Tornado Cash

Tornado Cash is an Ethereum smart contract mixer that provides transaction graph privacy by breaking the on-chain link between deposit and withdrawal addresses. It became the most prominent legal test of whether writing and deploying open-source privacy code constitutes a criminal act — and the most-cited precedent in cypherpunk legal defence discourse. (→ Cypherpunk Values & Philosophy)

What It Does

Tornado Cash accepts ETH (or ERC-20) deposits into a pool and issues a ZK proof (a “note”) to the depositor. The depositor can later present this note to withdraw the same amount to a completely fresh address. Because many users deposit and withdraw from the same pool, on-chain observers cannot link a specific deposit to a specific withdrawal.

Core privacy mechanism: shielded pool with ZK proof of membership. The anonymity set is the pool — larger pools provide stronger privacy because there are more plausible senders for any given withdrawal.

Limitation: Pool sizes are fixed denominations (0.1 ETH, 1 ETH, 10 ETH, 100 ETH). Users must deposit and withdraw exact amounts; mixing different amounts creates size-based fingerprints.

August 2022: The US Treasury’s OFAC sanctioned Tornado Cash — not a person or company, but the smart contract addresses themselves. This was the first time OFAC sanctioned immutable open-source code.

Charges against developers:

  • Roman Storm (developer) charged with money laundering conspiracy and sanctions violations
  • Alexey Pertsev (developer) arrested in the Netherlands; convicted and sentenced
  • Roman Semenov charged in absentia

The legal theory: prosecutors argued that building and maintaining the front-end interface (not the smart contract itself) constituted operating an unlicensed money transmission business. The smart contracts, once deployed, could not be controlled or shut down by the developers.

Roman Storm’s message to ECC2 (2025): Read at the Ethereum Cypherpunk Congress while Storm was awaiting trial — the case became a defining moment for developer legal defence movements.

The Code-as-Speech Defence

Peter Van Valkenburg (Coin Center): The prosecution of Tornado Cash developers criminalises tool-building based on potential misuse. The principle, if upheld, would extend to:

  • Lock manufacturers (locks can secure crime scenes)
  • VPN providers (VPNs can hide criminal activity)
  • Encryption library authors (encryption enables private criminal communication)

Legal argument: Writing and publishing code is constitutionally protected speech under the First Amendment. Deploying an autonomous smart contract is analogous to publishing a mathematical formula — the author cannot control how others use it.

Coin Center filed an amicus brief and pursued a separate legal challenge to the OFAC sanctions on the smart contracts themselves (distinct from the criminal charges against individuals).

Outcome trajectory: The 5th Circuit Court of Appeals ruled in November 2024 that OFAC exceeded its authority in sanctioning the immutable smart contracts (though the ruling was narrow and the criminal case against Storm proceeded separately).

Privacy Pools: The Compliant Successor

Ameen Soleimani (co-author of the Privacy Pools whitepaper, presented at ECC2): Tornado Cash’s fatal flaw was becoming too prominent — North Korea’s Lazarus Group used it to launder $600M+ from the Ronin bridge hack, poisoning the anonymity set and the protocol’s public image.

Privacy Pools v2 design:

  • Users can voluntarily associate their withdrawal with an “association set” — a subset of the pool that excludes known criminal deposits
  • This allows legitimate users to prove their withdrawal is not associated with sanctioned funds, without revealing which deposit is theirs
  • Preserves privacy for legitimate users while giving regulators a path to compliance
  • Internal peer-to-peer transfers (no on-chain trace at all)
  • Yield generation while in the pool
  • Integration with Kohaku wallet for seamless UX

Philosophical tension: Privacy purists (DarkFi, Amir Taaki) argue that any compliance mechanism that distinguishes “good” from “bad” users breaks the unconditional privacy guarantee that makes mixers valuable. Soleimani’s counter: a privacy tool that gets its developers jailed and its users deanonymised via association with Lazarus Group has failed at its actual goal.

Impact on Privacy Infrastructure

Tornado Cash reshaped how privacy tools are designed, funded, and defended:

  1. Legal defence infrastructure: Sentinel Alliance, Coin Center’s developer defence fund, and the broader “code is speech” litigation strategy all trace to the Tornado Cash prosecutions.

  2. ZK-based alternatives: Kohaku wallet, Rail Gun, and Privacy Pools all incorporate ZK proofs that allow selective disclosure — allowing users to prove something about their funds without revealing everything. This is a direct response to the “compliant privacy” problem.

  3. UI vs. contract distinction: The prosecution’s focus on the front-end interface (not the smart contract) accelerated the decentralisation of front-ends — IPFS-hosted UIs, ENS-based access, and SDK-first designs that eliminate a single controllable interface.

  4. Chilling effect: Several privacy projects delayed launches, removed features, or geo-blocked US users in response to the Tornado Cash precedent.

Connections

  • Cypherpunk Values & Philosophy — Code-as-speech doctrine; developer moral responsibility; Sentinel Alliance legal defence; Peter Van Valkenburg’s “John Hancock Project”
  • Privacy as UX Design — Privacy Pools as compliant successor; Kohaku wallet integration; Rail Gun as alternative
  • Ethereum Regulation 2026 — OFAC sanctions on smart contracts; developer liability; Clarity Act safe harbour proposals
  • Smart Contract Security (2026 State) — UI/front-end attack surface (the Tornado Cash prosecution targeted the UI layer, not the contract)
  • Anonymous Broadcast — Unconditional privacy (DC-nets) as the alternative to compliance-compatible designs

Open Questions

  • Does the 5th Circuit ruling limiting OFAC sanctions on smart contracts establish a durable precedent, or will it be circumvented via new legal theories?
  • Can Privacy Pools achieve a large enough anonymity set to provide meaningful privacy, given that compliance-seekers and privacy-seekers have conflicting incentives for pool composition?
  • Does the “no single front-end” design adequately protect developers, or does any involvement in maintaining protocol infrastructure create liability?
  • Is compliant privacy (Privacy Pools) a pragmatic middle ground, or does it fundamentally undermine the unconditional privacy guarantee that makes mixers valuable?