Open protocols such as HTTP, TCP/IP, and email standards have become critical global infrastructure, quietly underpinning modern commerce, communication, and coordination at scale. They define how information moves, how systems interoperate, and how participation scales across borders, markets, and societies.

Blockchain-based protocols are beginning to play a similar role in financial systems. They are shaping how financial systems operate globally, including the rails through which markets are accessed and transactions are executed. As this shift accelerates, expectations around global access, uninterrupted availability, and user agency are rising, and blockchain-based protocols are rapidly emerging as a foundational layer of the financial infrastructure of the future. 

In this environment, jurisdictions that do not provide clear conditions for protocol builders risk pushing critical capacity to concentrate elsewhere and increasing dependence on infrastructure built to reflect different values. As financial infrastructure becomes increasingly protocol-based and globally shared, the capacity to participate in building and securing open-source systems shapes which standards, safeguards, and design defaults become widely adopted. Over time, those technical choices determine how transparency, user agency, risk mitigation, and market integrity are embedded in the infrastructure itself. Regulators must therefore modernize institution-centric frameworks while preserving clear, workable conditions for building and maintaining secure open infrastructure.

Open, collaborative development is a primary way critical software is built, maintained, and improved across sectors, from core internet infrastructure to widely used code libraries and security tooling. As financial infrastructure becomes increasingly software-driven, this same open-source development model is now being applied to systems that support financial markets.

Finance, however, is subject to robust and complex regulatory frameworks addressing risks around custody, market integrity, and systemic stability. These frameworks were designed to govern financial actors and activities, not the development of the underlying technology on which modern infrastructure increasingly depends.

As software takes on an infrastructural role, the risk of conflation increases. The breadth of financial regulation can cause ordinary development and maintenance activity to be treated as a regulatory anchor, creating uncertainty about when builders may be pulled into frameworks designed for operational intermediaries rather than infrastructure development.

That uncertainty does not effectively reduce risk. It makes it harder for developers and organizations to build and maintain open infrastructure with clear, bounded responsibilities. Jurisdictions that provide predictable, outcome-based boundaries—distinguishing infrastructure development from custody and intermediation—will be better positioned to sustain critical technical capacity over time.

This creates a fundamental choice for societies: treat builders as strategic assets to be enabled under clear conditions, or treat them as risks to be constrained through rules that call ordinary development activity into question.

Secure digital infrastructure requires ongoing iteration, maintenance, and collaboration. Development is necessarily continuous and often distributed across contributors and organizations. These activities are structurally unavoidable if infrastructure is to remain safe, functional, and competitive in an accelerating global landscape.

However, there is an increasing tendency to treat signals of development, such as maintenance, upgrade processes, coordination among contributors, or funding of development teams, as evidence of “control” over systems. This approach risks conflating development activity with custody or financial intermediation.

Protocol development, even when it enables financial applications, does not inherently involve custody or discretionary execution. Writing, publishing, or maintaining code does not place a developer in the flow of funds or make them a financial service provider. Where development activity does not result in custody of user assets or unilateral authority to move funds, it should not be used as a proxy to infer financial intermediation.

When development practices are treated as regulatory triggers, the result is not greater safety but legal uncertainty about whether ordinary, necessary development work may be pulled into regimes designed for custodial intermediaries. That uncertainty discourages ongoing maintenance and improvement, erodes local capacity to participate meaningfully in global infrastructure development, and concentrates talent and investment in jurisdictions with clearer, bounded protections.

This outcome is misaligned with regulatory objectives. Many protocol builders are explicitly designing systems to advance policy-aligned goals such as reducing custodial risks, increasing transparency, and improving systemic resilience. Enabling developers to freely work toward these outcomes within clear boundaries strengthens, rather than undermines, the effectiveness of financial regulation. In a world where financial infrastructure is increasingly protocol-based and globally shared, sustaining the capacity to build and secure systems that embed these objectives will determine which societies and values help define the standards and safeguards that underpin the next generation of financial infrastructure.

Moreover, software evolves faster than law and rulemaking. Process-based regulation therefore becomes outdated quickly, forcing regulatory scope to chase technical change.

