Feb 3, 2025

From Wild West to Foundation of Finance: The Case for Public Permissionless Blockchains

The Owl
By and The Owl
shutterstock 2432442723

As recently as three or four  years ago, if you were a central bank,  financial institution or large enterprise wanting to experiment with blockchain technology, it would be a no-brainer to choose a private, permissioned network. Public permissionless blockchains were - and in many cases still are - viewed as a Wild West of DeFi lawlessness and NFT-driven hedonism. However, the tide is rapidly turning, and in the past couple of years we’ve seen increased interest from banks in building on public blockchain. Even the Bank for International Settlements - the ‘central bank of central banks’ - has started to run projects built on public blockchain

In this article we’re going to explain what public permissionless blockchains are, the benefits they can bring, and some examples of how financial institutions are already building on them. We’ll then look at why so many people in both the public and private sectors  have historically been inherently against public permissionless blockchains, what’s changing in terms of both technology developments and public perception, and how the barriers previously perceived by regulators and regulated entities are being broken down.

But first, let’s start with a few definitions. 

What do we mean when we say "public" and "permissionless"?

Public blockchains are open and accessible to anyone. Anyone can join the network, view the ledger and validate transactions, without any restrictions. In this respect, they’re fully decentralized and self-governing, and have a high degree of autonomy and resilience. 

Permissionless means that there are no gatekeeping requirements associated with access to and participation in the blockchain, and nobody needs special permission in order to join, validate or develop applications on the network.  

While these terms often overlap, they are not entirely synonymous. A blockchain can be public but not entirely permissionless if, for example, only authorized nodes can validate transactions (as in some ‘hybrid’ models, like Hedera). Conversely, a permissionless blockchain is typically public, as it relies on open participation to maintain its decentralized ethos. But taken together, these qualities underpin the trustless and open nature of many blockchain systems, enabling broad participation.


What are some of the benefits of public permissionless blockchains?

Public permissionless blockchains don’t rely  on a central authority exercising power and control to create trust between unknown counterparties. The ‘trust’ in this instance comes from the combination of decentralization, robust consensus mechanisms and economic incentives, cryptographic security, transparency and immutability of public blockchains. This decentralization eliminates single points of failure, making these networks more resilient against outages or cyberattacks. Open access allows global participation, enabling a broad range of developers and institutions to build and integrate applications, driving innovation, liquidity, and diverse use cases through composable ecosystems.

Network effects also play a role. The larger and more established a blockchain's user base, the more secure and trustworthy it becomes. This is because a larger network typically has more nodes validating transactions, making attacks less feasible. Public blockchains also often rely on open-source software, allowing the best developers and security experts globally to test, audit and improve the code. This open scrutiny helps identify vulnerabilities and maintain robustness. For the blockchain community, it’s axiomatic that all this is better: safer, more reliable, more universal.

Permissioned networks are still great for certain applications, particularly those in which there are a limited number of participants who all need to be on-boarded and known to each other,  implementing a very specific use case and with no need to interact with a broader range of participants or assets. But there’s an increasing recognition of the benefits that public permissionless blockchains bring for asset tokenization: distribution and liquidity, the benefits of a diverse ecosystem, and other network effects. 


Why and how are regulated financial institutions starting to use public blockchain?

Issue an asset on a private permissioned network and it’s available only for the use case implemented on that network, and to the participants in that network. Issue onto a public permissionless blockchain, and your tokenized asset can be accessible to any participant. It can be exchanged bilaterally between wallet-holders, picked up and integrated into decentralized exchanges or used as collateral in lending protocols. 

Users can pay for them in any stablecoins available on the network, or swap them directly for other tokenized assets. It can also be composed with other tokenized assets into use cases and applications that you as an issuer might never have foreseen. It can be bridged onto other public permissionless blockchains and made available to their ecosystems. All of this distribution capability drives greater liquidity and innovation - and that’s evidenced by the growing trend towards tokenized fund issuance on public chains. 

A growing recognition of these benefits - alongside all the other benefits of the technology - is fueling more experimentation and a growing cohort of live projects on public chains. Some high-profile examples include:

What are the regulators’  concerns about public permissionless blockchain?

