New Bipartisan Senate Crypto Bill Targets Developer Liability
As the U.S. Senate pushes towards markup for the CLARITY Act, a new bipartisan push in the U.S. Senate is trying to answer another question that has come up again and again in crypto.
When does writing software turn into running a financial business?
At the center of the debate is a bill reintroduced by Senators Cynthia Lummis (R-WY) and Ron Wyden (D-OR) that aims to clarify when crypto developers, open-source maintainers, and infrastructure providers should, and should not, be treated as money transmitters under federal law. The proposal does not try to deregulate crypto wholesale. Instead, it tries to draw a hard line between publishing code and controlling user funds.
That distinction might sound obvious to engineers. To prosecutors, it has been anything but.
Why this suddenly matters so much
For years, the idea of “developer liability” lived mostly in white papers, legal panels, and late-night conference debates. That changed when U.S. authorities began testing aggressive theories that treat certain privacy tools and non-custodial software as unlicensed financial businesses.
Cases involving Tornado Cash and Samourai Wallet turned a theoretical concern into a real one. The message many developers heard was simple and chilling: if people use your software to move money, you might be responsible for how they use it, even if you never touched the funds yourself.
That fear has started to shape behavior. Some teams have shut down. Others have avoided building in the U.S. entirely. Many have quietly redesigned products to remove any feature that could be interpreted as “control.”
This Senate bill is a direct response to that climate.
The core idea: code is not custody
The proposal, often referred to as the Blockchain Regulatory Certainty Act, rests on a single principle. Developers and infrastructure providers should not be treated as money transmitters if they do not have custody of user assets and do not have the unilateral ability to move or control those assets.
In other words, liability should follow control, not authorship.
If you run an exchange, a broker, or a custodial wallet, this bill does nothing for you. You are still squarely in regulated territory. But if you publish open-source software, operate a node, maintain a wallet interface, or provide routing infrastructure without custody, the bill aims to put you outside money transmitter rules.
That matters because money transmitter classification is not a small thing. It can trigger state-by-state licensing, federal registration, AML obligations, and in some cases criminal exposure if regulators decide you crossed the line without permission.
Even if a developer ultimately wins in court, the cost and risk of getting there can be enough to stop innovation cold.
Why “control” is the battlefield
The word that does all the work in this bill is “control,” and that is exactly where the fight will be.
In clean cases, the distinction is easy. Exchanges custody funds. Non-custodial wallets do not. But crypto is full of gray areas.
Upgradeable smart contracts with admin keys. Front ends that can block addresses. Protocols with pause buttons. Governance structures that look decentralized on paper but concentrated in practice.
Regulators may argue that these forms of influence amount to control. Developers will argue they do not.
The Senate bill tries to anchor the definition to something narrow and concrete: the legal right or unilateral technical ability to move someone else’s assets. Whether that language survives negotiations intact is an open question.
How this fits into the broader crypto regulation fight
This developer liability push is happening alongside a much bigger legislative effort to overhaul U.S. crypto market structure more broadly. That larger framework aims to clarify which assets are securities, which are commodities, and which agencies oversee what.
What is becoming clear is that developer liability has become a quiet pressure point in those negotiations. Many lawmakers may be willing to compromise on market structure details, but fewer are comfortable backing a system that could criminalize software developers for publishing neutral tools.
In that sense, developer protections are no longer a niche issue. They are a prerequisite for passing broader crypto legislation at all.
What would change if this becomes law
If enacted, the bill would not end debates about crypto and compliance. But it would shift them.
First, it would give open-source developers and infrastructure providers a clearer legal lane, especially those building non-custodial systems.
Second, it would encourage business models that minimize custody by design. Expect more architectures that deliberately strip out admin powers, key control, and unilateral intervention.
Third, it would push regulators to focus enforcement elsewhere. Centralized onramps, custodians, stablecoin issuers, and brokers would remain the primary choke points for AML and sanctions policy.
That shift may frustrate some policymakers. It will reassure many builders.
The bigger question Congress is really answering
Strip away the legal language and the crypto politics, and this debate boils down to something fundamental.
Is publishing financial software more like writing code, or more like running a bank?
The Lummis-Wyden approach says it depends on whether you control the money. That principle is simple, intuitive, and easy to explain. The hard part will be writing it into law tightly enough to protect neutral builders without giving cover to businesses that function as intermediaries in everything but name.
That fight is just getting started.
Stay Connected
You can stay up to date on all News, Events, and Marketing of Rare Network, including Rare Evo: America’s Premier Blockchain Conference, happening July 28th-31st, 2026 at The ARIA Resort & Casino, by following our socials on X, LinkedIn, and YouTube.