Protecting builders does not mean ignoring risk. It means drawing regulatory boundaries at actual financial intermediation and custody, rather than at the collaborative process required to create, publish, or maintain open-source protocols.

Systems that are open-source, non-custodial, and peer-to-peer, where users interact directly and assets are not held or managed by a third party, present fundamentally different risk profiles from systems that custody assets or operate as intermediated financial services. They should be treated accordingly under law.

This distinction is functional, observable, and technologically neutral. It preserves the ability to regulate real financial risk while avoiding misclassification of infrastructure development as regulated conduct. Focusing on system function and real-world outcomes, rather than the mechanics of writing, deploying, and maintaining code, keeps regulation targeted where risk actually arises. It reduces uncertainty, keeps custodians and intermediaries accountable, and helps jurisdictions sustain the capacity needed to participate meaningfully in building resilient global financial systems.

• Focus on system properties and outcomes, not development activity.

  Evaluate whether a system has publicly available source code, is credibly neutral, non-custodial, and peer-to-peer in practice, and does not treat maintenance, upgrades, coordination, organizational structure, or other development practices alone to infer custody or intermediation.

• Attach regulatory obligations to custody and discretionary intermediation.

  Regulatory obligations should attach where actors hold user funds, take custody, control, and execute transactions on users’ behalf.

• Establish clear and durable safe harbors.

  Developers and infrastructure providers should have explicit, unambiguous protection from civil or criminal liability solely for creating, publishing, maintaining, or enabling access to open-source, non-custodial, peer-to-peer systems.

• Ensure protections apply across the full lifecycle.

  Protections should extend beyond initial deployment to ongoing development, maintenance, security upgrades, and improvement, so long as the system remains non-custodial and disintermediated.

These principles do not weaken oversight. They strengthen it by ensuring that regulation attaches to the activities that create risk for the user, while protecting the necessary development processes that make modern infrastructure secure, resilient, and capable of evolving in the public interest.

The Alliance is a voluntary coordination forum and is not a legal entity. Each participant speaks only for itself unless expressly stated otherwise.

Open protocols such as HTTP, TCP/IP, and email standards have become critical global infrastructure, quietly underpinning modern commerce, communication, and coordination at scale. They define how information moves, how systems interoperate, and how participation scales across borders, markets, and societies.

Blockchain-based protocols are beginning to play a similar role in financial systems. They are shaping how financial systems operate globally, including the rails through which markets are accessed and transactions are executed. As this shift accelerates, expectations around global access, uninterrupted availability, and user agency are rising, and blockchain-based protocols are rapidly emerging as a foundational layer of the financial infrastructure of the future. 

In this environment, jurisdictions that do not provide clear conditions for protocol builders risk pushing critical capacity to concentrate elsewhere and increasing dependence on infrastructure built to reflect different values. As financial infrastructure becomes increasingly protocol-based and globally shared, the capacity to participate in building and securing open-source systems shapes which standards, safeguards, and design defaults become widely adopted. Over time, those technical choices determine how transparency, user agency, risk mitigation, and market integrity are embedded in the infrastructure itself. Regulators must therefore modernize institution-centric frameworks while preserving clear, workable conditions for building and maintaining secure open infrastructure.

Open, collaborative development is a primary way critical software is built, maintained, and improved across sectors, from core internet infrastructure to widely used code libraries and security tooling. As financial infrastructure becomes increasingly software-driven, this same open-source development model is now being applied to systems that support financial markets.

Finance, however, is subject to robust and complex regulatory frameworks addressing risks around custody, market integrity, and systemic stability. These frameworks were designed to govern financial actors and activities, not the development of the underlying technology on which modern infrastructure increasingly depends.

As software takes on an infrastructural role, the risk of conflation increases. The breadth of financial regulation can cause ordinary development and maintenance activity to be treated as a regulatory anchor, creating uncertainty about when builders may be pulled into frameworks designed for operational intermediaries rather than infrastructure development.

That uncertainty does not effectively reduce risk. It makes it harder for developers and organizations to build and maintain open infrastructure with clear, bounded responsibilities. Jurisdictions that provide predictable, outcome-based boundaries—distinguishing infrastructure development from custody and intermediation—will be better positioned to sustain critical technical capacity over time.