Regulators often start from some assumptions that challenge the benefits or need for public permissionless blockchains. Essentially, because of the way regulation works in the traditional financial sector, this initial mistrust comes out of  how different institutions and parts of the financial, regulatory and technology ecosystems look at the world. They see the words ‘public’ and ‘permissionless’ and conflate these with a lack of control over activities that should be regulated, and an inability to apply concepts like AML and KYC to participants. There’s a clash between worldviews.


Are these concerns justified?

A public blockchain typically isn’t a single application. It’s a network-based technology platform on which a range of applications and protocols can be built. These protocols themselves can have on-boarding requirements. Permissioning can also be implemented at the token level, so that tokens can only be transferred in accordance with predefined requirements. 

Nevertheless, public blockchains are increasingly recognizing the importance and value of supporting different permissioning mechanisms. Multichain blockchains, such as Avalanche and Cosmos, enable the creation of specialized blockchains, sometimes referred to as subnets or app-chains, that can be compliant by design. In these systems, developers can create chains with custom rule sets, execution environments, and governance regimes tailored to their needs. These custom blockchains unlock use cases previously not possible on blockchains with single rule sets, and isolate traffic and data into environments purpose-built for a given use case. They can also be natively interoperable with their mainnets and with other custom chains in the same network, enabling more of a balance to be struck between control and distribution of tokenized assets. 


Why go public and permissionless?

Just as we don’t try today to control who has access to the internet and who can build on it, regulators and governments don’t need to try to control public blockchains to mitigate potential risks from them. They come with significant, in-built benefits in terms of robustness, security and resilience. Additionally, public and permissionless at the blockchain technology level is not synonymous with public and permissionless at the application level, and this is where regulators should focus their attention. There are many mechanisms available to implement robust compliance at the protocol and token level, while still benefiting from the network effects of a diverse, innovative ecosystem.  

As we’ve seen, there are valid use cases for both private, permissioned and public, permissionless blockchains, and both will continue to exist, and co-exist, into the future. Which one you use for your business will depend on the outcomes you wish to achieve, and how that aligns with the relative attributes of different blockchains. More and more actors both in the crypto space and traditional financial system are realising that public, permissionless blockchains can be a strong foundation for new ways of doing business.

Articles

sand-
2026-04-15

The SEC Confirms: The Nature of the Activity Matters

