Tornado.cash: The Domain Name Versus the Protocol

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

Tornado.cash is a domain name, and the thing most people mean when they say it is not a domain name at all. The naming record is a rented pointer administered by a registrar, while the system it once pointed at is a set of Ethereum smart contracts replicated by every node on the network. Almost every persistent misunderstanding about this subject starts by treating those two objects as one.

What is the difference between a domain name and a protocol?

A domain name is a rented pointer in the global naming system, administered by a registrar and revocable by it. A protocol here is a set of smart contracts deployed to Ethereum and replicated by every node that runs the chain. One is an address label. The other is the machine the label pointed at.

Naming exists because numeric network addresses are hard to remember. A registrar sells the right to occupy a name for a period, a registry operator maintains the authoritative record for the suffix, and resolvers consult that record to translate a name into a destination. Nothing in that chain stores the software it points at. It stores a direction.

The contracts sit in a different category. Once deployed to Ethereum, a contract’s bytecode is written into the shared state that every participating node maintains and validates independently. The core privacy pool contracts in this case were published without an owner, without a pause function and without an upgrade path, so no administrative key exists that could change or halt them. They execute when called and produce the same result on every node.

The consequence is that the two objects fail in completely different ways. A name can lapse, be transferred or be suspended, and each of those is an action taken by an identifiable intermediary against a record it maintains. A contract without an owner has no equivalent lever, because no party sits between a user and the code to be asked to intervene.

Why do people treat the domain name as the whole system?

Because for most of the web the domain genuinely is the service. For a bank, a retailer or a social network, taking the name away removes the product, because the software runs on servers the operator controls. Readers apply an accurate mental model from ordinary web services to a case where it does not hold.

The habit is reinforced by how the subject is discussed. Headlines, summarized filings and search queries all use a short brand string, because a brand string is memorable and a contract address is not. That convenient compression silently merges a naming record, a hosted interface, a source repository, a governance token and a set of contracts into one apparent object.

Interface design deepens it further. Front-end software is deliberately built to make the underlying system invisible, so the layer people experience is the layer least connected to how anything actually works.

Which layer does each part of the stack actually sit on?

Separating the layers is the fastest way to make a confusing claim legible. The table below sets out the components commonly folded together under one name, what each one is, and what kind of party holds authority over it. It is a general description of how these layers work rather than a statement about any specific present arrangement.

Component	What it is	Who can change or remove it
Domain name	A rented record in the naming system pointing to a destination	The registrar and registry that maintain the record
Hosted interface	Files served from a machine so a browser can render a page	The hosting provider and whoever pays for the account
Source repository	A copy of human-readable code kept on a hosting platform	The platform operator and the account holder
Deployed contract	Bytecode in Ethereum state, here without owner or upgrade path	Nobody, once deployed without administrative functions
Governance token	A separate on-chain asset used for voting in the associated DAO	Token holders collectively, within the rules already deployed

Reading down the last column shows the whole issue in one view. Authority is concentrated and named at the top of the stack and disappears entirely at the contract row, which is precisely why measures that work on the upper rows produce so little effect on the bottom one.

How can you trace who controls a component you are reading about?

You trace control by naming the component precisely, placing it on the correct layer, asking who can revoke or alter it, checking the on-chain layer for mutability, and recording which layer a claim was really about. The procedure below is a research method for evaluating statements, not a guide to any protocol.

Step 1: Name the component precisely

Write down exactly which thing you are asking about, whether that is a domain name, a hosted interface, a code repository or a deployed contract address, because these are separate objects with separate owners. A question naming only a brand cannot be answered, since the brand covers all of them.

Step 2: Identify the layer it belongs to

Place the component on the stack by asking whether it is a naming record, a hosting arrangement, a source repository or on-chain code, since each layer has a different kind of controller. Getting the layer right narrows the possible answers before you look anything up.

Step 3: Look for the party that can revoke or change it

Ask who has the practical power to withdraw, suspend or alter the component, because the holder of that power is the meaningful controller regardless of who created it. Authorship and present control are frequently different parties.

Step 4: Check the on-chain layer for mutability

For a deployed contract, check with a public block explorer whether the code contains an owner, an administrative proxy or a pause function, since a contract without them cannot be altered by anyone. This single check separates code that someone can still govern from code that has passed out of anyone’s hands.

Step 5: Record which layer a claim actually refers to

Note in writing which layer any claim you have read is really about, because most confident statements about control collapse once the layer they describe is made explicit. The note also lets you compare sources that seem to contradict each other but describe different rows.

What did the loss of the naming and hosting layers actually change?

It changed access and convenience rather than existence. After the August 2022 Treasury designation, code hosting was restricted and a public interface stopped being served, so the ordinary path most people used disappeared. The deployed pool contracts continued to execute exactly as before, because nothing in the naming or hosting layers touches Ethereum state.

That distinction is not a technicality; it is the fact a federal appeals court eventually turned on. In November 2024, in Van Loon v. Department of the Treasury, the Fifth Circuit held that the immutable smart contracts were not property under the governing statute and therefore could not be designated. The court’s reasoning rested on the observation that nobody could own, exclude others from or dispose of code that no one can modify.

The practical picture after 2022 was therefore two-sided. Ordinary users lost the interface they knew, while the contracts remained callable by anyone able to construct a transaction directly. Measures aimed at the upper layers reduced casual access and left the technically capable minority unaffected.

Why does conflating the two lead readers to wrong conclusions?

Because a claim that is true of one layer is usually false of the other, and the brand name hides which one is meant. Statements that the system was shut down, seized, restored or made legal are almost always accurate about a naming or hosting record and inaccurate about the contracts, or the reverse.

The most common error runs in the direction of overstatement. A domain suspension is reported as a shutdown, which implies the system stopped, which implies a subsequent event must be a restart. None of those steps follow, because the contracts never stopped and therefore never restarted, and readers who accept the chain end up with a timeline that does not match any record.

The error also runs the other way. Because the contracts are immutable, some readers conclude that no enforcement is possible at all, which understates what actually happened to people. Immutable code is not a shield for individuals: a jury convicted Roman Storm in August 2025 on one count of conspiracy to operate an unlicensed money transmitting business, deadlocking on two further counts, and Alexey Pertsev was convicted in the Netherlands in May 2024. Conduct is prosecuted through people, not through bytecode.

The confusion carries a practical cost as well. Someone searching a familiar name may meet a site occupying it today with no relationship to anything historical, and the belief that a name reliably identifies a system is what makes that substitution work.

Frequently asked questions

If a domain expires, can someone else register the same name?

In the ordinary course of the naming system a lapsed name can be registered by another party, subject to the rules of the registry that operates it. This is one reason a familiar name in a search result carries no assurance about who is behind it today.

Does a protocol need a website to keep functioning?

No. A web interface is a convenience layer that builds a transaction for a user, and the contracts respond to any correctly formed transaction regardless of where it originated. The interface and the contract are separate pieces of software with separate failure modes.

Why do court filings and news reports describe the same thing differently?

Legal documents usually name a specific object such as a contract address, an entity or a person, because a legal claim has to attach to something definite. General reporting compresses all of it into a single brand name, which is where much of the public confusion begins.

Is the token the same thing as the protocol or the domain?

No. TORN is the governance token of the associated decentralized autonomous organization, which is a third object again, distinct from both the naming record and the privacy pool contracts. Statements about one of the three are routinely misapplied to the others.