The emergence of writing open-source code as an existential threat and the five-page legislation aimed at addressing it.

Two senators have put forth a concise bill with a remarkably ambitious goal: to prevent US law from categorizing individuals who write and distribute blockchain software as if they were operating a clandestine payments business.

The measure, known as the Blockchain Regulatory Certainty Act of 2026, seeks to clarify that “non-controlling” developers and infrastructure providers (i.e., those who lack the legal authority or unilateral capability to transfer others’ funds) should not be classified under the legal framework meant for money transmitters.

This has been a point of contention in the crypto community for several years, albeit often articulated in the vague terms of decentralization and autonomy.

However, the implications have become increasingly difficult to overlook. Prosecutors have pursued aggressive liability theories in prominent cases involving non-custodial tools, while developers have observed as a hodgepodge of federal regulations and state licensing frameworks turned compliance into a perplexing endeavor.

In a 2024 correspondence to Attorney General Merrick Garland, Senators Cynthia Lummis and Ron Wyden cautioned that a broad interpretation of money-transmission law “threatens to criminalize Americans providing non-custodial crypto asset software services.”

The proposed legislation aims to transform that caution into a formal regulation.

Related Reading

Zcash and privacy protocols face a “do-or-die” SEC meeting that determines if developers are personally liable for code

With Samourai’s November sentencing and Tornado Cash’s mixed verdict, the SEC’s Dec. 15 privacy roundtable marks a new chapter for wallet privacy and exchange compliance.

Dec 6, 2025 · Gino Matos

The broader issue is that outdated regulatory frameworks, designed for Western Union-style wiring and prepaid cards, are struggling to adapt to open-source code, decentralized networks, and software that can be utilized without the publisher ever handling customer funds.

When code translates to conduct

To grasp why a developer might be concerned about being labeled a “money transmitter,” one must begin with how the US regulates payments.

At the federal level, FinCEN, the Treasury department responsible for anti-money-laundering (AML) regulations, classifies many payment intermediaries as money services businesses (MSBs).

MSBs are required to register, implement AML programs, file suspicious activity reports, and maintain records.

FinCEN’s 2019 guidance states the principle clearly: Money transmission entails accepting and transmitting “value that substitutes for currency,” regardless of whether the value is transferred via a bank wire, an application, or a blockchain transaction.

Additionally, there is a criminal statute, 18 U.S.C. § 1960, which criminalizes the operation of an unlicensed money transmitting business.

The “unlicensed” aspect can be triggered in various ways: by failing to register federally when mandated, by breaching state licensing requirements, or by transmitting funds tied to illegal activities.

States have more influence here than many outsiders realize. Even if a business believes it falls outside federal MSB regulations, state money-transmitter licensing can still impose significant challenges, which can be costly, slow, and inconsistent.

Some states broadly interpret their statutes, while others provide clearer exemptions.

For a startup that deals with customer funds, this scenario is painful and ultimately familiar.

Related Reading

Vibe coding, no-code, and the new rules of web3 development

Eric Chen and the Injective team are employing vibe coding to redefine how software is created, developed, and delivered in web3.

Nov 23, 2025 · Christina Comben

However, for a developer who releases open-source wallet code, operates a node service, or maintains infrastructure for others, the notion that they could be forced into the same licensing framework as a remittance agency feels both absurd and critical.

This tension has been evident in the legal battles surrounding privacy tools and DeFi.

The US Justice Department’s prosecution of Tornado Cash co-founder Roman Storm helped crystallize a concern that has loomed over crypto for the past decade: that writing software could be equated to running a financial enterprise, even when the software itself doesn’t manage customer funds.

The Justice Department has contended that the service operated similarly to a money transmitter and should have enforced compliance measures.

Storm’s defense has highlighted the autonomy of the code and the absence of custody over users’ funds.

The case did little to clarify the policy debate, instead serving as fuel to an already raging fire.

A jury delivered a mixed verdict in 2025, convicting Storm on an unlicensed money-transmission conspiracy charge while deadlocking or acquitting on more serious allegations.

Related Reading

Jury convicts Roman Storm on unlicensed money transmission; hung on laundering, not guilty on sanctions

After a brief deadlock, the jury found Storm guilty of conspiring to operate an unlicensed money transmitting business.

Aug 6, 2025 · Gino Matos

Crypto proponents interpret the outcome as a cautionary signal for developers of non-custodial systems.

In this context, Lummis and Wyden’s bill is best understood as an effort to draw a distinct line between two domains: software publishing and fund custody.

The “non-controlling” distinction

The bill itself is concise, spanning just five pages, yet it is packed with definitions, as definitions are where regulation resides.

Initially, it outlines who qualifies as a covered “developer or provider”: essentially, anyone who creates or publishes software that enables a distributed ledger or provides maintenance for it, or offers a service associated with a distributed ledger.

It also broadly defines “distributed ledger service” to encompass systems that allow users to send, receive, exchange, or store digital assets.

Then it introduces the pivotal concept: a “non-controlling” developer or provider.

The bill’s central assertion is that if you do not control the assets, cannot unilaterally transfer them, and lack the legal authority to seize them, you should not be classified as a money transmitter under federal money transmission legislation.

In practice, this aims to formalize a distinction that regulators already tend to favor, though they often leave it vague in application.

FinCEN’s 2019 guidance notes that an individual fulfilling a specific role in developing or selling a software application may differ from the individual using the application to accept and transmit value.