How the SEC’s User Interface Guidance Aligns with APC’s Framework Recent guidance from the SEC’s Division of Trading and Markets on broker-dealer registration for user interfaces (the “Staff Statement”) marks an important step toward bringing clarity to digital asset regulation. While the statement focuses specifically on user interfaces interacting with crypto asset securities, its broader significance lies in the analytical framework it adopts. That framework closely aligns with the Avalanche Policy Coalition’s (APC) long-standing position: Regulation should turn on the nature of the activity, not the technology used to perform it. In our May 2025 submission to the SEC Crypto Task Force, we articulated this concept as the “nature of the activity test.” The Staff Statement demonstrates that this approach is increasingly reflected in regulatory practice. The Core Question: When Does a Tool Become an Intermediary? The SEC’s statement addresses a central issue in modern market structure: When does a software interface that enables transactions become a broker-dealer? Rather than creating a new category for “crypto interfaces” or focusing on the use of blockchain technology, the Staff applies a familiar inquiry rooted in existing law. The analysis turns on whether the provider is engaging in traditional intermediary activities, such as: Soliciting transactions Recommending securities Exercising discretion Receiving transaction-based compensation Custodying assets Acting as an intermediary between buyers and sellers If these hallmarks are present, broker registration is required. If they are not, the provider should not be treated as a broker.  This is a functional test—one that looks to what the entity does, not the means by which it is done. APC’s “Nature of the Activity” Test This approach closely mirrors the framework proposed in Ava Labs’ May 2025 submission to the Task Force. In that letter, APC articulated the nature of the activity test as a method for determining when infrastructure providers should be treated as securities intermediaries. The test asks a simple question: Are the activities ones performed by a broker, dealer, or investment adviser? If the answer is yes, existing regulatory obligations apply. If not, registration should not be required. This framework is grounded in decades of securities law. As the submission explains, the SEC has long evaluated whether entities fall within the scope of broker, dealer, or adviser regulation based on factors such as: Engagement in the business of effecting transactions Providing investment advice Receipt of transaction-based compensation Active solicitation of trades Participation in negotiations Custody of customer funds or securities Notably, none of these factors depend on the technology used. They were developed in an era of paper-based markets and continued to apply as markets digitized. We went on to say that the same logic should apply to blockchain-based systems, which represent the next iteration of digital market infrastructure. Infrastructure vs. Intermediation A central theme of the APC submission is the distinction between infrastructure providers and intermediaries. Infrastructure providers—such as validators, software developers, and communications providers—perform essential technical functions. They enable networks to operate but do not: Solicit transactions Provide advice Exercise discretion Control assets Know or influence the nature of specific transactions As the submission explains, these actors are: “invisible and indiscriminate in verifying, recording, and enabling transactions.” Their role is analogous to that of internet service providers, cloud service providers, API and RPC providers, and similar technical services.   These functions have never been treated as regulated financial intermediation, even though they are essential to the operation of financial markets. Our recent blog post comparing the GENIUS Act’s exceptions for infrastructure with the exceptions for “ancillary infrastructure” in the EU’s Transfer of Funds Regulation reinforces this distinction. SEC’s User Interface Guidance: A Practical Application The Staff Statement reflects this same distinction, even if it uses different terminology. The statement identifies a category of providers—those offering interfaces assisting users in crypto asset securities transactions (“Covered User Interfaces”)—for which broker-dealer registration is not required, provided they satisfy certain conditions. These conditions effectively define what it means to operate as infrastructure rather than an intermediary. To remain outside broker-dealer status, an interface provider must: Allow users to set all transaction parameters Avoid recommendations or investment advice Refrain from soliciting trades Operate without discretion or control Present execution options using objective criteria Maintain neutral, non-conflicted compensation structures Provide clear disclosures These requirements collectively describe a passive, neutral conduit—precisely the type of actor that has historically received no-action relief.  Continuity with SEC No-Action Precedent The APC submission places heavy emphasis on the SEC’s long history of granting no-action relief to technology providers performing neutral functions. Examples include: Messaging systems connecting brokers Electronic bulletin boards posting trade information Matching platforms linking investors and issuers Data providers offering analytics and research In each case, the SEC focused on whether the provider: Exercised control Participated in negotiations Provided advice or recommendations Handled funds or securities Earned transaction-based compensation Where these elements were absent, the SEC consistently declined to require registration. The user interface guidance follows the same pattern. It does not create new rules; it applies existing principles to new technology.  The Staff Statement even frames its conclusion in terms that closely resemble traditional no-action relief:  In circumstances where a Covered User Interface Provider takes the measures discussed below relating to its creation, offering, and/or operation of a Covered User Interface, the Staff will not object to the Covered User Interface Provider creating, offering, and/or operating a Covered User Interface without registering as a broker-dealer pursuant to Section 15(b) of the Exchange Act. Conclusion The convergence between APC’s framework and the SEC’s guidance has important implications. First, it confirms that existing law is sufficient when applied correctly. There is no need to create new categories for blockchain-based actors. Second, it reinforces the importance of functional analysis. Regulatory outcomes should depend on what an entity does—not on labels, technology, or proximity to financial activity. By focusing on the nature of the activities conducted, regulators can distinguish between: True financial intermediaries, and The infrastructure and tools that support modern markets Third, it provides a path forward for innovation. By clarifying that neutral infrastructure and tools are not automatically subject to intermediary regulation, the SEC reduces uncertainty and enables development within a compliant framework. APC is encouraged to see this clear alignment with its “nature of the activity” test. It demonstrates that longstanding principles of securities law remain vibrant and adaptable—even as markets evolve. The next step is to apply this same logic consistently across the digital asset ecosystem, ensuring that regulation remains targeted, coherent, and grounded in how these technologies actually operate. As our 2026 policy priorities make clear: Infrastructure providers are not intermediaries. Getting this distinction right is essential—not only for regulatory clarity, but for ensuring that robust, competitive markets can develop within a coherent and predictable framework.

The Owl
By and The Owl
shutterstock 2730976661
2026-04-13

