Ready Layer One: Functional Regulation for Blockchain Infrastructure
By
By
Carla L. Reyes[1]* & Joseph P. Cutler[2]**
II. Traditionally, The Law Takes a Functional Approach to Open-Source Software. 325
A. Existing Financial Regulation Assumes an Intermediated Financial System. 342
IV. The Emerging Decentralized Era Requires a Return to Functional Regulation. 355
2. Functional regulation should be technology neutral. 364
5. Open access to digital infrastructure resources should be protected. 368
Abstract
A software developer quietly builds a protocol that connects anyone with a project or a cause directly to other people who might be interested in financially contributing to the project or cause. Known broadly as a crowdfunding platform, this software developer is building something slightly different and new. In particular, his code connects those with project ideas directly to those willing to contribute to those ideas via computer code—enabling peer-to-peer collaboration. No company—such as the well-known Kickstarter—would need to operate the platform, facilitate connections between users of the platform, or custody funds. Rather, the developer is building software that would achieve those functions on an entirely decentralized and disintermediated basis. Before the developer could publish the software and make it available to the public, the Department of Justice brought criminal charges—felonies—against two developers of other decentralized software for unlicensed money transmission—even though the other developers never had custody of, or access to, any funds transacted through the software that they wrote.
In the wake of these prosecutions, instead of publishing the software, for fear of later facing criminal charges himself, the decentralized crowdfunding software developer sued the Department of Justice, seeking a declaration that it is not illegal to write and publish code that builds tools for use by other people.[3] The lawsuit stands for more than just pursuit of clarity, however. The lawsuit makes a larger policy point: by targeting open-source code and developers of that code—even though the code only executes software operations and does not take custody of any funds—federal regulatory policy has not only limited access to key existing digital public infrastructure that provides public goods, but has also chilled the willingness of other developers to build additional digital infrastructure. Because decentralized digital infrastructure is needed to usher in the next phase of digital commerce, these legal battles represent more than mere lawsuits. The three cases—two criminal and one civil—represent a battle over individual rights and autonomy and core aspects of national economic and innovation policy.
Picking up on the policy importance of the issue, in both 2025 and 2026, the Blockchain Regulatory Certainty Act (BRCA) was introduced for consideration by the U.S. Congress, which introduces protections for decentralized software developers so that they no longer need to fear prosecution for developing peer-to-peer open-source software. Up to this point, however, misunderstandings around how the technology works and inapt analogies have prevented regulatory and legal clarity in the DLT industry. Indeed, even as lawmakers considered the BRCA, another proposal circulated on Capitol Hill that would deem developers to be controllers of the open-source software they build for legal liability purposes. This conflict became a point of contention as the Senate worked to build market structure draft bill in 2025 and again in 2026 to correspond with the House’s Clarity Act. As a result, developers should not rest comfortably until lawmakers and regulators adopt a broader, and more predictable legal framework that distinguishes the functional roles played by developers of public open-source DLT protocols from centralized businesses that build on top of those protocols and apportions liability accordingly.
To resolve this quandary, this Article proposes a functional regulatory framework that recognizes the inherent characteristics of open-source Layer-1 DLT protocols and open-source Layer-2 smart contract protocols as digital infrastructure. In particular, this Article makes a novel contribution to the on-going scholarly analysis of open-source protocols as digital infrastructure by surveying the functional methods proposed for financial regulation and used in commercial law, comparative law, and legal approaches to artificial intelligence, and crafting five key principles for engaging in functional regulation of the DLT industry. This Article makes this novel proposal in three parts. Part II explores the treatment of the internet and network protocols as infrastructure and argues that open-source Layer-1 DLT protocols and open-source Layer-2 smart contract protocols similarly operate as infrastructure. Ultimately, Part II places open-source DLT protocols and Layer-2 smart contract protocols within this historical context as the next wave of open-source digital infrastructure development. Part III acknowledges that initial regulatory approaches to the DLT industry adopted a functional method, and then traces a shift in the legal treatment of DLT protocols away from a functional regulatory approach to uniform application of financial regulation designed for intermediated finance. As it does so, Part III explores the inherent mismatch between existing highly intermediated financial regulation and highly disintermediated open-source blockchain protocols. Part IV develops a framework for functional regulation in two respects. First, Part IV recommends regulatory process adjustments that would put the functional approach to work in simple, but impactful and concrete ways. Second, Part IV outlines five key principles of functional regulation for lawmakers and their policy teams to use as they continue to confront the changing landscape presented by an increasingly decentralized and disintermediated commercial era. A final section concludes that embracing functional regulation for the DLT industry will not only preserve access to open-source Layer-1 DLT protocols and Layer-2 smart contract protocols as the digital infrastructure that they are, but may also help lawmakers and regulators craft a careful and coordinated policy for other emerging technologies—including, for example, artificial intelligence—that increasingly play a crucial and strategic role in innovation and economic development in the United States.
1.6 billion people around the world use a virtual private network (VPN) when transacting over the internet to protect themselves from tracking and exploitation by fraudsters.[4] Indeed, in the legal field, many consider use of VPN technology to be a key tool in satisfying a lawyers’ duty of confidentiality under the Rules of Professional Conduct.[5] And yet, nearly 30 years ago, the law attempted to stomp the foundational technology underlying modern-day VPN software out of existence and jail its creator. Allow us to explain: this is the story of the “Pretty Good Privacy” (PGP) software[6] and the original Cypher Wars, a story that will soon sound all too similar to modern day happenings in decentralized open-source software.
At the dawn of the internet age, personal computers became household items, along with widespread use of modems, fax machines, the internet, email, and cell phones, and a host of other modern technological marvels.[7] But as people reaped the personal and business benefits of modern communications technology, the law struggled to adapt in a variety of ways.[8] In particular, privacy law struggled to adequately address law enforcement’s new capacity for surveillance of digital communication.[9] Indeed, the U.S. attempted to require communication technology manufacturers to install back-doors into their products to give law enforcement access to data whenever they wanted.[10] In fact, the 1994 Digital Telephony bill required phone companies to install technology that enabled easier wiretapping.[11]
Worried that “new technologies [would] give the government new automatic surveillance capabilities that Stalin could never have dreamed of,” software developers searched for privacy-protecting tools that could enable individuals to resist digital encroachment on their privacy rights.[12] In 1991, Phillip Zimmerman created software called “Pretty Good Privacy” or “PGP,” which enabled individual internet users to protect their messages and data while communicating online through the use of public-key cryptography.[13] Later that year Zimmermann released PGP to the world as free and open-source[14] software.[15] By 1993, Zimmerman was under federal investigation; he was subjected to a federal criminal investigation for alleged violations of the International Traffic in Arms Regulations, which prohibited the exportation of “munitions,” a term broad enough to include cryptographic software like PGP.[16]
The International Traffic in Arms Regulations were enacted as implementing regulations for the Arms Export Control Act of 1976,[17] and were intended to keep U.S. military grade weapons out of the hands of Cold War enemies abroad.[18] Faced with a new threat to its surveillance capacity,[19] law enforcement applied a twenty-year-old law designed to protect military-grade weapons to an entirely new context: open-source software that enabled private digital communications.[20] The public, however, spoke out against the obvious overreach of applying a Cold War-era weapons regulation to an open-source software tool and its developer.[21] Ultimately, the federal government closed its investigation without charges in 1996[22] and PGP became the backbone of modern encryption technology that private individuals and entities use to this day.[23] Unfortunately, these Cypher Wars of the 1990s did not end the fight waged by open-source software against government encroachment upon individual rights to privacy. Indeed, an eerie repeat of the PGP Cypher War is playing out in the modern context of government attempts to apply traditional financial regulation to open-source distributed ledger technology (DLT) protocols.[24]
Open-source DLT protocols and open-source software built on top of such protocols enable private individuals to recapture a measure of financial autonomy by providing the technical infrastructure that enables disintermediated digital financial transactions.[25] The modern-day federal government routinely attempts to apply financial regulation designed for an intermediated financial system to open-source DLT protocols that create peer-to-peer infrastructure.[26] Instead of justifying this approach with worries about affording communications privacy to Russian spies, the modern enforcement apparatus justifies applying financial regulation to open-source software in order to prevent criminals and terrorists from exploiting it for illicit finance.[27] Just as export control laws were an ill-fitting tool for combatting the cold war in the internet era, modern financial regulation is an ill-fitting tool for combatting illicit digital finance in today’s decentralized digital era.
Instead of using a system of regulation designed for an intermediated industry as a one-size-fits-all solution to regulation, this Article argues that the increased adoption of decentralized infrastructure for digital activity requires functional regulation.[28] Functional regulation requires crafting regulation by first “examining the functionality of a process or application without worrying about the details of its internal structure.”[29] A functional legal regime would calibrate its regulatory approach to the function that actors and technology play in commerce. For example, open-source software that acts as digital infrastructure to support any number of different types of activity, including disintermediated financial transactions, would not be subject to rules designed for financial intermediaries, while broker-dealers who use the infrastructure to transact on behalf of others would be subject to such rules. Using open-source Layer-1 DLT protocols and open-source Layer-2 smart contract protocols as case studies, this Article unpacks a framework for functional regulation, in three Parts.
Part II outlines the history of law’s interaction with open-source software, highlighting law’s tradition of approaching open-source software functionally and the long-familiar open-source ethos of creating rights-protecting software infrastructure as new technology changes the face of commerce. In particular, Part II examines the treatment of the internet and network protocols as infrastructure and argues that open-source Layer-1 DLT protocols and open-source Layer-2 smart contract protocols similarly operate as infrastructure. Ultimately, Part II places open-source DLT protocols and Layer-2 smart contract protocols within this historical context as the next wave of open-source digital infrastructure development and uncovers how regulatory efforts related to DLT initially followed a functional approach by focusing on activity undertaken using infrastructure but maintaining open access to the infrastructure itself.
Specifically, various financial regulation enforcement agencies initially seemed to acknowledge the infrastructural nature of Layer-1 DLT protocols and certain Layer-2 smart contract protocols by adopting regulatory guidance that centered on activity and excepted infrastructure. Part III traces the shift in the legal treatment of DLT protocols from a functional regulatory approach that governed activities of individuals and entities to the application of financial regulation designed for intermediated finance directly to code. Part III explores the inherent mismatch between the existing highly intermediated financial regulatory regime and highly disintermediated open-source DLT protocols. Further, Part III uses several case studies to argue that blindly applying existing financial regulation to DLT protocols both fails to achieve stated policy goals and undermines long-term technological innovation.
Part IV develops a framework for functional regulation in two respects. First, Part IV recommends regulatory process adjustments that would put the functional approach to work in simple, but impactful and concrete ways. Second, Part IV outlines five key principles of functional financial regulation for lawmakers and their policy teams to use as they continue to confront the changing landscape of finance in an increasingly decentralized and disintermediated era. A final section concludes that embracing functional regulation, first for open-source Layer-1 DLT protocols and open-source Layer-2 smart contract protocols, and then more broadly for other emerging technology may offer an underappreciated avenue for combatting systemic risks to both traditional and emerging decentralized technology systems.
The long and fruitful U.S. history with open-source software development offers lessons for developing a modern-day legal regime for open-source Layer 1 blockchain protocols and certain open-source Layer-2 smart contract protocols. Specifically, the law’s approach to open-source software and their communities as a form of commons resulted in a functional approach to issues at the intersection of law and open-source software. This Part examines the history of free and open-source software development in the United States, emphasizing the mostly hands off approach law adopted with regard to the code itself. This Part also highlights the impact that understanding and characterizing open-source network protocols (like the internet) as digital infrastructure had on policy debates. This Part then considers the technical realities of open-source Layer-1 distributed ledger technology (DLT) protocols and open-source Layer-2 smart contract protocols and argues that they fit the various definitions of infrastructure resources and infrastructural services that justified the preservation of open-access digital technologies during the early policy debates at the emergence of the internet. Layer-1 DLT protocols and Layer-2 smart contract protocols represent the next wave of open-source digital infrastructure development. As the law develops with regard to DLT protocols, it should be guided by the same functional approach historically used for activity conducted via the internet and other open-source software protocols.
Free and open-source software[30] enjoy a lengthy commercial, economic, and legal history in the United States.[31] Indeed, during the last four decades,[32] open-source software has formed the basis of some of the most important technological advances in computing that modern society currently enjoys.[33] For example, the Linux operating system (which currently powers the Android platform),[34] email, the World Wide Web, Internet Relay Chat, and many other programs that enable much of the activity undertaken via today’s internet were developed as open-source software by communities of volunteer developers.[35] Many such communities create these software innovations through a governance structure that eschews the traditional hierarchy of most organizations.[36] Although projects are often followed by a foundation, the structure of the community that contributes to the open-source code is not generally dictated by the foundation.[37] Further, although many commercial entities put open-source software to use in the products and services they offer to consumers, thereby profiting from the existence of the software, many of the contributors to open-source projects do not.[38] Irrespective of why open-source software developers contribute to specific projects, the reality is that open-source software powers core components of modern computing software such as HTML,[39] Apache,[40] Linux,[41] virtual private networks,[42] and email,[43] among others.
Notably, most of the key examples of open-source software that fuel the modern economy act as tools and platforms that enable others to further develop applications downstream. With a few notable exceptions, law has historically actively resisted direct regulation of such open-source software because it fulfills the function of infrastructure.[44] The plain meaning of the word “infrastructure,” is, according to one source, “The underlying framework of a system; esp., public services and facilities (such as highways, schools, bridges, sewers, and water systems) needed to support commerce as well as economic and residential development.”[45] Indentifying when open-source software acts as infrastructure in the digital environment requires determining when open-source software acts as “the underlying framework” for a networked system. Making that determination requires identifying which functions make some open-source software infrastructural in nature.
Infrastructure, broadly speaking, has long been included in the study of commons management.[46] Initially, industrial infrastructure featured prominently as the object of commons management discussion in both law and economics.[47] With the emergence of the internet, open-sourced software, and an increasingly networked economy, both legal scholars and economists began to explore the application of the law and economics of the commons to cyberspace.[48] In exploring the congruence between commons literature and the internet, Professor Yochai Benkler explained that the core element of a commons was “the absence of asymmetric power to determine disposition of a resource.”[49] Indeed, many scholars argued that the commons nature of the internet was the driving force behind the productivity and creativity exploding in cyberspace.[50] This analysis leads to a policy view that digital infrastructure, as commons, should be protected as open-access tools that can be used by everyone.[51]
To determine which open-source software to protect as commons because of their infrastructural nature, Professor Brett Frischmann proposed a paradigm for “identify[ing] and evaluat[ing] infrastructure resources functionally,” through the following three criteria:
(1) The resource may be consumed nonrivalrously for some appreciable range of demand. (2) Social demand for the resource is driven primarily by downstream productive activity that requires the resource as an input. (3) The resource may be used as an input into a wide range of goods and services, which may include private goods, public goods, and social goods.[52]
If a resource can be classified as infrastructure using these criteria, “then there are strong economic arguments that the resource should be managed in an openly accessible manner,”[53] leading to a legal approach to infrastructure resource technology that protects access to the open-source software and regulates individuals and entities conducting certain activity via the software.
By way of example, take the email protocol—the Simple Mail Transfer Protocol (SMTP).[54] The SMTP defines the rules by which one machine routes and sends a message to another machine.[55] SMTP can be used nonrivalrously by many people—nearly everyone sends email throughout the day, without any thought to whether others are also sending emails. Demand for use of SMTP is driven primarily by downstream commercial and personal activity[56]—we send emails to conduct business and to communicate with friends and family. As we do so, we very rarely consider the fact that our activity reflects a high level of demand for SMTP. Further, SMTP is used by actors as inputs into “a wide range of goods and services”[57] that includes the provision of corporate services (private goods), government services (public goods), and personal communication (social goods). Under Frischmann’s functional framework for identifying infrastructure resources, SMTP is a digital infrastructure resource.
Now, imagine you operate a health care company that delivers medical supplies to remote regions by drone. You hold a long-term vendor contract with a local manufacturer of drones, and regularly place orders for parts and replacement drones as needed to ensure continued delivery of medical supplies to your rural health care provider clients. The vendor, in turn, emails you a monthly invoice for goods delivered. The order and invoice process has become so routinized over time that you barely read the email delivering the invoice anymore, you just forward it to accounting for payment. Last month, as it turns out, the invoice came via email in the usual manner, but from a slightly altered email address, and instructed payment be made to a bank account other than one to which you normally direct payment. But you didn’t really notice these changes and you forwarded it to accounting as always, and accounting assumed that meant the payment was approved and sent a significant sum of your company’s money to the new bank account contained in the invoice. Several weeks later, you receive what you believe is a duplicate invoice from the vendor, only to realize the mistake—your company has been the victim of a business email compromise—or a BEC scam—and you directed payment to a fraudster.
You immediately report these events to the police, who, luckily enough, track down the fraudster and charge the fraudster with theft and wire fraud, and begin a wider investigation into the fraudster’s illegal activities. You deal with the recovery of funds through separate means, but you find the criminal action just and satisfying. The fraud that victimized you and your company, of course, was all perpetrated through the use of email, and email only works because of the digital resource infrastructure known as SMTP. The fraudster could not have stolen your money without SMTP enabling the operation of email. At no point, however, does it occur to you to try and prosecute the developers of the SMTP for building the tool used by the fraudster to perpetrate the scam, as they built a digital infrastructure resource and played no part in the use of that resource to commit fraud. Rather, the criminal law applies to the perpetrator of the BEC scam, not the digital tool—the digital infrastructure resource—that the perpetrator used as the medium for the scam.
Told as a story this way, the outcome makes intuitive sense. But the story also reflects the deeper theoretical point that digital infrastructure resources are traditionally regulated functionally—with the activity undertaken via the digital infrastructure serving as the object of regulation, and the infrastructure itself being preserved for open-access as a commons resource used by many people and entities for many different purposes.[58] Like their digital protocol predecessors, DLT protocols have been recognized as digital infrastructure resources,[59] and to understand why the application of financial regulation to such protocols makes so little sense, we first turn to the features and infrastructural functions of open-source Layer-1 DLT protocols and Layer-2 smart contract protocols.
A lot of linguistic confusion surrounds the various components of DLT.[60] This linguistic confusion often leads to the use of metaphors—sometimes apt, sometimes not—which are predominately relied upon during legislative and regulatory discussions.[61] As a result, regulatory enforcement actions often apply ill-fitting legal paradigms to technology that, as a matter of technical reality, do not perform regulated activity. To help counter some of the confusion sewn by inapt metaphors for blockchain protocols, this Section offers a brief introduction to blockchain technology, with an emphasis on Layer-1 DLT protocols and certain open-source Layer-2 smart contract protocols. The Section then reorients the discussion of open-source Layer-1 DLT protocols and Layer-2 smart contract protocols to consider their roles as digital infrastructure resources.
Generally speaking, DLT protocols enable decentralized digital activity via demonstrably provable, secure means. Indeed, at the most general level, DLT is a broad term that covers various distributed databases, including a specific type of database referred to as a blockchain protocol.[62] DLT protocols “assume[] the possible presence of malicious users (nodes)” and structure data processing with the goal of thwarting those nodes.[63] “A blockchain protocol—one type of distributed ledger—structures its data in a literal chain of blocks by linking blocks of validated transactions together using one-way cryptographic hashes.”[64] The architectural choices between using a DLT protocol broadly or a blockchain protocol specifically, along with choices among other specific features, vary widely among different protocols.[65] Although certain blockchain protocols are often held out as the archetypal protocols—Bitcoin and Ethereum—many other DLT protocols with very different features and goals exist.[66]
Nevertheless, DLT technology, as a general matter, is a protocol technology.[67] A protocol is “a set of instructions for the compilation and interaction of objects.”[68] In particular, a network protocol simply sets the rules that allow networked computers—nodes—to communicate with each other[69] like the protocols that keep the internet running,[70] or SMTP, the protocol that enables email communication.[71] Similarly, a DLT protocol “sets the rules that enable networked computers to track transitions in the global state of recorded data without a centralized third-party intermediary.”[72] DLT and blockchain protocols are commonly referred to as Layer-1 in what is conceptualized as a blockchain technology stack.[73] Conceptualizing DLT protocols as part of a stack of layered technologies is not a metaphor, but rather a technical reality that mirrors the layered model of the internet stack.[74] Traditionally, the internet is conceptualized as existing in five, or sometimes seven, layers.[75] The five layer model consists of a physical hardware layer, a link layer, a network layer, a transport layer, and an application layer.[76] In the blockchain technology stack, Layer-1 is the DLT or blockchain protocol that serves as the network layer, and Layer-2 encompasses additional software that operates on or interacts with the network.[77] Meanwhile, applications and user interfaces exist at higher layers of the stack.[78]
Just as the protocols that enable the internet and email serve as open-source infrastructure for digital life, DLT and blockchain protocols represent the next wave in open-source digital infrastructure development.[79] In particular, DLT and blockchain protocols offer the infrastructure necessary for users to record transitions in the state of globally recorded data without the intervention of a third-party intermediary.[80] Layer-1 DLT and blockchain protocols fit Professor Brett Frischmann’s definition of infrastructure.[81] Open-source DLT and blockchain protocols are nonrivalrous because anyone can record changes in state[82] to the protocol, and anyone—whether they have recorded a state change via the DLT protocol or not—can read the resulting data.[83] Most demand for open-source Layer-1 DLT protocols is for downstream productive use—examples of which include, but are not limited to: building decentralized applications,[84] operating decentralized autonomous organizations,[85] creating privacy protecting software,[86] supply chain management,[87] carbon credit tracking,[88] and identity verification.[89] Further, open-source Layer-1 DLT protocols fulfil Frischmann’s genericity requirement insofar as the downstream uses to which the protocols are put include private goods,[90] public goods,[91] and social goods.[92] Open-source Layer-1 DLT protocols, like the internet and email protocols before them, should be regarded as digital infrastructure resources for which open-access should be protected, while activity undertaken through that access serves as the object of regulation.[93]
Open-source Layer 2 smart contract protocols, for their part, also functionally operate as digital infrastructure resources. A smart contract is one type of computer program commonly deployed on a Layer-1 blockchain protocol.[94] When smart contracts are so deployed, the term smart contract really just refers to computer software that takes some action after receiving some pre-defined data,[95] and then reflects the resulting state change in the history of the blockchain protocol.[96] As a very general matter then, “smart contracts are computer code that says, ‘if data is received that X has occurred, Y will execute.’”[97] Creative developers use these computer programs in many ways, including as part of decentralized applications, decentralized organizations, and protocols that protect financial privacy for transactions conducted through blockchain protocols.[98] Indeed, many smart contracts are designed to be composable, meaning they solve a problem common to many developers and can be integrated into other smart contracts or applications.[99]
Open-source Layer-2 smart contract protocols represent only a subset of the technology often encompassed in a reference to “Layer-2.” Broadly speaking, Layer-2 protocols operate on top of a Layer-1 distributed ledger or blockchain protocol, but operate under different parameters that enable a reduction in the processing load borne by the Layer-1 distributed ledger or blockchain protocol.[100] The goal of many Layer-2 solutions is to improve some aspect of the Layer-1 protocol: improve scalability, reduce transaction costs, and enhance privacy.[101] Some uses of the term “Layer-2” in the broader DLT industry actually refer to off-chain scaling solutions.[102] Sometimes, however, a network of smart contracts operates as a protocol at Layer-2. Such smart contract protocols are often built on an open-source basis, with no third-party intermediary to manage their operations.
An example of one such Layer-2 smart contract protocol that has received a lot of recent attention is the Tornado Cash software. “Tornado Cash” refers to a set of smart contracts that interact with one another in ways that allow anyone conducting transactions via the Ethereum blockchain protocol (and theoretically other protocols) to enhance the privacy of their transactions.[103] Why would anyone want to enhance the privacy of their transactions on Ethereum? When an Ethereum user conducts routine transactions on Ethereum, those transactions are publicly recorded for anyone to see and data mine.[104] If an Ethereum user does not want what is the equivalent of masked versions of their bank account statements available for everyone to see, the user transacts funds to a Tornado Cash public key address that is operated by a pool and then withdraws them at a later time to a public key address different from depositing wallet’s public key address.[105] The depositing wallet is given a private key, which acts like a passcode or receipt insofar as the user may present the private key to the smart contract operated Tornado Cash pool at a later date as proof of the right to withdraw the deposited funds at a later time.[106]
One drawback of the Tornado Cash deposit and later withdrawal process, however, is that because anyone who executes a transaction on the Ethereum protocol must pay a transaction fee, every deposit to and withdrawal from a Tornado Cash smart contract requires a fee payment.[107] Paying the fee at initial deposit, and again at withdrawal risks revealing the pseudonymous identity of the user, making the increased privacy to be obtained by using Tornado Cash difficult to achieve. To try and solve for this technical obstacle to transactional privacy, users may choose to use a “relayer.”[108] Basically, the relayer uses its own pseudonymous identity to stand in for the Tornado Cash user in exchange for a fee by paying the Ethereum protocol transaction fee and transacting the funds the user originally deposited to whatever public key address the user designates.[109] In fulfilling this role, relayers merely pass on instructions to the Tornado Cash smart contracts; relayers never take custody or control over user deposits to the pools operated by smart contracts.[110] These technical features of the Tornado Cash software make it a digital infrastructure service. The Tornado Cash software is non-rivalrous in that anyone can use it to enhance the privacy of their transactions. User demand for the Tornado Cash software is not driven by the software itself, but by desires for transactional privacy to enhance user cybersecurity and, sometimes, physical safety.[111] The Tornado Cash software can be, and was in fact, integrated into other software offered as private goods,[112] but also served as a public good when, for example, enabling donations to individuals affected by the war in Ukraine,[113] and served the social good of protecting the fundamental human right to privacy.[114]
But instead of protecting access to the Tornado Cash software as commons-based digital infrastructure, the software was placed on the Office of Foreign Assets Control (OFAC) sanctions list,[115] and its developers were prosecuted.[116] Other open-source Layer-2 smart contract protocols have been targeted by the Commodities Futures Trading Commission (CFTC).[117] These actions reflect a fundamental flaw in efforts to apply regulation to open-source Layer-1 DLT protocols and open-source Layer-2 smart contract protocols: ignoring the function of the protocols as disintermediated digital infrastructure. Ultimately, the U.S. Court of Appeals for the Fifth Circuit ruled that OFAC exceeded its authority in placing the Tornado Cash smart contracts on the sanctions list because the smart contracts were not property of a sanctionable entity.[118] The Fifth Circuit made this determination by carefully considering the technical reality of the Tornado Cash smart contracts and determining that in no way did they function as legally enforceable contracts that could fall within the regulatory definition of “property” relied upon by OFAC.[119]
Instead, considering the function of the Tornado Cash software as a Layer-2 smart contract protocol, the Fifth Circuit determined the software could not be characterized as property that could be placed on the sanctions list because they were not property of any one person or entity in particular,[120] but rather, the Tornado Cash software served as Layer-2 digital infrastructure. The Fifth Circuit’s analysis represents a clear use of the functional approach that has characterized law’s interaction with open-source software up to this point, adapting it to the DLT context. But protocol developers and communities should not be forced to rely on ex-post correction of faulty regulatory actions. If regulators and lawmakers approached DLT through a functional method, the law could provide ex-ante clarity that would ultimately benefit both industry and consumers. Unfortunately, to date, regulators have largely taken the opposite approach—without assessing the function of the tools, regulators have insisted on applying a regulatory system designed to apply to entities that act as intermediaries to digital infrastructure that lacks any intermediary at all.[121] This fundamental mismatch does not serve stated policy aims and instead harms the legitimacy of legal and regulatory institutions.[122]
The fundamental nature of open-source Layer-1 DLT and blockchain protocols and open-source Layer-2 smart contract protocols rests in digital infrastructure for an emerging peer-to-peer digital economy—that is, a way for individuals to own, sell, and transfer property analogously to the way they do in most of the physical world, without requiring some sort of institutional oversight. Despite this fact, the use of inapt metaphors has led to the inappropriate application of financial regulation designed for intermediaries to computer code that has no intermediary. Frequently analogized to a ledger, many lawmakers and regulators conjure an image of a payments network when they think of DLT protocols,[123] when instead they should be thinking of sending an email or data over the internet.[124] Indeed, popular references to “blockchain transactions” often harken to financial transactions,[125] when, in fact, the computing activity undertaken by Layer-1 DLT protocols and Layer-2 smart contract protocols are more accurately “software operations.”[126] The constant analogies drawn between open-source Layer-1 DLT protocols and traditional financial systems wreak havoc on regulatory and legal policy discussions because the analogies ignore the differences in infrastructure and function between the two systems. Specifically, modern-day payment networks operate within a highly intermediated financial system.[127] Financial regulation, for its part, assumes the presence of intermediaries to serve as the object of regulation.[128] By investigating these dualling realities, this Part argues that when the existing regulatory paradigm is applied to open-source Layer-1 DLT protocols and open-source Layer-2 smart contract protocols, the results are suboptimal.
The modern regulatory apparatus aims to mitigate negative externalities caused by private actors pursuing their own benefit.[129] Financial regulation is no different. The traditional modern day financial system operates almost entirely through intermediaries[130] which operate to provide, allocate, and deploy capital.[131] Even as intermediaries fulfill these generalized capital funding functions, they also participate in “core financial functions, like asset aggregation, market making, risk management, and information clearing . . . .”[132] Financial intermediaries aggregate assets from multiple investors and make markets in order to make capital available to entities that can put it to productive use.[133] In terms of risk management, financial intermediaries, in a well-functioning market, will diversify their risk profile, thereby hedging against risk and improving their overall investment.[134] In properly functioning markets, financial intermediaries act as information clearinghouses, reducing information asymmetries between investors and issuers.[135] Properly fulfilling each of these functions, of course, assumes a properly functioning market. But financial intermediaries, as profit-seeking entities themselves, may engage in behavior that introduces new risk to the market, or causes market failures. Financial regulation aims to reduce the likelihood that financial intermediaries engage in activity that might contribute to such market risks and failures.[136]
Specifically, financial regulation targets negative externalities related to transaction costs,[137] information asymmetries,[138] risk complexity,[139] consumer exploitation,[140] systemic risk[141] and moral hazard.[142] Each of these risks is inherent to intermediaries. For example, markets rely on financial intermediaries to properly assess the risk of financial products, but as financial transactions and products become more complex, financial intermediaries themselves begin to rely on short-hand indicators of risk to make risk assessments.[143] If the indicator becomes faulty in some respect, but financial intermediaries fail to take notice or ignore the problem in pursuit of short-term gains, they can introduce deeper risk to the markets.[144] Indeed, many acknowledge the role of complexity risk in the events that led to the 2008 financial crisis.[145] In order to mitigate intermediary-related risks—and, ostensibly, avoid another 2008-like financial crisis—lawmakers increasingly, and nearly exclusively, craft regulations for financial services and capital markets participants that target intermediaries.[146]
Targeting financial regulation at intermediaries that aggregate capital and clear information related to transactions on a global scale also allows governmental surveillance of transactions in an attempt to prevent or otherwise detect and prosecute illicit financial transactions, including money laundering and terrorist financing.[147] The United States enacted the Bank Secrecy Act (BSA) in 1970[148] to “require institutions to maintain certain records the government could use to support criminal and tax evasion investigations.”[149] Congress would later amend the BSA to address white collar financial crimes, to better detect money laundering by identifying “suspicious activity,” and to account for new threats and new schemes as they arose.[150] To achieve these ends, the BSA requires financial institutions (a defined term that covers a variety of financial intermediaries) to file various reports about transactions they facilitate and the customers that undertake those transactions.[151] Because the BSA and its implementing regulations require reporting on the vast majority of transactions,[152] the BSA regime has come under fire for eroding privacy rights and acting as a financial surveillance dragnet that captures even law-abiding citizens.[153] Essentially, the BSA turns all financial institutions into financial intermediaries that double as surveillance tools.
Targeting financial regulation at intermediaries suffers from a fundamental flaw—namely, by tying regulation to a specific archetype of intermediated financial institution, the law fails to achieve its policy aims when the financial system undergoes periods of transformation and innovation.[154] To facilitate legal change that keeps pace with industry transformation, Professor Steven Schwarcz has argued for policymakers to consider functional financial regulation.[155] Functional regulation, for its part, requires “examining the functionality of a process or application without worrying about the details of its internal structure.”[156] Then, using the policy goals of financial regulation—namely, to prevent market failures that would interrupt the functions of the intermediated financial system—functional financial regulation would ask what market failures would impede the functions of the financial system.[157] For example, if regulators worry that the complexity of an emerging financial product might result in information asymmetry and rationality failure that will impede the function of a financial institution in aggregating funds for redistribution to firms that can put the funds to use, then regulation might require less use of benchmark data to assess the financial products.[158] Ultimately, functional regulation requires consideration of the function of the law and of the object of regulation. Only by considering them together can regulation be crafted effectively. The result, of course, is a regulatory system that eschews a one-size-fits all approach to law making and instead enacts fit for purpose regulation tailored to the function.
Fascinatingly, regulators initially took a functional approach to applying existing law to DLT protocols and smart contract protocols. For example, in 2019, the U.S. Department of Treasury’s Financial Crimes Enforcement Network (FinCEN) issued guidance that functionally applied the BSA and its implementing regulations.[159] Under the 2019 FinCEN Guidance, FinCEN used four functional criteria to determine whether a cryptocurrency wallet provided money transmission services: “(a) who owns the value; (b) where the value is stored; (c) whether the owner interacts directly with the payment system where the [cryptocurrency] runs; and, (d) whether the person acting as intermediary has total independent control over the value.”[160] Under those criteria, FinCEN instructed that hosted wallet providers acted as “account-based money transmitters that receive, store, and transmit [cryptocurrencies] on behalf of their accountholders,” while “[u]nhosted wallets are software hosted on a person’s computer, phone, or other device that . . . do not require an additional third party to conduct transactions,” and therefore were deemed outside the scope of the BSA and its implementing regulations.[161] Using similarly functional criteria, FinCEN also instructed that an “anonymizing services provider”—a “person[] that accept[s cryptocurrencies] and retransmit[s] them in a manner designed to prevent others from tracing the transmission back to its source”—acted as a money transmitter subject to the BSA regulations while “[a]n anonymizing software provider is not a money transmitter” because “FinCEN regulations exempt from the definition of money transmitter those persons providing ‘the delivery, communication, or network access services used by a money transmitter to support money transmission services” and open-source software—even if it anonymizes DLT activity—is digital infrastructure, not an intermediary with independent control over the value.[162]
However, a tendency to conflate centralized actors like the ill-fated FTX exchange and the related counterparty risk that led to fraud, theft and a string of cryptocurrency failures in the summer of 2022 with the DLT industry as a whole,[163] increasingly led to calls for stricter adherence to existing law—even when existing law did not fit the function undertaken by the technology.[164] As a result, the last several years saw the functional approach to regulating DLT protocols give way to an approach that forces laws designed for intermediaries—namely, financial regulation—onto systems in which no intermediaries exist—and which perform operations different in kind from financial transactions.[165] Even in an industry somewhat used to regulation by enforcement, the public outcry in response to this perceived overreach was swift and significant. Users of smart contract protocols sued the U.S. Department of Treasury for exceeding its authority by attempting to list software code on the economic sanctions list,[166] a cryptocurrency user sued the Internal Revenue Service alleging illegal collection of data related to cryptocurrency users,[167] artists sued the Securities and Exchange Commission to prove non-fungible tokens and digital art do not constitute securities,[168] two industry associations and a non-profit advocacy group sued the IRS alleging regulatory overreach by unduly broadening the definition of broker,[169] and a developer of an open-source and decentralized crowdfunding platform sued the Department of Justice for regulatory overreach.[170] A variety of companies,[171] academics,[172] and non-profit associations[173] filed amicus briefs[174] in support of these attempts by the public to reign in the regulatory insistence on intermediaries run amok.
Why would regulators so uniformly embrace an approach that undermines their own legitimacy[175] to such an extent that companies and individuals alike feel compelled to file lawsuits to vindicate individual rights? Perhaps the persistent regulatory adherence to finding an intermediary where none exists relates to the realization that the lack of intermediaries in open-source Layer-1 DLT protocols and open-source Layer 2 smart contract protocols “means that the traditional approach to [anti-money laundering/countering the financing of terrorism (AML/CFT)] regulation in which AML/CFT requirements are imposed on a private sector entity and compliance is monitored by supervisors, cannot be applied.”[176] Indeed, perhaps just as worries over clandestine Russian communications made PGP a target in the 1990s, worries about illicit finance made all disintermediated protocols a current target of regulatory wrath. Whatever the reason for the deep shift in regulatory approach, the attempt to crack-down on bad actors in the DLT ecosystem only really highlighted the many ways that applying existing intermediated financial regulation to open-source digital infrastructure characterized by open access, disintermediation, and genericity utterly fails to reduce the types of risks that financial regulation is designed to mitigate.
This Section explores the outcomes achieved by applying existing financial regulation to open-source Layer-1 DLT protocols and open-source Layer-2 smart contract protocols. Through the use of several case studies, this Section makes clear the mismatch inherent in applying regulation meant for financial intermediaries to digital infrastructure. In particular, this Section argues that the enforcement actions taken to date with respect to Layer-1 DLT protocols and Layer-2 smart contract protocols serve none of the regulatory policy aims the regulation was designed to address.
For our first case study, we turn to a decentralized exchange. In its purest form, no intermediary operates in the middle of decentralized exchange.[177] When the software that we often refer to as “a DEX” is truly decentralized, there is no intermediary called a DEX—“just software and an internet connection.”[178] One such protocol was called the 0x Protocol, and was a software tool enabling the decentralized exchange of cryptocurrencies.[179] Although a company called ZeroEx, Inc. developed the Layer-2 0x Protocol, the software itself “was a collection of smart contracts on the Ethereum blockchain” which the company “developed and deployed” but did not further control in any meaningful technical or business sense of control.[180] Indeed, the company ZeroEx, Inc. gave up its control over the software when it transitioned management over the protocol to the 0x protocol community of users.[181]
ZeroEx, Inc. did, however, create a website, “Matcha,” through which users could access the 0x Protocol.[182] ZeroEx, Inc. similarly exercised no measure of technical or business control over Matcha—the company did not interact with users, did not intermediate transactions for users, did not charge for the use of the website, and did not charge trading fees on transactions.[183] Yet, the Commodity Futures Trading Commission (CFTC) became concerned that “certain leveraged digital assets” traded via the 0x Protocol without complying with the relevant Commodities Exchange Act (CEA) requirements.[184] The difficulty for the CFTC in addressing its concern, of course, lies in the fact the CEA requirements are intended to apply to intermediaries that facilitate such trades in a centralized manner.[185] No such entity exists in the 0x Protocol.[186] This conflict of the old regime designed for intermediaries and the new disintermediated technology reflects the broader problem facing U.S. financial regulators—namely, that financial regulation applies to intermediaries.
Rather than attempt to adapt capital markets regulations to a disintermediated financial platform, regulators applied existing law—designed to apply to an intermediary—to the developer of the decentralized protocol. In an order dated September 7, 2023, the CFTC and ZeroEx entered into a settlement arrangement, ostensibly because ZeroEx created the website, Matcha.[187] The CFTC maintained the settlement was warranted because ZeroEx violated the CEA.[188] And yet, the ZeroEx action represented a stark departure from other capital markets enforcement activity in so far as the 0x Protocol was not specifically designed to support transactions that fall under CFTC jurisdiction, and was not specifically marketed as a way to avoid regulation by the CFTC.[189] Further, ZeroEx did not issue the offending tokens, did not approve or facilitate the listing of the offending tokens, did not make any profit from the trading of the offending tokens via the open-source protocol, and remained powerless to take the offending tokens out of circulation.[190] Further still, it could not prevent the actual creator of the offending tokens from recreating and relisting the tokens via another decentralized exchange tool or on a centralized exchange, nor prevent anyone else from creating an identical user interface, like Matcha, that would provide users the exact same access to the 0x Protocol.[191] Given that reality, the CFTC appears to have achieved little through its action against ZeroEx that advances its regulatory mandate.
In contrast, what could the CFTC have achieved if it had taken a functional approach to ZeroEx? The 0x Protocol community described 0x as “an open-source public good that serves as the underlying settlement layer for the global exchange of value.”[192] Further, the 0x community believed that eventually “the 0x Protocol [would] serve as a fundamental building block to a system that will provide individuals with greater sovereignty.”[193] To assess these claims, and whether they should have impacted the CFTC’s approach to the enforcement action, we first consider whether the 0x Protocol fits Frischmann’s three criteria for digital infrastructure. As an initial matter, the Layer-2 0x Protocol is nonrivalrous[194] in two important ways: first, as open-source software, the source code for the protocol was and is available for anyone to use in launching another similar protocol, and second, any specific instantiation of the 0x software launched on a DLT protocol can be used by anyone to execute software operations.[195] Further, the demand for the 0x Protocol is primarily driven by downstream productive activity—the creation and use of other tokens and applications.[196] Finally, the 0x Protocol, whether as source code or as a specific instantiation of the software, can be incorporated into other software and put to use for private, public and social purposes.[197]
Because the 0x Protocol functionally meets Frischmann’s criteria for digital infrastructure, the first policy priority should have been to preserve open access to the infrastructure. With that in mind, the CFTC could have taken different steps to maintain market integrity and transparency other than requiring that Matcha—which provided access to the 0x Protocol—be shuttered. For example, the CFTC could have required ZeroEx to require that issuers make disclosure statements on Matcha to explain new tokens listed on 0x using Matcha. The disclosures could serve as both an information tool for prospective purchasers of tokens listed on Matcha and as an information tool for the CFTC, to enable the CFTC to pursue the issuer of the tokens rather than the creator of the digital infrastructural resource. Alternatively, and more appropriately, the CFTC could have pursued enforcement actions against the issuers themselves. Such enforcement activity, of course, would be more expensive and time-intensive than pursuing ZeroEx, the obviously identifiable entity. That, however, is what financial regulation more appropriately required, and what would have actually achieved the policy aims of the CEA.
The CFTC also settled potential charges with the Deridex Protocol for similar violations of the CEA.[198] Notably, the Deridex Protocol was a Layer-2 smart contracts protocol operating on the Algorand blockchain.[199] Anyone could use the smart contracts to contribute margin or trade on a leveraged basis, and they could do so either through Deridex’s website or through direct interaction with the smart contracts.[200] Ultimately, the CFTC reasoned that because Deridex retained the capacity to update the smart contract code, it retained sufficient control over the Deridex Protocol to be treated as an intermediary to which the CEA requirements applied.[201] This conclusion is problematic as a matter of simple software development best practices, insofar as it discourages open source software developers from making smart contract software code upgradeable. The best interest of the software’s users demands a path for updating software code in the event that a software bug is identified. Ultimately, as with ZeroEx, it remains unclear how the settlement with Deridex furthers the policy goals of the CEA. Indeed, it appears to put open-source DeFi software developers in a bind: retain the capacity to upgrade code and face potential commodities regulation enforcement or intentionally make it impossible to upgrade software code, still face enforcement regulation (like ZeroEx), and face potential consumer protection or other liability if a software bug causes user losses. By insisting on finding an intermediary so that it could apply the CEA to the Deridex Protocol, the CFTC created a terrible double bind for developers while claiming that it had the authority to impose liability whether you could not upgrade the code (ZeroEx) or you could upgrade the code (Deridex).
If the CFTC had instead considered a functional regulatory approach, would the outcome have been different for Deridex? Deridex can be “consumed nonrivalrously for some appreciable range of demand”[202] because anyone who wanted to use the Deridex Protocol could bypass Deridex’s website and interact with it directly.[203] Further, users of the Deridex Protocol used it as a transaction management software for downstream productive activity—to help minimize risks and simplify operations[204] by providing cross-chain functionality for network flexibility, heightened data robustness, and enhanced efficiency.[205] Finally, Deridex smart contracts, as open-source software, could be used as component parts of other software—meaning that the Deridex Protocol also satisfies the genericity criteria for digital infrastructural resources. Indeed, perhaps the fact that the Deridex Protocol served as digital infrastructure made Deridex’s decision to retain the ability to upgrade smart contracts an important exercise in developer responsibility. In the traditional infrastructure and commons management literature, the question of who and how to maintain the commons infrastructure relied upon by many for public, private, and social goods represents one of the key issues of inquiry. If the CFTC had taken a functional approach to the application of the CEA to the Deridex Protocol, it would have recognized the protocol as digital infrastructure for which Deridex had volunteered to be one of the potentially many actors who contributed to the maintenance of the commons.[206]
As with ZeroEx, under a functional regulatory approach, Deridex should have been preserved as digital infrastructure, while issuers that violated the CEA by offering leveraged and margin-imbued tokens were more appropriately the true enforcement targets for undertaking noncompliant activity. Moreover, the “control” attributed to Deridex merely because they retained the software development capacity to upgrade the software and mend bugs would not have served as a regulatory enforcement trigger. Rather, maintaining the capacity to upgrade software in an open-source context would be encouraged by a functional regulatory approach that recognizes Layer-1 DLT protocols and Layer-2 smart contract protocols as digital infrastructure. Indeed, analyzing the CFTC’s action against the Deridex Protocol through a functional regulatory lens reveals that the functional regulatory approach can help regulatory agencies align their policy priorities. For example, by charting a path where retaining the capacity to upgrade software is not considered a CEA regulatory trigger, the functional regulatory approach helps align CFTC enforcement activity with broader policies of investor and consumer protection in the context of complex software. The ZeroEx and Deridex case studies demonstrate the power of a functional regulatory approach over current efforts to identify intermediaries in disintermediated systems where intermediaries do not exist. The next section considers how legislatures and regulators can operationalize functional regulation in practice.
The current architecture of financial regulation targets intermediaries and aims to change their behavior to mitigate risks posed by information asymmetry, customer exploitation, risk complexity, and moral hazard.[207] Attempting to apply those rules to disintermediated open-source protocols ignores the fact that such protocols serve as disintermediated digital infrastructure. Indeed, modern financial regulation’s focus on intermediaries fails to recognize that certain technical attributes of the code fulfill the risk mitigation function that the law plays in the U.S. financial market. This approach, unfortunately, inhibits innovation in financial and capital markets.[208] If the U.S. shifted to a functional regulatory approach—“examining the functionality of a process or application without worrying about the details of its internal structure” [209]—the regulatory apparatus could more nimbly respond to market risk while allowing for technological and other innovation.[210] This Section explores the contours of the traditional functional method in both the arena of financial regulation and in other contexts, and uses Layer 1 protocols as a case study through which to argue for a return to functional regulation of the DLT industry.[211] Recognizing the limitations of applying any single functional method developed in a different context, this Section proposes a framework of key principles reflected across three functional approaches to law for use by regulators and law makers as they make policy choices for new and emerging digital infrastructure resources.
Technological developments in the financial and capital markets have pushed the boundaries of regulation since as early as 1963.[212] Initially, financial and capital markets regulators embraced technology to make their own regulatory approaches nimbler and more sophisticated.[213] In the wake of the 2008 financial crisis and the 2010 flash crash, however, financial and capital market regulators became more skeptical of technological innovation.[214] The resulting regulatory structure has been criticized by economists and financial regulatory scholars as being too stagnant.[215] Financial regulation is stuck, and will fail to adequately address market failures, they argue, because the law is mapped to existing financial intermediaries.[216] Law could be more responsive to innovation in the market, and indeed, could enable greater innovation in the market without expecting greater risk, if financial regulation was instead tied to the functions performed by financial intermediaries.[217] The emergence of Layer-1 DLT protocols and the failure of traditional financial regulation with respect to those protocols represents further evidence that tying regulation to the existence of intermediaries undermines the efficacy of the legal system.
Layer-1 DLT protocols and decentralized Layer-2 smart contract protocols provide digital infrastructure for facilitating transactions but do not actually shoulder any of the policy, consumer protection, and illicit finance risks that financial regulation tries to mitigate. Such protocols do not generally aggregate capital in order to independently decide which firms can best put it to productive use.[218] Layer-1 DLT protocols and Layer-2 smart contract protocols also do not issue signals as to the merits of complex financial instruments—they do not serve as an information clearinghouse.[219] Because such protocols do not perform traditional financial intermediary market functions, they should not be regulated in the same way as financial intermediaries—the protocols do not pose the same risk, so they should not be subject to the same regulation and should not be expected to produce the same regulatory outcome.[220] Instead, to the extent law “regulates” open-source Layer-1 DLT protocols and Layer-2 smart contract protocols at all, it should be in accordance with the functions the protocols perform as digital infrastructure resources, leaving regulation to intervene with respect to individual actors using the protocol, as it does with any other form of digital infrastructure resource. Lawmakers, however, struggle to craft appropriate regulatory frameworks for DLT protocols for the same reason they struggle to keep pace with the ever-changing and increasingly complex financial marketplace: taking a functional approach sounds great, but it remains unclear how to operationalize the theory in every context.
By way of example, consider the issue of prosecuting the developers of non-custodial software as money transmitters. Recognizing that as a matter of technical reality, non-custodial software does not give control over customer assets to the person who crafted the software’s code, lawmakers introduced the Blockchain Regulatory Certainty Act (BRCA) on May 21, 2025,[221] and again on January 12, 2026.[222] The BRCA aims to provide a safe harbor for developers of non-custodial blockchain software from prosecution as money transmitters under 18 U.S.C. 1960.[223] The BRCA reaches a result that flows from a functional analysis—by considering the function performed by money transmitters and comparing it to the function of non-custodial software developers—and concludes that such developers do not undertake money transmission services because they serve different functions. However, the law itself is not an example of functional regulation. As originally written, instead of using functional language to describe the activity covered by the safe harbor, the BRCA used technology-specific terminology that arguably described activity and software the does not exist.[224] Even if such an error did not invalidate the safe harbor that the BRCA intended to provide, the problem with enacting a law that reflects the result of a functional analysis without actually enacting functional regulation is that the safe harbor is limited to the one very specific context of money transmission but would not come to the aid of open source developers that create protocols like 0x and Deredex. Eventually, new drafts of the BRCA resolved the issue of technical neutrality, and the BRCA does in fact represent a step in the right direction. However, the development of the BRCA make clear that even with all the recent attention on the fact that Layer-1 DLT protocols and Layer-2 smart contract protocols do not serve the same functions as financial intermediaries, well-meaning lawmakers and regulators struggle to adopt a methodology that would enable a new, functional form of regulation.
A variety of disciplines have, however, successfully deployed different methodologies that they might refer to as a “functional method.” Professor Frischmann, for example, built his functional definition of infrastructure on an economic approach to function.[225] Professor Schwartz similarly grounds his functional financial regulatory framework in the economic functions performed by financial intermediaries.[226] In law, the functional method is operationalized most successfully in two arenas: commercial law and comparative law. In commercial law, the Uniform Law Commission (ULC) and the American Law Institute (ALI) jointly undertake a functional approach when drafting and maintaining the Uniform Commercial Code (UCC).[227] Because the UCC provides the framework for commercial contracting, the ULC and the ALI map the rules it contains to the economic realities of transactions as they are undertaken in commerce.[228] They achieve this feat by engaging an exceptional number of stakeholders during any process that might result in UCC revisions, and by engaging in a detailed and instructive discourse about the factual realities facing actors in commerce.[229] While the process is diligent, thorough, and as inclusive as possible, the functional method used to craft and maintain the UCC does not move very quickly.[230] The measured pace of the commercial law approach to the functional method may pose certain disadvantages for addressing the fast pace of federal regulatory developments in the DLT space;[231] however, the principles underlying the commercial law functional method can be adapted to improve the regulatory enterprise.
In a separate context, the comparative law functional method considers elements of a legal system in light of the function that they serve in responding to a societal problem.[232] Importantly, comparative law starts by identifying the societal problem and then looks broadly for ways that the society in question has addressed this problem, recognizing that not all functional equivalents will be laws; rather, there may be “other institutions, legal or non-legal, that perform the same function.”[233] Comparative law also recognizes that when two societies address the same problem with law, they may do so through different areas of law altogether, and therefore comparative law views the functional method as a methodological tool for identifying when “different legal rules can play similar functions.”[234] “Functionalist comparative law compares systems by focusing on facts, such as the effects of rules, events, and judicial responses or decisions in response to real life situations.”[235] Functionalist comparative law then applies “the theory that [comparative law’s] objects must be understood in the light of their functional relation to society” to the facts present in the society or system being studied.[236] Together, this process of functional analysis allows the identification of doctrinally or institutionally different responses to the same problem that fulfill similar functions.[237] As with the commercial law approach to developing legal rules that reflect the function of transactions in commerce, the comparative law functional method grounds itself in the factual and social reality that affects different legal systems. This, in turn, resonates with the approach that internet scholars have taken in identifying digital infrastructure resources.
Indeed, more broadly, scholars also often use a functional frame when considering what law applies to issues at the intersection of law and emerging technology. For example, when scholars consider the intersection of artificial intelligence systems and law, they first recognize that artificial intelligence systems do not stand on their own as mere technical artifacts, but rather, such systems are built for and deployed in a specific social context.[238] Only by considering their socio-technical nature does the true function of an algorithmic system become clear.[239] And only by understanding the true function of an algorithmic system can the law anticipate how to mitigate any related risk.[240] This approach systematizes and crystalizes the two core inquiries that each of the other three disciplines (financial regulation, commercial law, and comparative law) ask in different ways when engaging in the functional method: (1) as a matter of technical reality, what function does the technological system serve, and (2) as a matter of policy and social values, what function does society need it to serve? Only when both the technical function of the system and the societal demands on how the technology should function are clearly identified can legislatures and regulators determine what function law can and should serve in relation to the technology. It is the failure of legislatures and regulators to engage in this inquiry that has led to the law’s failure to recognize Layer-1 DLT protocols and Layer-2 smart contract protocols as a foundational new wave of digital infrastructure and instead mistakenly apply regulation for intermediaries to systems where no intermediaries exist. Rectifying this policy mistake moving forward requires internalizing core principles of the functional approach that inform all the disciplines that use it when adopting regulation for Layer-1 DLT protocols and Layer-2 smart contract protocols.
Professor Schwarcz’s proposal for functional financial regulation revolves around the four micro-prudential functions of the financial intermediaries and concerns about preventing systemic risk at the macroprudential level.[241] The commercial law approach to drafting law from a functional perspective requires constant monitoring and updating that may prove difficult to achieve at the federal level.[242] The comparative law functional method, for its part, was created for work involving comparisons across legal systems,[243] making it an approach that may not map wholesale to designing functional regulation of DLT.[244] The broader questions asked about the technical function of the system and the functional needs of society with relation to the technical system help systematize the inquiries across each of the other three disciplines when considering how to regulate activity undertaken through Layer-1 DLT protocols and Layer-2 smart contract protocols. As a result of that process of systemization, this Section extrapolates from the functional method several policy principles that cross each of the disciplines in which the functional method is used that lawmakers can use to identify public digital infrastructure and then focus regulation on activity undertaken through such infrastructure. These principles should serve as policy guideposts for the new era of emerging technology that lawmakers now face.
Undertaking a functional regulatory approach requires fact-intensive inquiries that investigate the function of the object to be regulated,[246] the societal context in which the regulated object achieves that function,[247] the societal demands upon and values associated with that function,[248] and the risks that might prevent the regulated object from fulfilling its function and meeting the necessary societal demands placed on it while nevertheless upholding important related societal values.[249] When innovative and emerging technology disrupts functions traditionally fulfilled by long-standing institutional actors, policy makers can be tempted to view the changed function as more of a change in form rather than substance.
This has been the crux of the financial regulatory approach to the Layer-1 DLT protocols and Layer-2 smart contract protocols: an assumption, even after recognizing that they function differently than intermediaries at a purely technical level, that the protocols perform the same activity as traditional intermediaries, just in a different form.[250] So, for example, based on a belief that non-custodial wallet software performs the same functions as brokers, just through a different form, the Internal Revenue Service revised the definition of broker in its regulations so that anyone who provides a “trading front-end service” or “other effectuating services” must collect and report data even if done for free and even if done without actually taking custody of assets of any kind.[251] Doing so ignores the substantive differences between the functions served by non-custodial wallet software as opposed to those functions performed by custodial brokers.[252] Ultimately, ignoring these core difference creates a rule with which most non-custodial wallet software simply cannot comply as a matter of technical and functional reality.[253]
If regulators consider that the technical system might change the substance of activity in legally consequential ways rather than merely change the form through which the same function is achieved, they will also move beyond merely changing the form of regulation rather than the substance. As a matter of technical reality and societal demand, non-custodial wallet software serves the same function as a physical wallet that holds a person’s cash, debit, and credit cards.[254] The only person or entity capable of reporting data related to the use of the items held within the wallet is the person or entity in control of the wallet—in this case the person using the items within the wallet to conduct software operations on distributed ledger technology.[255] If the IRS wants individuals to report on every software operation conducted with the technical artifacts held in their non-custodial software wallets, the substance of the regulation must change to reflect the same approach the IRS uses to require reporting of barter and cash transactions. Failure to do so jeopardizes the future of important digital infrastructure resources including open-source non-custodial wallet software, Layer-1 DLT protocols, and Layer-2 smart contract protocols.[256]
A truly functional approach to DLT regulation applies the functional method to the substance of the regulation rather than the form. Doing so allows legislatures and regulators to craft rules that both address the functional risks associated with the actual function of new technology like non-custodial software wallets, while also preserving the important policy of open access for related digital infrastructure resources. Focusing on the substance of regulation rather than the form of regulation enables a holistic functional regulatory approach that can preserve multiple policy aims at once: preserving transactional autonomy, enhancing consumer protection, preventing illicit finance, enforcing tax obligations, and preserving open access to digital infrastructure resources.
Functional regulation should craft legal rules that are technology neutral and focus instead on regulatable activity.[257] Frischmann’s definition of infrastructural resources is technology neutral. It applies with equal force to describe industrial infrastructure as it does to describe digital infrastructure.[258] Similarly, the UCC drafters examine the functions of commercial practices and then craft rules that address those practices in technology neutral terms.[259] The benefit of taking a technology neutral approach is two-fold: (1) a technology-neutral approach forces lawmakers to truly understand the functional activity for which it seeks to craft legal rules; and (2) technology neutral rules enable a sort of legal future-proofing—the law will apply to any activity that performs the function irrespective of the tool used to aid in the activity.
The difficulty of the technology neutral approach is also two-fold, however. First, the technology-neutral approach to legal drafting has been criticized as leading to the use of overly abstract or archaic language in drafting statutory text. The UCC, for example, is often criticized for seemingly having been written in a different language—a technology neutral one.[260] The second difficulty of the technology neutral approach is that it requires a time intensive and demanding fact gathering process. The technology neutral approach only works if what the law describes in technology neutral language is an accurate description of the function achieved by the activity subject to the law. Despite these drawbacks, a technology neutral approach ensures strict adherence to the principle of reflecting the function of an activity in the substance of regulation rather than the form of regulation. One cannot be achieved well without the other.
The innovative nature of the technology and the industry will require lawmakers to consider whether and how new tools serve which functions. As lawmakers and regulators consider the function of Layer-1 DLT protocols and Layer-2 smart contract protocols, they will inevitably come to the determination that such protocols operate entirely in the background, enabling system functionality that: is available to anyone who wants to access it (e.g., available on a nonrivalrous basis), is used as a tool in achieving downstream productive activity, and supports a variety of public, private and social goods.[261] And yet, even when it has been confirmed that a given Layer-1 DLT protocol or a specific smart contract protocol serves as a digital infrastructural resource, the next step is to understand the societal demands placed on the infrastructure. Only at that point is it possible to determine the scope and content of relevant rules needed to mitigate any negative externalities that might prevent the technology from fulfilling the demands placed on it by social contexts.
When considered from this light, one of the challenges to implementing functional regulation is that the type of investigations required to take a deep-dive into both the technology and its uses requires a collaborative stakeholder-rich approach. Perhaps anticipating this and recognizing the usefulness of the functional approach, regulators and lawmakers are currently working to create spaces for stakeholder engagement and technology education.[262] These efforts signal the importance of increased innovation within regulators themselves to develop adequate technical expertise to achieve functional regulation. As Congress hears testimony about the efficacy of private-public partnership in creating regulatory technology (RegTech) solutions to address legal compliance in decentralized applications,[263] and as lawmakers both within the United States and overseas implement regulatory sandboxes,[264] it becomes clear that lawmakers and regulators are being pro-active in building their capacity to test functional regulation. Such innovative and collaborative stakeholder building efforts should be encouraged.
A key challenge to the functional regulatory approach is that it requires a certain level of expertise of lawmakers and their policy teams that may exceed their realistic time commitment capacity. First, the functional regulatory approach requires understanding Layer-1 DLT protocols and Layer-2 smart contract protocols at a sufficiently sophisticated level so as to be able to identify whether the demand for the protocol rests in characteristics internal to the protocol or rests in downstream applications being built on or with the protocol. Second, even if lawmakers can internally source this level of technical expertise, functionally regulating Layer-1 DLT protocols and Layer-2 smart contract protocols requires understanding the social context in which the protocols will be put to use. “Identifying the social context requires more than merely naming a context. A social context is composed of a variety of stakeholders, processes, rules, and other institutional forces (such as roles, statuses, hierarchies, power relations, and communication networks).”[265] Understanding the social context and its impact on the function of an emerging technology “requires understanding each of these components of the social system and the linkages between them.”[266] Practically speaking, however, how can lawmakers implement the functional regulatory approach given their time and resource constraints?
In order to achieve a truly functional analysis of both the technology and its social context, functional regulation should be undertaken through a legislative approach that appropriately empowers an existing regulator to promulgate rules in accordance with the Administrative Procedure Act.[267] More than mere rule-making, however, a functional regulatory approach would require broad stakeholder coalition building in order to foster relationships that enable trust. Trust building through coalition building is an important element for functional regulation because regulators are heavily dependent upon stakeholders for education in the technology realm and insight into the relevant social contexts. Further, regulators will only listen to comments submitted during the request for comments if they can ascribe a measure of trust to the person or entity submitting the comment.[268] Indeed, CFTC Commissioner Summer Mersinger, in dissenting from the orders on ZeroEx DAO and Deridex, “questioned whether enforcement actions were suitable…suggesting that rulemaking and stakeholder engagement might provide a more comprehensive approach.”[269] Specifically, Commissioner Mersinger “emphasized the need to balance regulatory oversight with fostering responsible innovation and stakeholder engagement.”[270]
The importance of building a coalition of stakeholders that can provide insight into the factual realities of how the technology functions in a given social context is reflected in one of the most active contexts that applies the functional method to legal rule drafting: the Uniform Commercial Code.[271] Whenever the Uniform Law Commission and American Law Institute begin an amendments project for the UCC, the meetings are open to the public, and members of the public can register to serve as “observers”—active participants in the uniform drafting process that provide key insight into how to structure new rules functionally.[272] These drafting coalitions work best when the observers and committee members trust each other. For example, the committee process that led to the adoption of the 2022 Amendments to the UCC involved a formal committee that worked alongside approximately 350 industry participants and lawyers serving as observers.[273] To replicate this kind of atmosphere at the federal level, regulations should be promulgated through an open notice and public comment period alongside open listening and dialogue sessions that allow stakeholders to elaborate on their policy recommendations, explain the technology in detail, and highlight how the social context in which the technology is put to use helps mold the function the technology serves when deployed.
Because digital infrastructure resources are open to, and depended upon by, everyone, when lawmakers and regulators identify open-source Layer-1 DLT protocols and Layer-2 smart contract protocols that serve the function of digital infrastructure, one of the societal demands placed on those protocols should be considered a highly important value worth protecting: open access to the infrastructure resource. Preserving open access to the infrastructure will also require a regulatory refusal to turn software development best practices (like retaining the ability to upgrade the software’s smart contracts) into regulatory jurisdictional hooks. Indeed, embracing functional regulation requires recognizing that the developers of the new wave of digital infrastructure resources are not intermediaries for regulatory purposes merely by writing and publishing code.[274] At least some courts are already adopting a functional method that leads them to effectively treat open-source Layer-1 DLT protocols and Layer-2 protocols as digital infrastructure. In Risley v. Universal Navigation, Inc, Judge Failla, siting in the Southern District of New York, determined that the “it defies logic that a drafter of computer code underlying a particular software platform could be liable under § 29(b) for a third-party’s misuse of that platform.”[275] But the DLT industry should not have to wait for the resolution of ex post disputes to confirm the principles of protecting blockchain digital infrastructure and confirmation that the engineers who built it are not imprisoned or otherwise held liable for creation of the infrastructure. Instead, lawmakers and regulators should adopt these five principles to help provide ex ante clarity in ways that go beyond one specific context like money transmission, but rather offer ex ante clarity for a large variety of activity that might be conducted using open-source public digital infrastructure.
Because open-source Layer-1 DLT protocols and open-source Layer-2 smart contract protocols represent the next wave of open-source digital infrastructure development, it is not at all surprising that they have been the subject of intense policy debates. Policy debates around the proper approach to road and bridge maintenance, intellectual property law reform, energy policy, network neutrality, and the internet have always sounded loudly in the halls of state and federal legislatures.[276] As Frischmann explained, the debates are loud, contentious, and prolonged because they are ultimately “a battle to control infrastructure resources, set the terms and conditions under which the public gets access, and determine how the infrastructure and various infrastructure-dependent systems will evolve over time.”[277] The stakes are just as high in the debate over what regulatory approach should be used for the DLT industry. The discussions over whether and how to regulate Layer-1 DLT protocols and Layer-2 smart contract protocols touch on important questions of fundamental rights, personal autonomy, national economic resiliency, and the future of U.S. innovation.
This Article argues that because open-source Layer-1 DLT protocols and open-source Layer-2 smart contract protocols are nonrivalrous, support demand from downstream productive uses, and exhibit genericity—the ability to be the foundation upon which other private, public and social goods are built—regulation should approach such protocols functionally and recognize their role in the new era of decentralized commerce as digital infrastructure. A functional regulatory regime that characterizes such protocols as digital infrastructural resources would protect public access to the protocols while targeting activity-based regulation toward those that use the protocols to conduct regulable behavior. While this Article’s proposal that a functional regulatory approach be applied to open-source Layer-1 DLT protocols and open-source Layer-2 smart contract protocols to achieve this outcome is novel, functional regulation of open-source protocols represents the historical norm. The United States has long taken a functional regulatory approach that recognizes open-source protocols as digital infrastructure while targeting regulation at specific behavior conducted through those protocols. The proposal in this Article merely suggests an extension of these policy priorities to the next wave of public digital infrastructure and develops a framework for doing so that recognizes the unique context of Layer-1 DLT protocols and Layer-2 smart contract protocols.
Importantly, developing this framework may have important consequences for other emerging digital architecture currently developing at a rapid pace. Specifically, developing a working functional regulatory approach for emerging and complex technologies has implications for other applications of emerging technology in commerce, including artificial intelligence. Applying the framework proposed in this Article to other emerging technologies, particularly those that, like digital asset technology, stand as a national strategic priority for economic resiliency and innovation, will enable regulatory clarity for the development of other foundational decentralized technical architectures beyond DLT protocols. The importance of identifying which elements of emerging technology serve as digital infrastructural resources and protecting access to them as such by using the functional method proposed in this Article to craft new law cannot be overstated. Correctly calibrating regulation to emerging technologies will help pave the way for such technologies as they become the backbone of new and strengthened commercial life in the United States, just as PGP formed the backbone of new and strengthened expectations for privacy in the internet age.
* Associate Professor of Law, SMU Dedman School of Law; Faculty, Institute for Cryptocurrency and Contracts; Affiliated Faculty, Indiana University Bloomington Ostrom Workshop Program on Cybersecurity and Internet Governance; Research Associate, University College London Center for Blockchain Technology. JD, LLM, MPP, Duke University; BA, Whitworth University. My co-author and I would like to thank Nilmini Rubin, Gregory Schnieder, and Amy Whitsel for their feedback and comments on early drafts of this Article. ORCID ID: 0000-0002-2448-8309 ↑
First, if a decentralized exchange is truly decentralized . . . then grammatically it’s an action not a thing, a verb and not a noun: I make a decentralized exchange; not, I use a decentralized exchange. When I use free software and an open blockchain network to trade one token for another directly with another trader, then I am engaged in decentralized exchange — an action, just as I might engage in running or paying.
Id. ↑