This creates a fundamental choice for societies: treat builders as strategic assets to be enabled under clear conditions, or treat them as risks to be constrained through rules that call ordinary development activity into question.

Secure digital infrastructure requires ongoing iteration, maintenance, and collaboration. Development is necessarily continuous and often distributed across contributors and organizations. These activities are structurally unavoidable if infrastructure is to remain safe, functional, and competitive in an accelerating global landscape.

However, there is an increasing tendency to treat signals of development, such as maintenance, upgrade processes, coordination among contributors, or funding of development teams, as evidence of “control” over systems. This approach risks conflating development activity with custody or financial intermediation.

Protocol development, even when it enables financial applications, does not inherently involve custody or discretionary execution. Writing, publishing, or maintaining code does not place a developer in the flow of funds or make them a financial service provider. Where development activity does not result in custody of user assets or unilateral authority to move funds, it should not be used as a proxy to infer financial intermediation.

When development practices are treated as regulatory triggers, the result is not greater safety but legal uncertainty about whether ordinary, necessary development work may be pulled into regimes designed for custodial intermediaries. That uncertainty discourages ongoing maintenance and improvement, erodes local capacity to participate meaningfully in global infrastructure development, and concentrates talent and investment in jurisdictions with clearer, bounded protections.

This outcome is misaligned with regulatory objectives. Many protocol builders are explicitly designing systems to advance policy-aligned goals such as reducing custodial risks, increasing transparency, and improving systemic resilience. Enabling developers to freely work toward these outcomes within clear boundaries strengthens, rather than undermines, the effectiveness of financial regulation. In a world where financial infrastructure is increasingly protocol-based and globally shared, sustaining the capacity to build and secure systems that embed these objectives will determine which societies and values help define the standards and safeguards that underpin the next generation of financial infrastructure.

Moreover, software evolves faster than law and rulemaking. Process-based regulation therefore becomes outdated quickly, forcing regulatory scope to chase technical change.

Protecting builders does not mean ignoring risk. It means drawing regulatory boundaries at actual financial intermediation and custody, rather than at the collaborative process required to create, publish, or maintain open-source protocols.

Systems that are open-source, non-custodial, and peer-to-peer, where users interact directly and assets are not held or managed by a third party, present fundamentally different risk profiles from systems that custody assets or operate as intermediated financial services. They should be treated accordingly under law.

This distinction is functional, observable, and technologically neutral. It preserves the ability to regulate real financial risk while avoiding misclassification of infrastructure development as regulated conduct. Focusing on system function and real-world outcomes, rather than the mechanics of writing, deploying, and maintaining code, keeps regulation targeted where risk actually arises. It reduces uncertainty, keeps custodians and intermediaries accountable, and helps jurisdictions sustain the capacity needed to participate meaningfully in building resilient global financial systems.

• Focus on system properties and outcomes, not development activity.

  Evaluate whether a system has publicly available source code, is credibly neutral, non-custodial, and peer-to-peer in practice, and does not treat maintenance, upgrades, coordination, organizational structure, or other development practices alone to infer custody or intermediation.

• Attach regulatory obligations to custody and discretionary intermediation.

  Regulatory obligations should attach where actors hold user funds, take custody, control, and execute transactions on users’ behalf.

• Establish clear and durable safe harbors.

  Developers and infrastructure providers should have explicit, unambiguous protection from civil or criminal liability solely for creating, publishing, maintaining, or enabling access to open-source, non-custodial, peer-to-peer systems.

• Ensure protections apply across the full lifecycle.

  Protections should extend beyond initial deployment to ongoing development, maintenance, security upgrades, and improvement, so long as the system remains non-custodial and disintermediated.

These principles do not weaken oversight. They strengthen it by ensuring that regulation attaches to the activities that create risk for the user, while protecting the necessary development processes that make modern infrastructure secure, resilient, and capable of evolving in the public interest.

The Alliance is a voluntary coordination forum and is not a legal entity. Each participant speaks only for itself unless expressly stated otherwise.