DeFi Governance Is a Question of Concentration, Not Decentralization

A recent European Central Bank working paper looks to analyze decentralization in DeFi protocols from the standpoint of governance.  It finds concentration in governance and that this undermines decentralization.  This claim, however, rests on a conceptual error: it conflates system decentralization with governance concentration. And governance concentration that does not affect transaction finality or asset ownership is not relevant to whether a system is decentralized. The distinction matters and clarifies both the paper’s findings and their implications. At Avalanche Policy Coalition, we have consistently defined decentralization from a technical standpoint. A system or network is decentralized when there is no single source of truth, no single point of failure, and no authority with the ability or responsibility to change data, transactions or balances.  It is a definition focused on finality. It ensures that users can trust what they see regarding ownership of assets and the completion of transactions.  The working paper errs by reframing decentralization as a governance question rather than a matter of network finality.  It compounds this error by trying to answer the question of who to regulate in DeFi by looking at concentration of governance power and participation across major DeFi protocols.  What the paper actually demonstrates is not a failure of decentralization, but the presence of concentrated governance layered on top of decentralized infrastructure. Confusing governance concentration with decentralization risks pushing regulation toward infrastructure rather than actors—undermining the very properties that make these systems trustworthy. Here is a summary of the paper’s empirical findings:  Token ownership is heavily skewed, with the top 100 holders controlling more than 80% of supply across the studied protocols, and the top five holders often control a substantial fraction of that total. Governance systems also rely extensively on delegation, whereby token holders assign voting power to intermediaries. As a result, a relatively small number of delegates exercise a disproportionate share of voting power, in some cases controlling the majority of delegated votes. Delegation thus operates as a structural amplifier of concentration. The paper also notes that concentration of governance power is further compounded by opacity. A substantial share of the most influential participants cannot be linked to identifiable individuals or institutions, making it difficult to determine whether governance power is independent or coordinated, whether incentives are aligned or conflicted, and whether influence is exercised by insiders, intermediaries, or diffuse communities. At the same time, governance processes themselves do little to redistribute power. The paper shows that most proposals concern operational parameters—risk settings, asset listings, and similar adjustments—while very few address governance structure. As a result, the paper concludes, existing distributions of power tend to reproduce themselves over time. The paper then concludes that decentralization is a property of governance. Under this view, a system is decentralized to the extent that decision-making authority is widely distributed, no small group can dominate outcomes, and the relevant actors are identifiable and accountable. If governance power is concentrated, the paper concludes that decentralization is incomplete or illusory.  This definition is viscerally appealing, particularly from a regulatory perspective. Regulators require identifiable points of control, and the paper emphasizes the difficulty of relying on governance token holders, developers, or exchanges as regulatory “anchor points” precisely because of opacity and fragmentation in governance structures.  Yet this definition departs from the more established understanding of decentralization in distributed systems, where the concept refers not to governance dispersion but to system architecture: whether there is a single point of failure, a single source of truth, or a single authority capable of altering data or transactions. On the more technically precise definition of decentralization, the protocols studied in the paper—built on public blockchains—remain decentralized. Framed in these terms, the paper’s findings are best understood as documenting concentrations of governance power, not undercutting decentralization.  The paper does not show that any individual token holder, delegate, or developer can rewrite transaction history, override consensus, or unilaterally alter the state of the ledger. Nor does it show that the voting groups have this power.  It also implicitly recognizes that where governance does not affect asset ownership or transaction finality, regulatory hooks are difficult to establish.  Indeed, as noted above, the proposals on which votes are sought have nothing to do with transaction finality or asset ownership.   At best, the paper can conclude that the infrastructure remains decentralized even if governance becomes concentrated. This distinction suggests a more precise analytical framework. At the infrastructure layer, finality is distributed, consensus is collective, and no single point of failure exists. At the governance layer, ownership can become concentrated, voting power aggregated, and influence unevenly distributed. These are not contradictory observations but complementary ones. DeFi systems can be both decentralized and concentrated, depending on the layer of analysis. Recognizing this layered structure clarifies the nature of the challenges identified in the paper. The difficulty regulators face is not that decentralization has failed, but that concentration exists without clear attribution.  This produces a structural asymmetry.  Governance actors can shape protocol outcomes—adjusting parameters, allocating resources, and influencing development trajectories—but they do so within systems whose core integrity cannot be compromised by that concentration. The result is a hybrid condition in which decentralized infrastructure coexists with concentrated influence over things that do not undercut decentralization. Reframing the issue in terms of concentration rather than decentralization also shifts the focus of regulation. For regulators, the challenge is not identifying a centralized intermediary in the traditional sense (i.e., one that controls transactions or custodies assets), but understanding how concentrated influence operates within systems that lack formal control points on the areas of typical regulation. Addressing these issues will require regulatory approaches that focus on identifiable actors and activities, rather than attempting to impose control at the infrastructure layer where it does not exist. The ECB paper makes a significant contribution by documenting the realities of DeFi governance. But its conceptual framing requires greater precision. Decentralization and concentration are not opposing descriptions of the same phenomenon; they operate at different levels of analysis. The systems studied in the paper are not failed attempts at decentralization. They are decentralized systems with concentrated governance structures. And where those structures do not affect transaction finality or asset ownership, the system remains decentralized. Recognizing this distinction provides a clearer understanding of both the risks and the possibilities inherent in DeFi. To hear more on this and related topics, please listen to this webinar from Global Blockchain Business Council.

