Developer liability for immutable code (Roman Storm)

Roman Storm’s case matters because it separates two questions that crypto has long blurred together: whether immutable code can be sanctioned, and whether the people who deploy, promote, and monetize that code can be criminally liable for how it is used. Those are not the same question. The Fifth Circuit’s Tornado Cash ruling narrowed one path of government power by holding that immutable smart contracts are not “property” for sanctions purposes, while the Southern District of New York’s case against Storm tested a different theory: that a developer can cross the line from publishing software into operating an unlicensed money transmitting business.

That distinction is now central for protocol teams, compliance groups, and investors. A system can be technically immutable and still have people around it making design choices, collecting fees, maintaining interfaces, steering users, and knowing exactly what kind of flow they are enabling. The law is increasingly focused on that surrounding conduct, not just on-chain code semantics.

01Immortality is not immunity

The Tornado Cash architecture is useful because it shows how often “immutable” is only partially true. The protocol had immutable pool contracts, but it also had surrounding components and human operators: front ends, relayers, infrastructure, promotion, and a business model. The Fifth Circuit’s November 26, 2024 decision in Van Loon v. Department of the Treasury focused on the immutable smart contracts themselves and held that they were not property subject to blocking under IEEPA. Treasury later removed the Tornado Cash sanctions on March 21, 2025, saying it had reviewed the novel legal and policy issues raised by applying sanctions to evolving technology.

That does not mean immutable code is legally invisible. It means sanctions law and criminal law work differently. For sanctions, the key question was whether the government could treat self-executing, immutable code as property that can be blocked. For criminal liability, the key question is whether the defendant participated in conduct that satisfies the elements of the offense: operating, conspiring, transmitting, helping transmit, or profiting from regulated money movement with the requisite knowledge or intent. Immutability can weaken a theory of control, but it does not erase the rest of the factual record.

The practical lesson is simple: code immutability is a technical property, not a complete liability shield. If the business around the code is still centralized, still marketed, still fee-generating, and still responsive to criminal usage, prosecutors will not stop at the source code.

02What the Storm case showed

The government’s theory against Roman Storm was never just that he wrote smart contracts. In its August 6, 2025 press release announcing the verdict, the Southern District of New York said Storm and his co-conspirators created the core features of Tornado Cash, paid for critical infrastructure, promoted the service, and made millions of dollars in profits. The office said the service advertised anonymous and untraceable transfers, and that Storm continued to provide the service while knowing it was transmitting large volumes of criminal proceeds. The jury convicted Storm of conspiracy to operate an unlicensed money transmitting business, an offense carrying a maximum five-year sentence.

That theory matters because it aligns liability with operational reality. If a team merely publishes code and walks away, the argument for criminal exposure is harder. If a team keeps servers alive, maintains a web interface, advertises the product’s ability to obscure traces, routes traffic through infrastructure it controls, and earns a cut of the flow, the government can argue that the team is not a passive publisher of software. It is operating a financial service.

This is why Roman Storm became such a consequential test case. The defense narrative says open-source developers should not be treated as operators for what strangers do with permissionless software. The prosecution narrative says a developer who knows the tool is being used for laundering, keeps the service running, and profits from that usage is not a neutral coder. The jury verdict did not answer every broader question about open-source software, but it did show that “immutable” does not automatically defeat an “operation” theory when the surrounding facts suggest active business conduct.

03Where the line can move

For builders, the dangerous zone is not “any code that can be misused.” Nearly all software can be misused. The line moves when the team retains enough control, benefit, or involvement that the software looks like a service rather than a publication. A front end hosted by the team is not the same as source code on a repository. A relayer network is not the same as a static library. Fees based on transaction flow are not the same as donation-funded open-source development. Explicit marketing around anonymity for illicit users is not the same as privacy-preserving design for ordinary users.

In regulatory and criminal analysis, several facts tend to matter. Who can change the system? Who can pause it? Who can upgrade it? Who controls the domain, the UI, the relayer set, the admin keys, or the key infrastructure? Who receives the revenue? Who wrote the messaging that told users what the tool is for? Who continued to operate after clear evidence of criminal use? Those are the facts that can turn “I wrote code” into “I ran a business.”

The Treasury delisting of Tornado Cash in March 2025 is also important because it shows that sanctions risk and criminal exposure do not move in lockstep. Treasury effectively backed away from the proposition that the immutable contracts themselves could be treated as sanctionable property. But that policy change does not immunize developers from other statutes. It only narrows one route the government had taken. The law can still reach conduct through money transmission, conspiracy, aiding and abetting, or sanctions-evasion theories when the surrounding facts support them.

That is why compliance teams should not treat the end of sanctions as the end of the legal problem. The question for any protocol touching value movement is whether the project has crossed from software publication into financial intermediation. If it has, the team needs to think like a regulated business, not like a pure software project.

04Practical lessons for builders

For teams building wallets, mixers, bridges, privacy tools, relayer networks, or other value-transfer systems, the safest mindset is to design as though a prosecutor will examine every point where human control still exists. If you want the strongest possible argument that you are publishing software rather than operating a service, you need a record that control was genuinely minimized, not just rhetorically decentralized. That means careful attention to custody, upgrade rights, administrative keys, operational infrastructure, fee capture, and the public messaging that surrounds the project.

It also means treating legal characterization as an engineering requirement. Teams should document when and how control is surrendered, separate code publication from service operation, and avoid building a business model that depends on fees from illicit use. If the system touches transmission of value, sanctions exposure, or transaction screening, get counsel early enough that the architecture can still change. Retrofitting compliance after launch is much harder than designing for it.

Roman Storm’s case will not be the last word on developer liability for immutable code, but it has already clarified the shape of the fight. Immutability can help against one kind of government theory. It does not automatically protect a developer who is still operating, profiting from, or intentionally facilitating a financial service. For protocol teams, that is the standard that now matters most.