The Blockchain Regulatory Certainty Act of 2026: Protecting Open-Source Code from Financial Regulation
The US crypto landscape is facing a critical juncture. Two senators have introduced a short, five-page bill with a potentially massive impact: to prevent US law from treating developers and publishers of blockchain software as traditional money transmitters. The Blockchain Regulatory Certainty Act of 2026 aims to clarify that those who build and maintain blockchain infrastructure – those without the legal right or ability to unilaterally control user funds – should not be subjected to the same regulations as financial institutions. This is a debate crypto has been waging for years, often framed in abstract terms of decentralization. However, recent legal challenges and aggressive prosecution are raising the stakes, making legislative clarity more urgent than ever.
The Growing Threat to Crypto Developers
The core issue stems from how US law defines and regulates payments. FinCEN (Financial Crimes Enforcement Network), the Treasury bureau responsible for anti-money laundering (AML) rules, treats many payment intermediaries as Money Services Businesses (MSBs). MSBs face stringent requirements: registration, AML program implementation, Suspicious Activity Report (SAR) filing, and record-keeping. The concern is that a broad interpretation of “money transmission” could inadvertently criminalize developers simply for creating and publishing open-source code.
In a 2024 letter to Attorney General Merrick Garland, Senators Cynthia Lummis and Ron Wyden warned that an expansive view of money transmission law “threatens to criminalize Americans offering non-custodial crypto asset software services.” The new bill is a direct response to this warning, attempting to translate it into a concrete legal rule. Recent cases, like the prosecution of Tornado Cash co-founder Roman Storm and the sentencing of Samourai Wallet developers, demonstrate the real-world consequences of this ambiguity.
The Tornado Cash and Samourai Cases: A Warning Sign
The US Justice Department’s prosecution of Roman Storm highlighted the fear that writing software could be equated to operating a financial business, even without holding customer funds. The DOJ argued Tornado Cash functioned as a money transmitter and should have implemented compliance controls. The jury delivered a mixed verdict in 2025, convicting Storm on a conspiracy charge related to unlicensed money transmission, but deadlocking on more serious counts. Similarly, the sentencing of developers involved with Samourai Wallet sent a chilling effect through the developer community.
These cases underscore a fundamental mismatch: existing regulatory architecture, designed for traditional financial intermediaries like Western Union, struggles to adapt to the nuances of open-source code, decentralized networks, and software where the publisher never directly handles customer funds. The question isn’t just about compliance; it’s about whether creating foundational infrastructure for a new technology should be treated as a financial crime.
Understanding Money Transmission Law
At the federal level, 18 U.S.C. § 1960 criminalizes knowingly operating an unlicensed money transmitting business. This “unlicensed” status can be triggered by failing to register federally, violating state licensing requirements, or facilitating transactions linked to illegal activities. However, state regulations add another layer of complexity. Even if a business believes it’s exempt from federal rules, state money transmitter licensing can be costly, time-consuming, and inconsistent.
For startups handling customer funds, navigating this landscape is challenging but familiar. However, for developers publishing open-source wallet code, running node services, or maintaining infrastructure, the prospect of being subjected to the same licensing regime as a remittance shop feels both absurd and existential. The core argument is that these developers don’t control the assets; they simply provide the tools for users to manage their own funds.
The “Non-Controlling” Developer: A Key Distinction
The Blockchain Regulatory Certainty Act of 2026 attempts to formalize this distinction. The bill defines “covered developers or providers” as those who create, publish, or maintain software facilitating a distributed ledger. It also broadly defines “distributed ledger service” to encompass systems enabling users to send, receive, exchange, or store digital assets.
The central concept is the “non-controlling” developer or provider. The bill asserts that if you don’t control the assets, can’t unilaterally move them, and lack the legal right to seize them, you shouldn’t be treated as a money transmitter under federal law. This aims to codify a principle FinCEN’s 2019 guidance already acknowledges: the distinction between the toolmaker and the transmitter. However, guidance isn’t law, and it can be reinterpreted or ignored.
Why a Statutory Safe Harbor is Crucial
FinCEN guidance, while helpful, lacks the force of a statutory safe harbor. A bill like this would provide developers with a clear legal framework, reducing uncertainty and encouraging innovation. It also addresses the risk of state-level regulations that may interpret money transmission laws more broadly. The Lummis-Wyden letter emphasized that Congress intended to capture actors who *accept* customer funds, not those who simply publish code.
The Nuances of “Control” and the Future of Regulation
While the “non-controlling” line seems straightforward, the reality is more complex. The hardest cases lie in the gray areas where control is shared, indirect, or exercised through design. Consider developers who deploy smart contracts with upgradeable admin keys, or teams controlling front-end interfaces and transaction routing. The further you move from pure publishing towards operational discretion, the greater the risk of being classified as a financial intermediary.
The bill’s focus on “unilateral ability” and “legal right” is crucial. It aims to protect developers who genuinely lack the power to move or seize user funds while still allowing enforcement against those who do. However, the interpretation of “non-controlling” will be critical. Systems often blend open-source components with hosted services, admin dashboards, and managed interfaces, creating ambiguity.
Legislative Context and Broader Market Structure
A similar bill, the Blockchain Regulatory Certainty Act, was introduced in the House in 2025. The Senate version arrives amidst broader discussions about market structure, AML regulations for DeFi, and the appropriate regulatory framework for stablecoins. In this context, developer protections could become a bargaining chip or a principled boundary.
What Happens Next?
The introduction of a bill doesn’t guarantee its passage. Often, these proposals serve as signals, informing agencies about lawmakers’ priorities and providing a framework for lobbying efforts. The proposal is a standalone push for developer protections as the Senate prepares to unveil a broader market structure proposal, highlighting the ongoing debate over definitions and jurisdiction.
Even if the bill doesn’t pass quickly, it narrows the narrative space for prosecutors and regulators. Introducing a definition like “non-controlling” into legislative text creates a reference point for legal arguments. This has been observed in other crypto fights, where even failed proposals influence the broader interpretive ecosystem.
Furthermore, the bill incentivizes compliance design. If the legal boundary is control, system architects will prioritize minimizing control, potentially removing admin keys, decentralizing interfaces, and clarifying contractual limitations on developer authority. This creates a trade-off: increased legal safety may come at the cost of responsiveness to hacks, bugs, and governance crises.
Ultimately, the Blockchain Regulatory Certainty Act of 2026 represents a crucial step towards clarifying the legal status of crypto developers. It acknowledges the fundamental difference between writing code and moving money, and seeks to protect open-source infrastructure from being regulated out of existence. The outcome will likely be complex, reflecting the inherent messiness of the real world, but the bill sets the stage for a more rational and innovation-friendly regulatory environment.
Mentioned in this article
Tornado Cash
Cynthia Lummis
Roman Storm
Posted In: US, Analysis, Featured, Legislation, Regulation
Author: Andjela Radmilac, Senior Analyst • CryptoSlate