Two senators have introduced a short bill with an unusually big ambition: to stop US law from treating people who write and publish blockchain software as if they were running a shadow payments company.
The proposal, titled the Blockchain Regulatory Certainty Act of 2026, aims to clarify that “non-controlling” developers and infrastructure providers (i.e., those who don’t have the legal right or unilateral ability to move other people’s funds) should not be swept into the legal bucket reserved for money transmitters.
It’s an argument crypto has been making for years, unfortunately, often in the abstract language of decentralization and autonomy.
But the stakes have become harder to ignore. Prosecutors have tested aggressive theories of liability in high-profile cases involving non-custodial tools, and builders have watched as a patchwork of federal rules and state licensing regimes turned compliance into a guessing game.
In their own 2024 letter to Attorney General Merrick Garland, Sens. Cynthia Lummis and Ron Wyden warned that a broad interpretation of money-transmission law “threatens to criminalize Americans offering non-custodial crypto asset software services.”
The new bill tries to turn that warning into a rule.
The deeper story is that old regulatory architecture, written for Western Union-era wiring and prepaid cards, is straining to map itself onto open-source code, decentralized networks, and software that can be used without the publisher ever touching customer funds.
When code becomes conduct
To understand why a developer might care about being labeled a “money transmitter,” you have to start with how the US polices payments.
At the federal level, FinCEN, the Treasury bureau responsible for anti-money-laundering (AML) rules, treats many payment intermediaries as money services businesses (MSBs).
MSBs must register, run AML programs, file suspicious activity reports, and keep records.
FinCEN’s 2019 guidance lays out the principle in plain terms: Money transmission involves accepting and transmitting “value that substitutes for currency,” and it doesn’t matter whether the value is moved through a bank wire, an app, or a blockchain transaction.
Layered on top is a criminal statute, 18 U.S.C. § 1960, that makes it an offense to knowingly operate an unlicensed money transmitting business.
That “unlicensed” piece can be triggered in multiple ways: by failing to register federally when required, by violating state licensing requirements, or by transmitting funds connected to unlawful activity.
States matter here more than many outsiders realize. Even if a business believes it’s outside federal MSB rules, state money-transmitter licensing can still bite, and it can be expensive, slow, and inconsistent.
Some states interpret their statutes broadly, while others offer clearer exemptions.
For a startup that touches customer funds, this is painful and ultimately familiar.
But for a developer who publishes open-source wallet code, runs a node service, or maintains infrastructure other people use, the idea that they might be forced into the same licensing regime as a remittance shop feels both absurd and existential.
That tension has been on display in the legal fights around privacy tools and DeFi.
The US Justice Department’s prosecution of Tornado Cash co-founder Roman Storm helped crystallize a fear that has hovered over crypto for a decade: that writing software could be treated as operating a financial business, even where the software itself doesn’t hold customer money.
The Justice Department has argued that the service functioned like a money transmitter and should have implemented compliance controls.
Storm’s side has emphasized the autonomy of the code and the lack of custody over users’ funds.
The case did nothing to resolve the policy debate, acting instead as fuel to an already roaring fire.
A jury delivered a mixed outcome in 2025, convicting Storm on an unlicensed money-transmission conspiracy charge while deadlocking or acquitting on more serious counts.
Crypto advocates read the result as a warning flare for developers of non-custodial systems.
Against that backdrop, Lummis and Wyden’s bill is best understood as a bid to draw a bright line between two worlds: software publishing and funds custody.
The “non-controlling” line
The bill itself is compact, coming in at just five pages, but it’s dense with definitions, because definitions are where regulation lives.
First, it defines who counts as a covered “developer or provider”: essentially, anyone who creates or publishes software that facilitates a distributed ledger or provides maintenance to it, or offers a service associated with a distributed ledger.
It also defines “distributed ledger service” broadly enough to include systems that enable users to send, receive, exchange, or store digital assets.
Then it introduces the key concept: a “non-controlling” developer or provider.
The bill’s core claim is that if you don’t control the assets, can’t unilaterally move them, and don’t have the legal right to seize them, you shouldn’t be treated as a money transmitter for the purposes of federal money transmission laws.
In practice, that’s an attempt to formalize a distinction regulators already lean toward, but often leave fuzzy in application.
FinCEN’s 2019 guidance notes that a person performing a certain role in developing or selling a software application can be different from the person using the application to accept and transmit value.
The compliance obligation attaches to the transmitter, not necessarily the toolmaker.
Why isn’t that enough? Because FinCEN guidance is not the same as a statutory safe harbor.
Guidance can be reinterpreted, narrowed, or simply ignored by a different agency in a different context.
Builders also worry about what happens when federal ambiguity meets state licensing statutes, or when criminal prosecutors test expansive readings of what it means to “conduct” a money transmitting business.
That’s why the 2024 Lummis-Wyden letter leaned on the term “accepting,” arguing that Congress meant to capture actors who actually receive customer funds, not those who publish code people use to move their own assets.
If you’re looking for the bill’s practical promise, it’s this: to make it safer to do the boring, foundational work crypto runs on (maintaining wallet software, publishing open-source libraries, operating infrastructure that relays transactions) without waking up to the existential question of whether you’ve accidentally become a regulated financial intermediary.
But the line is not as simple as custody versus no custody.
The hardest cases live in the middle, where the “control” the bill refers to is shared, indirect, or exercised through design.
Consider a developer who deploys smart contracts that can be upgraded, paused, or parameter-changed with admin keys, or a team that controls a front-end interface, sets fees, and has discretion over which transactions are routed or prioritized.
The farther you move from pure publishing and closer to ongoing operational discretion, the more a prosecutor, or a state regulator, may argue that you’re not just providing software, you’re running a service.
That’s why the bill’s focus on unilateral ability and legal right is so important.
It tries to preserve room for enforcement against actors who actually can move or seize user funds while giving cover to those who can’t.
Whether it succeeds will depend on how clearly the term “non-controlling” maps onto real-world systems that often mix open-source components with hosted services, admin dashboards, and managed interfaces.
There’s also a legislative subtext.
A similar idea has circulated in the House: there’s a Blockchain Regulatory Certainty Act bill introduced in 2025 that would provide a safe harbor for non-controlling developers and service providers.
The Senate version arrives at a moment when lawmakers are simultaneously wrestling with broader market-structure questions, including who regulates what, how AML should apply to DeFi, and whether stablecoin regimes should look more like banking rules or securities rules.
In that context, developer protections can become either a principled boundary or a bargaining chip.
What happens next
The hard truth about Washington is that introduced doesn’t equal passed.
Bills like this often function as signals: they tell agencies how lawmakers want a problem framed, they give lobbyists a text to rally around, and they stake out a negotiating position in a larger package.
The proposal is a standalone push to lock in developer protections as the Senate nears a broader market-structure unveiling, a reminder that the fight over definitions is happening in parallel to the fight over jurisdiction.
Lummis’s own press release explicitly frames it as protecting developers and infrastructure providers who don’t control user funds from being treated as money transmitters under federal law.
The most useful question here is what this bill changes, even if it doesn’t pass quickly.
One answer is that it narrows the narrative space prosecutors and regulators can occupy.
When senators put a definition into bill text, like writing “non-controlling” into a statutory frame, they create a reference point that defense attorneys, industry groups, and judges can cite to argue what Congress thinks the law should mean.
That has been visible in other crypto fights, where legislative proposals, even failed ones, become part of the broader interpretive ecosystem.
Another answer is that it forces a sharper conversation about compliance design.
If the future legal boundary is control, then system architects have incentives to minimize control.
That could mean removing admin keys, limiting upgradeability, decentralizing interfaces, or making it clear, both technically and contractually, that a developer cannot unilaterally move assets.
It also creates a new kind of risk tradeoff: the more you minimize control for legal safety, the harder it may be to respond quickly to hacks, bugs, and governance crises.
For the public, the bill is a lens into a quieter shift.
The early crypto argument was that software is neutral, and users are responsible for their actions.
The modern regulatory pushback is that tools can be designed to facilitate abuse, and that profit, governance, and operational involvement can turn that neutral code into a managed service.
The 2026 bill is an attempt to preserve a space for open-source infrastructure to exist without being regulated out of existence, while still leaving room to punish actual intermediaries who handle other people’s money.
The outcome will likely be messy because that’s how the real world is.
Wallets can be self-custodial but default to hosted routing. Decentralized protocols can have small groups with meaningful levers.
Interfaces can be open-source but controlled through domains, app stores, and curated endpoints.
Regulators know this, and so do developers.
The next phase of crypto regulation will be decided by who controls the levers that move value, and by whether Congress can write rules that recognize the difference between a tool, a service, and the gray territory in between.
If Lummis and Wyden get their way, at least one line will be clearer than it is today: writing code is not the same thing as moving 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.