Same Protocol, Two Sentences — Roman Storm vs Alexey Pertsev

The Dutch prosecution of Pertsev pursued a relatively conventional money-laundering theory. The prosecutor argued that Pertsev, as a Tornado Cash developer, knew or should have known that the protocol was being used to launder proceeds of crime, and that by continuing to develop and operate the protocol he facilitated those crimes. The court agreed. Money laundering does not require intent to commit the predicate offense; it requires knowledge that the funds are proceeds of crime and an act that obscures them. Pertsev's continued development was the act.

The Storm prosecution in SDNY pursued three theories. The unlicensed money transmitting business charge (Section 1960) was the simplest: operating a service that moves funds for a fee without the required state-by-state money transmitter licenses or federal money services business registration. The jury convicted on this charge.

The money laundering conspiracy charge was structurally more aggressive — the government had to prove Storm intended to facilitate the laundering, not merely that he knew it might happen. The IEEPA conspiracy charge required proof that Storm intended for the protocol to be used to violate US sanctions specifically. The jury, having heard testimony from Storm and from defense witnesses (including security researcher Matthew Green), could not unanimously agree on either theory. The verdicts were "hung," not acquittals — meaning the government can retry.

Mayer Brown's analysis of the mixed verdict called it a "win for code-is-speech" arguments at the margin, but cautioned that the Section 1960 conviction is itself a substantial precedent. It establishes that operating a protocol that moves user funds, even with no centralized control over destinations, can be construed as money transmission requiring licensure. That precedent does not require any showing of bad intent.

Tornado Cash itself — the protocol, not the developers — was on the OFAC Specially Designated Nationals list from August 2022 to March 2025.

The legal challenge to that listing succeeded in the Fifth Circuit on November 26, 2024. The court in Van Loon v. Treasury held that immutable smart contracts are not "property" of any foreign national within the meaning of IEEPA, and therefore OFAC exceeded its statutory authority by designating them.

Treasury delisted Tornado Cash on March 21, 2025, characterizing the move as "discretionary" rather than a concession to the court ruling. Whether or not that framing is sincere, the legal result is the same: as of May 2026, the smart contracts themselves are not on any US sanctions list, and US persons can legally interact with them.

This creates a curious legal geometry. The protocol is not sanctioned. The protocol's developers, however, are being criminally prosecuted in the United States and have already been criminally convicted in the Netherlands.

The implication that compliance lawyers and developers in the United States have drawn is structural: the path of criminal liability runs through the developer relationship to the protocol, not through the legality of the protocol itself. Writing code that becomes a money-transmission service can subject you to criminal exposure even when the code itself is constitutionally protected.

On January 9, 2026, Vitalik Buterin published an open letter on his blog calling the criminalization of code "unjust." He disclosed that he had personally used Tornado Cash and that he had donated 50 ETH (approximately $170,000 at December 2024 prices) to Storm's defense fund.

The letter is, in standard advocacy framing, an argument that the prosecution of protocol developers chills the broader open-source development ecosystem. Vitalik's specific concern is that criminal liability for what users do with neutral infrastructure puts every Ethereum developer — every contributor to a public, permissionless protocol — at potential exposure for actions outside their control.

The legal community's response was split. Coin Center and EFF supported the framing. Other commentators noted that the Storm prosecution focused on specific developer actions — operating the protocol's UI, taking a percentage cut of fees, knowledge of specific laundering instances — that distinguish it from purely passive open-source contribution.

The line between the two positions is not yet sharp. The retrial on the hung counts in October 2026, if it proceeds, will be the next venue where the line gets tested.

If you build privacy infrastructure today — Privacy Pools, Railgun, Aztec Network, Umbra Cash, Nocturne — what does the Storm precedent tell you about your exposure?

The conservative reading is that operating the deployment, taking fees, or making the protocol UI ad-supported all increase exposure. The Storm conviction was on the operating dimension, not the development dimension. A team that publishes code and is not in any practical sense operating the deployment has different exposure than a team that runs the UI, hosts the front-end, takes fees, and engages in active development on the live deployment.

The more aggressive reading is that the Section 1960 hook applies to any developer who can be construed as in control of a money-moving service, even without fees or active operation. Under this reading, even fully decentralized protocol governance does not insulate developers — because someone built the protocol, and the someone who built it can be charged.

Compliance lawyers I've spoken with broadly take the conservative reading. The Section 1960 conviction is real but bounded; it was about Storm's specific role at Tornado Cash, not about all developers who touched the codebase. The hung counts on money laundering and IEEPA are where the broader exposure lives, and the retrial in October will tell us how the government wants to push.

For Privacy Pools specifically, the Association Set Provider design — where users prove ZK-membership in non-criminal sets, and the protocol can comply with sanctions screening without identifying users — is the architectural answer to the Storm vulnerability. The protocol can document that it is not operating a money-transmission service in the Section 1960 sense, because the protocol does not transmit user funds at all; users transmit their own funds, and the protocol provides proof-of-innocence infrastructure on top.

Wallet-screening vendors — Chainalysis, TRM Labs, Elliptic, and Sanctuary — operate in adjacent legal territory but with different exposure. We do not transmit user funds. We do not custody. We do not provide the protocol. We attach risk scores to addresses and entities.

The Storm precedent does not directly affect this work. Risk scoring is a categorically different activity than protocol operation. The closest analogous risk is if a screening vendor's risk labels were so wrong that they produced obvious sanctions violations downstream — and even then, the liability is for the customer using the data, not the vendor producing it.

That said, the broader environment has shifted. In 2022, "we just provide neutral analytics tooling" felt sufficient as a regulatory posture. In 2026, after Tornado Cash and after the EU 20th sanctions package, the expectation is that compliance tools should actively prevent specific named harms. The screening industry has moved with the expectation. Sanctuary's screening, for example, ships with EU 20th-package designation flags effective May 24, 2026, OFAC March 12 DPRK additions, and per-corridor risk weightings — not because we are required to, but because the market expects it of any serious compliance tool.

If you used Tornado Cash before March 2025 — when the sanctions were in effect — and you transacted through an address that is now in the OFAC archive of historical designations, you may have lingering exposure. The fact that the protocol is no longer sanctioned does not retroactively unsanction your historical transactions.

If you use it now, your legal exposure for the act of using the protocol is, per the Fifth Circuit, no greater than using any unsanctioned smart contract. Your exposure for the proceeds you mix is, however, governed by every other law that applies to those proceeds. If the proceeds are clean, you have done nothing wrong; if the proceeds are dirty, the protocol does not launder you out of culpability.

The post-Tornado architecture — Privacy Pools, Railgun's Private Proofs of Innocence, Aztec's compliance-friendly composability — is the user-facing answer to "I want privacy and I am not a criminal." All three let you prove the negative about your funds without doxing your identity. None of them is binary like Tornado Cash was. All of them require some on-chain receipt that you participated in a compliant association set.

The protocol can be unsanctioned and the developer can still be prosecuted.

The line between "developer of neutral infrastructure" and "operator of an unlicensed money transmitter" is now being drawn case-by-case in US courts. Pertsev got sixty-four months on a Dutch theory. Storm got a partial conviction and faces a possible forty-year retrial on the rest. Vitalik donated to the defense fund and called the prosecution unjust.

Adjacent developers should plan for the conservative reading. Adjacent compliance tools should ship what the regulatory environment expects. Adjacent users should expect that "privacy" in 2026 means "compliance-friendly privacy" — with a receipt.