The Owl
By and The Owl
IMG 8810
2026-04-03

Getting Infrastructure vs. Intermediary Right: EU Transfer of Funds Regulation and the US GENIUS Act

Financial regulation has always looked to capture intermediaries, the money transmitters, brokers, exchanges, custodians, and others that move, hold or control assets on behalf of end users. In traditional financial services, that boundary is relatively clear: regulation attaches to those who intermediate transactions, control client assets, or provide financial services. It does not attach to the wider infrastructure that supports those activities. As digital asset ecosystems become more complex, that same boundary is being tested in new ways, making it important to defend the underlying principle. This piece examines how the EU’s implementation of the Travel Rule (via the recast Funds Transfer Regulation or “TFR”) correctly draws that line using the concept of “ancillary infrastructure,” and how a similar distinction appears in the U.S. GENIUS Act. At its core, the analysis is simple but consequential: when does a participant in a crypto system become a regulated intermediary, and when are they merely part of the infrastructure that makes the system work? These two pieces of legislation on both sides of the Atlantic show how policy makers can ensure regulation remains in force for the activities they want to capture, without blurring the distinction between infrastructure providers and financial intermediaries. In the EU: Where the Concept Comes From The EU’s idea of ancillary infrastructure appears in the recitals of the TFR, which guide how the regulation should be interpreted. The regulation explains (emphasis added): Persons that provide only ancillary infrastructure, such as internet network and infrastructure service providers, cloud service providers or software developers, that enable another entity to provide transfer services for crypto-assets, should not fall within the scope of the Regulation unless they perform transfers of crypto-assets. That is the entirety of it. The term is not further defined. There is no formal category or test in the operative provisions of the TFR, just this functional description and a few examples. But that short passage does a lot of good work. A Working Definition Taking the recital’s examples and its express limit together, ancillary infrastructure can be more specifically understood as: Infrastructure that is used by others in connection with crypto-asset transfers, but does not itself effect, execute, or control the transfer of crypto-assets, or provide custody of such assets. This is not a technology-based definition. It is a role-based definition, grounded in the regulatory perimeter. (This is consistent with other EU Regulations in the crypto-space, such as the Markets in Crypto-Assets (MiCA) Regulation.) What matters is not what the system looks like, but what the activity actually is. Two elements define the boundary: 1. Used in Connection with Transfers The infrastructure is part of the ecosystem that enables crypto-asset transfers. It may be essential to the functioning of the system. It may sit directly in the transaction flow. But it operates in a supporting role to the financial transaction, and is used by other entities such as CASPs and end users. 2. No Transfer or Custody Function The infrastructure provider does not: effect or execute transfers, control the movement of crypto-assets, or provide custody or control over those assets. That is the dividing line. Once a provider crosses into movement or control of value, it begins to look like an intermediary. If it does not, it remains infrastructure. What Counts as Ancillary Infrastructure The TFR itself provides only a handful of examples, but they point to a broader and consistent categorization. They are infrastructures that enable the system to function, without themselves engaging in the activities of financial intermediation. Internet Network Providers, such as internet service providers and network connectivity providers. These entities move data, not value. They carry transaction information across networks, but they have no relationship to the underlying assets being transferred or parties making the transfers. Cloud Service Providers, such as infrastructure-as-a-service providers and cloud hosting platforms. These providers supply computing power, storage, and hosting. They make it possible to run nodes, exchanges, and applications, but do not execute transfers, hold assets or interact directly with customers. Software Developers, such as developers of non-custodial wallets, developers of blockchain protocols, and providers of APIs and developer tools. These actors create the tools that others use to interact with crypto-assets. Once deployed, they do not control how those tools are used, nor do they execute or custody transactions. Technical Infrastructure Providers, such as node infrastructure providers, remote node access (RPC) providers, blockchain data indexing services, and validators and miners. These entities maintain and operate the underlying networks. They validate transactions, order and record them according to protocol rules, and ensure the system continues to function. They do not act on behalf of users, determine the purpose of transactions, or take custody of assets. Their role is protocol-level infrastructure and maintenance, not financial intermediation. Data and Analytics Providers, such as blockchain analytics firms, transaction monitoring tools, and risk scoring services. These providers analyze and interpret blockchain data. They support compliance, investigation, and risk management, but they do not initiate, execute, or control transfers. As we see, the concept of ancillary infrastructure covers a lot of different providers and activities, none of which intermediates or has direct responsibility for transfers or custody. This recognition provides a critical distinction between who is and who is not subject to regulation. A Parallel Approach: The GENIUS Act The same boundary appears explicitly in the U.S. GENIUS Act, which introduces the concept of a Digital Asset Service Provider (DASP) and provides exceptions for infrastructure providers. The Act defines DASPs by reference to familiar intermediary activities: exchanging digital assets, transferring them to third parties, acting as custodians, and providing financial services tied to issuance. In other words, DASPs are intermediaries. But the definition goes further by explicitly stating what is not an intermediary. The definition of DASP explicitly excludes: a distributed ledger protocol; developing, operating, or engaging in the business of developing distributed ledger protocols or self-custodial software interfaces; an immutable and self-custodial software interface; developing, operating, or engaging in the business of validating transactions or operating a distributed ledger; or participating in a liquidity pool or other similar mechanism for the provisioning of liquidity for peer-to-peer transactions. This is the same idea as ancillary infrastructure in the TFR, but stated directly in the text (rather than the recitals), and in greater detail. The Same Line, Two Drafting Styles The TFR and the GENIUS Act take different drafting approaches, but they arrive at the same place. The TFR uses a functional exclusion (“ancillary infrastructure”) The GENIUS Act uses explicit statutory carve-outs Both frameworks draw the same distinction: Intermediaries are regulated because they effect or execute transactions, or control or custody assets - activities that are traditionally within the regulatory perimeter. Infrastructure providers are not, because they enable systems rather than effect transactions or custody assets - activities that have never been captured within the regulatory perimeter, although firms using the infrastructure to undertake regulated activities may themselves require regulatory authorization. In both, that principle holds across network providers, software developers, validators and miners, and other technical actors. Conclusion: Why This Distinction Matters This boundary is not just a drafting detail, it continues to apply a foundational principle. Crypto systems are built in layers. Many actors contribute to how transactions are created, transmitted, and recorded. Without a clear distinction, regulation could easily expand to capture the entire stack. The concept of ancillary infrastructure prevents that outcome. It ensures that providing infrastructure, which is neutral and only indirectly involved, is not treated the same as acting as an intermediary in transactions. That principle is now reflected on both sides of the Atlantic. As digital asset markets evolve, it is likely to remain one of the most important lines in crypto regulation. And together these two pieces of legislation show how policy makers can update rulebooks for new technologies without unwittingly regulating the technology itself. We at Avalanche Policy Coalition have discussed this point multiple times over the last year, including in our April and May comment letters to the SEC Crypto Task Force, our response to the Australian Treasury consultation, and this blog post. Preserving the distinction between infrastructure and intermediary is one of our 2026 policy priorities.

The Owl
By and The Owl