The compliance responsibility attaches to the transmitter, not necessarily the creator.

Why isn’t that sufficient? Because FinCEN guidance does not equate to a statutory safe harbor.

Guidance can be reinterpreted, narrowed, or simply disregarded by a different agency in another context.

Developers are also concerned about what occurs when federal ambiguity intersects with state licensing laws, or when criminal prosecutors explore expansive interpretations of what it means to “conduct” a money transmitting business.

This is why the 2024 Lummis-Wyden letter emphasized the term “accepting,” arguing that Congress intended to encompass actors who actually receive customer funds, not those who publish code that enables individuals to move their own assets.

Related Reading

Senator Lummis pushes tax break for small Bitcoin payments. Could it unlock everyday adoption?

By easing tax regulations, Senator Lummis aims to transition Bitcoin from an investment tool to a daily currency.

Oct 9, 2025 · Oluwapelumi Adejumo

If you seek the practical promise of the bill, it is this: to create a safer environment for engaging in the mundane, essential tasks that crypto relies on (maintaining wallet software, publishing open-source libraries, managing infrastructure that facilitates transactions) without the constant anxiety of inadvertently becoming a regulated financial intermediary.

However, the distinction is not as straightforward as custody versus non-custody.

The most challenging cases occupy the gray area, where the “control” mentioned in the bill is shared, indirect, or exercised through design.

Consider a developer who deploys smart contracts that can be upgraded, paused, or modified with admin keys, or a team that governs a front-end interface, establishes fees, and has discretion over the routing or prioritization of transactions.

The closer one gets to ongoing operational discretion, the more a prosecutor or state regulator may argue that they are not merely providing software, but rather running a service.

This is why the bill’s emphasis on unilateral ability and legal authority is crucial.

It seeks to maintain a distinction for enforcement against actors who genuinely can move or seize user funds while protecting those who cannot.

Whether it achieves this will hinge on how clearly the term “non-controlling” aligns with real-world systems that often blend open-source components with hosted services, admin interfaces, and managed endpoints.

There is also a legislative subtext.

A similar concept has circulated in the House: a Blockchain Regulatory Certainty Act was introduced in 2025, which would offer a safe harbor for non-controlling developers and service providers.

The Senate version emerges at a time when lawmakers are also grappling with broader market-structure issues, such as who regulates what, how AML should apply to DeFi, and whether stablecoin frameworks should resemble banking rules or securities laws.

In this context, developer protections can serve as either a principled boundary or a negotiation tool.

Related Reading

Why developers are calling latest Bitcoin code “malware”

Bitcoin Core’s v30 update expands on-chain data use, dividing the community over innovation versus bloat.

Oct 13, 2025 · Oluwapelumi Adejumo

What lies ahead

The stark reality in Washington is that introduction does not guarantee passage.

Bills like this often act as signals: they indicate to agencies how lawmakers prefer a problem to be framed, provide lobbyists with a text to rally around, and establish a negotiating stance in a larger package.

This proposal is a standalone effort to secure developer protections as the Senate approaches a more extensive market-structure announcement, serving as a reminder that the struggle over definitions is occurring alongside the battle over jurisdiction.

Lummis’s own press release explicitly emphasizes that it aims to protect developers and infrastructure providers who do not control user funds from being classified as money transmitters under federal law.

The most pertinent question here is what this bill changes, even if it does not pass swiftly.

One response is that it constrains the narrative space available to prosecutors and regulators.

When senators embed a definition into legislative text, such as incorporating “non-controlling” into a statutory framework, they create a reference point that defense attorneys, industry associations, and judges can reference to argue what Congress intends the law to signify.

This has been evident in other crypto disputes, where legislative proposals, even unsuccessful ones, become part of the broader interpretive landscape.

Another response is that it compels a more focused discussion about compliance design.

If the future legal boundary is control, then system designers will be motivated to minimize control.

This could involve eliminating admin keys, restricting upgradeability, decentralizing interfaces, or clearly indicating, both technically and contractually, that a developer cannot unilaterally move assets.

It also introduces a new kind of risk tradeoff: the more one reduces control for legal safety, the more challenging it may become to react promptly to hacks, bugs, and governance crises.

For the public, the bill serves as a window into a quieter transformation.

The initial crypto argument was that software is neutral, with users responsible for their actions.

The contemporary regulatory counterargument is that tools can be crafted to enable abuse, and that profit, governance, and operational involvement can transform that neutral code into a managed service.

The 2026 bill represents an effort to safeguard a space for open-source infrastructure to exist without being legislated out of existence, while still permitting punishment of actual intermediaries who manage others’ money.

The outcome will likely be complex, as is the nature of the real world.

Wallets can be self-custodial but default to hosted routing. Decentralized protocols can have small groups wielding significant influence.

Interfaces can be open-source yet controlled through domains, app stores, and curated endpoints.

Regulators are aware of this, and so are developers.

The next phase of crypto regulation will be determined by who controls the mechanisms that transfer value and whether Congress can formulate rules that differentiate between a tool, a service, and the ambiguous area in between.

If Lummis and Wyden achieve their objective, at least one distinction will be clearer than it is today: writing code is not equivalent to transferring money.

The post Why writing open-source code is suddenly an existential risk, and the five-page bill designed to fix it appeared first on CryptoSlate.