The Door Stayed Open After the Lock Was Confiscated

You pull up the Tornado Cash interface one morning and get a blank page. The GitHub repo is gone. The developers are in handcuffs or hiding. You check the Ethereum block explorer anyway, mostly out of habit, and the contract address is sitting there, live, processing deposits. Funds moving in. Funds moving out. Not a single line of code disturbed.

That is, with uncomfortable precision, what happened after the U.S. Treasury's Office of Foreign Assets Control added Tornado Cash's smart contract addresses to the Specially Designated Nationals list. The prosecution of developers proceeded. The front-end went dark. The protocol did not notice.

Understanding why requires a short detour into what a smart contract actually is at the mechanical level.

Code Deployed Is Code That Doesn't Need Permission

When a developer deploys a smart contract on Ethereum, they broadcast bytecode to the network. The network assigns that bytecode a permanent address. From that moment, the contract exists as an autonomous entry in Ethereum's global state: no server hosts it, no company runs it. Tens of thousands of nodes across dozens of countries collectively enforce its logic every time someone sends a transaction to its address.

Tornado Cash's core contracts run on a specific cryptographic mechanism: zero-knowledge proofs, specifically a zk-SNARK construction. The flow is this. A user deposits a fixed denomination of ETH (the protocol standardized pools at 0.1 ETH, 1 ETH, 10 ETH, and 100 ETH) and receives a cryptographic note, essentially a secret string proving they made the deposit without revealing which deposit. Later, from a completely fresh address, they submit that note as a proof. The contract verifies the proof, confirms the note hasn't been used before by checking a nullifier hash stored on-chain, and releases funds to the new address. No link between deposit address and withdrawal address appears on the public ledger.

Nowhere in that sequence does the contract check who is asking. It cannot. There is no identity layer, no IP lookup, no compliance module. The contract checks one thing: is the cryptographic proof valid? If yes, the ETH moves.

Immutable. No admin key. No upgrade function. The original developers retained no ability to pause, modify, or kill the contracts after deployment.

Sanctions, as a legal instrument, work by prohibiting persons and entities subject to U.S. jurisdiction from transacting with a designated target. They are extraordinarily effective against banks, exchanges, and businesses with employees, accounts, and legal exposure. Against a 500-line Solidity contract sitting at a fixed Ethereum address, they create a legal obligation without a technical enforcement mechanism. The contract has no nationality. It cannot receive a letter. It cannot be arrested.

This is not a subtle distinction. It is the entire problem.

What Sanctions Actually Did (and Didn't) Do

The practical effects were real, just narrower than the headlines suggested.

Coinbase, Infura, Alchemy, and other U.S.-based infrastructure providers blocked access to the Tornado Cash front-end and RPC endpoints almost immediately. The GitHub repository was taken down. Circle froze USDC held in associated addresses. Meaningful disruptions, all of them, to the casual user experience.

But a user comfortable with a command line never needed any of that. The contract ABI (the interface specification) is public and permanent. Anyone can write a local script that constructs a valid transaction and broadcasts it directly to an Ethereum node. The protocol's documentation was replicated across dozens of mirrors within days. A technically literate user outside U.S. jurisdiction faced essentially no new friction.

Consider two users. Mara uses a browser-extension wallet and relied on the Tornado Cash website. After the front-end goes dark, she is effectively locked out, facing significant technical effort to proceed. David, a developer, had already bookmarked the contract addresses and interacts via a local script he wrote himself on a Tuesday afternoon. For David, the sanctions produced exactly one change: a legal obligation under U.S. law not to use the protocol. His technical access remained identical before and after the designation.

That gap caught regulators flat-footed, and it should not have surprised anyone who had read a protocol whitepaper. The sanctions framework assumes that choking off access points chokes off access. With a permissionless protocol, access points are effectively infinite. Every Ethereum full node is, in a narrow sense, one of them.

The Immutability That Makes This Structural

Tornado Cash's immutability was a deliberate design choice, not an oversight, and it is common across serious DeFi protocols. Upgradeable contracts require an admin key, which creates a central point of control, which creates a central point of legal or regulatory pressure. Protocol designers who want to credibly commit to stable rules often deploy without upgrade mechanisms precisely to make the protocol trustworthy to users. Think of it less like a vending machine and more like a mathematical proof: once published, no one can unpublish the result.

That same property makes the contract ungovernable by external authority.

A court can order a developer to modify a contract. If the developer holds no key, the order cannot be technically fulfilled regardless of willingness to comply. This is not a loophole anyone is exploiting. It is an architectural property, the same one that prevents confiscating your Bitcoin by sending a letter to Satoshi.

Subsequent legal arguments in the Tornado Cash proceedings have circled exactly this question: can immutable, autonomous code constitute "property" subject to sanctions designation, or does the sanctions framework only coherently apply to persons? Courts in different jurisdictions have reached different preliminary conclusions, and the question remains live in active dockets. Both readings have textual support, which is precisely what makes the litigation worth watching.

What Actually Stops an Unstoppable Contract

If code cannot be sanctioned into stopping, what stops it? A few things, none of them clean.

Network-level consensus changes could, in theory, blacklist specific addresses at the Ethereum protocol layer: validators could collectively refuse to include transactions touching designated addresses. This would require social coordination among thousands of independent validators, many outside U.S. jurisdiction, and would represent a profound departure from Ethereum's neutrality guarantees. No such change has been implemented. The Ethereum community has shown no appetite for it, and I think that resistance is correct, because a censorship layer at the consensus level would compromise the network's value proposition for every application running on it, not just the ones regulators dislike.

The more durable pressure point is the perimeter, not the contract itself. If every regulated exchange flags or freezes ETH that passed through a sanctioned mixer, the withdrawn funds become difficult to spend in the regulated economy. The contract keeps running, but its outputs are increasingly quarantined at the boundary between the on-chain world and the financial system that most people actually need to use.

So here is the real question regulators have not squarely answered: if the code cannot be stopped and the users cannot all be identified, what precisely is the theory of deterrence?

The Tornado Cash situation is a clean demonstration of a principle that will recur wherever DeFi and regulation intersect: legal authority and technical authority are not the same thing, and asserting one does not confer the other. Regulators who continue treating them as equivalent will keep arriving at the scene after the transaction has already settled. The more productive frame is to ask what the perimeter can actually hold, and to build enforcement doctrine around that honest accounting rather than around the comforting fiction that a designation letter reaches the blockchain.