Tornado Cash Immutability: Why There Was No Off Switch

Prepared by the editorial team. Updated August 31, 2026.

Tornado Cash is usually described as a service, which is the single biggest source of confusion about it. The core of the system is a set of Ethereum contracts that no party can modify, pause or delete, and that technical fact drove both the regulatory response and the court decision that followed. This article explains what immutability means in practice and where control genuinely existed.

What does it mean that the core contracts are immutable?

Immutable means the deployed code cannot be changed, paused or removed by anyone, including the people who wrote it. Once the contracts were published to Ethereum they held no administrative key, no upgrade path and no emergency stop. They execute the same rules for every caller, permanently, without any party able to intervene.

This is a design choice rather than an inherent property of blockchains. A developer deploying a contract decides whether to include privileged functions. Most projects keep some, typically an owner address that can pause the system or swap the logic behind a proxy, because bugs are common and the ability to respond is valuable. Removing those functions is a deliberate decision to give up control permanently.

The motivation is a trust argument. If a pool holds deposits and its creator retains an upgrade key, users must trust that the key will never be used to seize funds or alter withdrawal rules. Removing the key removes the need for that trust, and the guarantee becomes a property of the code rather than a promise from a company. The cost is that the same permanence applies when something goes wrong.

Why could no one switch the protocol off after 2022?

Because there was nothing to switch. The contracts contained no pause function, no owner with special rights and no mechanism through which any party, including a government or the original developers, could halt their execution. Ethereum nodes worldwide continued processing calls exactly as the code specified, and no instruction could change that.

This surprised many observers who assumed a sanctions designation would function like a court order to a company. Ordinary enforcement works through intermediaries: a bank freezes an account, a registrar suspends a domain, a company disables a feature. Each of those requires a party who both controls the thing and can be compelled. Here the controlling party did not exist, and the code was replicated across thousands of independent nodes.

What enforcement could reach were the surrounding layers. Domain names, hosted interfaces, code repositories and the exchanges through which funds enter and leave are all operated by identifiable parties in identifiable jurisdictions. Those were restricted quickly and effectively. The distinction between the protocol and its access layer became central to the legal reasoning, because it separated the thing that could not be controlled from the things that could.

What parts of the project were not immutable?

Several components were fully controllable. The web interface, the domain name, the code repositories, the relayer registry and the governance system built around the TORN token all depended on identifiable parties or on-chain votes. Only the core pool contracts were beyond intervention, and much public commentary treats the whole project as though it shared that property.

Governance is the clearest example. A token-based system existed through which holders could vote on proposals affecting parts of the wider project. A voting mechanism implies someone can change something, which is the opposite of immutability, and it also implies a set of participants who might be identified. Legal arguments about who runs a decentralized system tend to concentrate on exactly these features.

This layered picture explains why the appeals court decision in Van Loon was narrower than headlines suggested. The Fifth Circuit ruled in November 2024 that the immutable contracts were not property capable of being blocked under the relevant statute. It did not hold that everything associated with the project enjoyed the same status, and the criminal case against Roman Storm proceeded on questions about conduct rather than about the contracts themselves.

How can you tell whether a smart contract is upgradeable?

You confirm the source is verified, check whether the address is a proxy, search the source for privileged functions, identify who controls any that exist, and corroborate against an independent audit. The procedure below is a research method for evaluating any deployed contract and is not instruction for interacting with a mixing service.

Step 1: Confirm the source code is verified

Check whether the deployed bytecode has published, verified source on a block explorer, because an unverified contract cannot be assessed from its source and any claim about its behavior rests on trust rather than evidence. Verification means the published code provably compiles to the bytecode actually running at that address.

Step 2: Look for a proxy pattern

Determine whether the address is a proxy that forwards calls to a separate implementation contract, since a proxy usually means the logic can be replaced later by whoever holds the right to point it elsewhere. Explorers commonly label this pattern, and the implementation address is the code that actually runs.

Step 3: Search for privileged functions

Read the source for privileged functions such as pause, upgrade, withdraw or ownership transfer, because the presence of any of these means some account retains powers that ordinary callers do not have. Access-control modifiers on a function are the usual signal that a role beyond the public exists.

Step 4: Identify who holds the privileged role

If privileged functions exist, identify what controls them, whether that is a single externally owned account, a multisignature wallet or a governance contract, because the answer determines who could actually act. A single key and a broad multisignature represent very different practical risks.

Step 5: Corroborate with an independent audit

Compare your reading against an independent audit or technical review rather than relying on your own inspection alone, because subtle upgrade paths are easy to miss and audits are written to surface them. Disagreement between your reading and an audit is a signal to look again rather than to choose.

Does immutability mean nobody can be held responsible?

No. Immutability describes what the code can do, not what people did. Prosecutors in both the United States and the Netherlands built cases around human conduct: what developers built, how they promoted it, what they knew about its use and what steps they took or declined to take. None of those questions depends on whether a contract has an off switch.

This is the point where technical and legal reasoning most often talk past each other. A technically accurate statement that nobody controls the contracts does not answer a legal question about whether particular people conspired to operate an unlicensed money transmitting business. The first describes a system’s properties; the second describes alleged human decisions, and a court can find the first true while still examining the second.

The outcomes so far reflect that separation. Alexey Pertsev was convicted in the Netherlands in May 2024 under Dutch law and was later conditionally released while pursuing an appeal. In New York, a jury convicted Roman Storm on one count in August 2025 and deadlocked on two others, which the government intends to retry in April 2027. Immutability was part of the technical record in these proceedings, not a shield against them.

Where control actually sits in a protocol stack

Treating a protocol as a single object obscures which layers can be reached and which cannot. The table separates common components by whether a party retains control, using this project as the illustration. It is descriptive and does not evaluate the legality of any layer.

Layer	Controlled by a party?	What that meant in practice
Core pool contracts	No, immutable once deployed	Continued executing regardless of any order
Web front end	Yes, hosted by identifiable operators	Taken offline after the 2022 action
Domain name	Yes, held through a registrar	Reachable through ordinary legal process
Code repositories	Yes, hosted on commercial platforms	Restricted, then partly restored later
Relayer participants	Yes, run by independent operators	Individual operators could and did withdraw
Token governance	Yes, through on-chain voting	Proposals remained possible after the action

The general lesson extends past this one project. Asking which layer a claim refers to usually resolves an apparent contradiction between two accurate statements about the same system.

Frequently asked questions

Could Ethereum validators have censored the contracts instead?

Individual block builders and validators can choose not to include particular transactions, and some did filter after 2022. That is a soft, partial form of censorship rather than a shutdown, because any single non-filtering participant can still include the transaction in a later block.

Is immutability a security feature or a liability?

It is both, which is the core tension. Users are protected from a creator quietly changing the rules or seizing deposits, but the same property means a discovered flaw cannot be patched and harmful use cannot be blocked at the contract level.

Do most DeFi protocols use immutable contracts?

No. Most deployed protocols use upgradeable proxy patterns or retain pause functions, precisely so that bugs can be fixed and emergencies handled. Fully immutable deployment is a deliberate minority choice with a specific trade-off attached.

What is a trusted setup and why did it matter here?

Certain zero-knowledge systems require initial parameters generated in a ceremony, and if every participant’s secret contribution were retained and combined, false proofs could in principle be forged. Multi-party ceremonies exist to make that outcome implausible, since a single honest participant destroying their contribution is enough.