Tornado Cash Website Versus the Contracts It Calls

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

Tornado Cash website conversations almost always merge two things that behave very differently: a web interface, and the deployed contracts an interface constructs transactions for. The interface is software someone hosts and can replace at will, while the contracts are fixed code on a public network. Keeping the two apart is the single most useful safety idea available to a reader on this topic.

What does a front end actually do for a user?

It assembles a transaction and asks a wallet to sign it. A front end is a web page that reads public chain data, collects whatever inputs it needs, prepares a candidate transaction and passes it to wallet software for approval. It holds no assets, has no keys, and cannot move anything by itself.

The design splits responsibility across four layers. The page provides convenience, the wallet holds the keys and signs, the network orders and finalises what was signed, and the contract applies its rules to whatever call arrives. The interface is the least authoritative component in that stack, despite being the only one most people ever see.

Interfaces for privacy pools of this kind also do local cryptographic work, preparing the proof material a withdrawal call requires before the transaction reaches the wallet. That work happens in the visitor’s browser, which is a choice about where secrets stay rather than a service performed on anyone’s behalf.

Because contract interfaces are public, any number of pages can be written against the same deployed code and none holds a privileged position. That interchangeability is why one page disappearing tells you nothing about the contracts, and why a new one appearing tells you nothing about its provenance.

Can a website change what a deployed contract does?

No. Contract code on Ethereum executes exactly as deployed, and the core pool contracts here were written without an owner, a pause switch or an upgrade path. A page can change which contract it calls and what it tells you that call does, but it cannot alter the rules the contract itself enforces on every caller.

Immutability here is a concrete property rather than a slogan. There is no administrative key, so no party can freeze balances, reverse a call or revise the logic after deployment. The contract records a commitment on deposit and releases each deposit exactly once against a nullifier derived from the same secret, and those rules apply identically to everyone because nobody can vary them.

What the page controls is the framing and the destination. It decides which address a transaction is addressed to, what values are filled in, and what description of all this appears on screen. A replaced interface therefore does not corrupt the protocol; it points somewhere else while continuing to describe itself in the same familiar language.

The practical consequence is that two familiar statements are unrelated. Saying the contracts cannot be tampered with is true and says nothing about any page, while calling a page trustworthy is a claim about a hosting party that immutability cannot support. Confusing them moves confidence from a layer that earned it to one that did not.

Why is the interface the layer an attacker replaces?

Because it is the only layer that can be replaced cheaply. Deployed code cannot be edited, keys cannot be extracted from a wallet without the holder acting, and consensus cannot be persuaded to reorder history. The web page is the one component an outsider can fully control, and it is where every decision gets presented.

Attackers concentrate where control is cheap. Standing up a convincing page costs very little, requires no access to anyone’s systems, and can be repeated after each takedown. Nothing else in the stack combines low cost with such proximity to the moment a person approves something.

The interface also holds a monopoly on context. The balance you see, the fee you are told about, the destination described in plain language and the reassurance that everything is routine all originate from the page. The wallet confirmation screen is the only element outside its control, which is why it is the only element worth treating as evidence.

This is a recurring shape in industry incident reporting rather than a hypothetical. Compromises of domains, hosting and build pipelines have repeatedly caused losses at projects whose on-chain code was never touched, and the protocol layer performed as designed throughout.

How can you tell whether a claim describes the interface or the protocol?

You restate the claim with the layer named, ask what would have to change for it to be true, check chain data rather than page copy, separate availability claims from rule claims, and record what stays unverifiable. The procedure is a research method for reading claims critically, not a guide to using anything.

Step 1: Restate the claim with the layer named

Rewrite the claim so that it names the layer it is about, whether that is a web page, a wallet, a deployed contract or the network, because most confusion in this area comes from sentences that leave the subject implicit. Many claims lose their force once the subject is written down.

Step 2: Ask what would have to change for it to be true

Work out which component would have to behave differently for the statement to hold, because a claim requiring an immutable contract to change is a claim that can be dismissed immediately. This step alone disposes of many confident assertions about relaunches and upgrades.

Step 3: Check chain data rather than page copy

Look for the answer in a public block explorer, where deployment history and contract code are visible to anyone, rather than in the description written by the party making the claim. Chain data is neutral in a way that marketing copy structurally cannot be.

Step 4: Separate availability claims from rule claims

Distinguish claims about whether something is reachable from claims about what the rules permit, since a service being online or offline says nothing about what the underlying code does. Availability is a fact about a host, and rules are a fact about deployed code.

Step 5: Record what remains unverifiable

Write down which parts of the claim you could not confirm from primary sources and leave them marked as open rather than resolving them in the claimant’s favor, because unverified statements about the interface layer are the ones that cost people money. An open question is a usable research result.

Does a missing front end mean the protocol stopped working?

No. Deployed contracts continue to execute whether or not any page points at them, because they exist in the replicated state of a public network rather than on a server somebody rents. A missing interface is a fact about hosting, publishing and legal risk, and it carries no information about the code.

The events of 2022 illustrate the split clearly. Around the OFAC action notice of August 2022, the published interface went offline and code repositories were removed, while the contracts continued to behave as they always had. Two layers responded to the same event in completely different ways, and coverage that treats them as one thing produces confusion in both directions.

The reverse error is equally common and more dangerous. A page being live, polished and highly ranked is not evidence that anything behind it is operating correctly, or that the party running it has any relationship to the code it names. Availability is the easiest property in the entire stack to fake.

None of this speaks to whether any action is lawful for any particular person. Criminal questions around this protocol remain live in more than one jurisdiction, sanctions status has changed over time, and both are separate from the layering described here. Those questions belong with qualified counsel rather than with a page offering a confident answer.

Which layer controls what

Naming the layers side by side makes the security picture easier to hold, since almost every mistake in this area comes from attributing a power to one layer that in fact belongs to another. The table is a general orientation rather than a description of any specific page or deployment.

Layer	What it controls	What it cannot do
Web interface	What you see, which contract is called, how the request is described	Move assets, or change any rule the contract enforces
Wallet software	Custody of keys, signing, the confirmation screen you are shown	Judge whether the page that asked is honest
Deployed contract	The rules applied to every valid call it receives	Ask why you called it or who told you to
Network consensus	Ordering, inclusion and finality of signed transactions	Reverse a settled transaction for anyone
Relayer	Submitting a withdrawal transaction and paying its gas for a fee	Redirect funds, because the proof fixes recipient and fee

Only the first row describes something an outsider can silently substitute, which is why it deserves most of a reader’s scepticism and receives the least of it.

Frequently asked questions

If two interfaces call the same contract, are they equally safe?

No, because safety at this level is a property of what each page asks you to sign rather than of the contract behind it. Two pages can address the same immutable code while differing completely in what they request, what they display and who receives the resulting funds.

Does published source code prove that a page runs that code?

Not on its own. A repository shows what someone published, while the files a server sends to a browser are a separate artifact that can differ, and confirming they match requires a reproducible build most visitors cannot perform. Published source is useful context, not proof of what executed.

Is a wallet’s transaction preview a guarantee of the outcome?

Previews and simulations are a genuine improvement on reading raw data, but they estimate an outcome under current conditions and can be misled by contracts that behave differently when actually called. Treat a clean preview as one supporting signal rather than as a settled verdict.

Did the 2025 delisting change anything about the deployed code?

No. Sanctions listings and removals operate on names and identifiers held by a government, not on contract bytecode, which is unchanged throughout. The legal position for any particular person is a separate question that depends on conduct and jurisdiction and belongs with qualified counsel.