Tornado Cash Website: Which One Do You Actually Mean?
Prepared by the editorial team. Updated August 31, 2026.
Research Notice: This guide is part of our fintech research series examining blockchain privacy tools and their regulatory context. It is informational and educational only, is not legal, financial or compliance advice, and does not endorse or instruct the use of any mixing service. Laws differ by jurisdiction and change over time; verify current rules for your location.
Tornado Cash website is a phrase that points at no single object, which is why the search for the official one so often ends badly. The name has been attached to an interface published by the original project, to alternative front ends built by unrelated people, to archived snapshots, to documentation, and to pages that exist only to impersonate the others. This article explains why the question needs reframing, and what to ask instead.
Why is there no single official site for this protocol?
No organization holds the authority to designate one. The protocol is a set of deployed Ethereum contracts with no owner and no administrator, the original project’s interface stopped being maintained in 2022, and nothing about the contracts grants any web page a privileged relationship to them. Officialness here has no issuer.
In ordinary commerce, official means something concrete. A company owns a trademark, controls a domain, signs its releases and can disavow imitators, and each of those functions needs an entity that still exists. Where the entity is absent, the word keeps its force while losing its referent.
The break is documented in public records rather than rumor. After August 2022 the published interface went offline, code repositories were removed, and people associated with the project became criminal defendants in two countries. A broken chain of custody over a famous name is exactly the condition impersonators need. When a page announces today that it is the official site, it asserts something no surviving party can confirm or deny, so the assertion tells you only what the page wants you to believe.
What different things have been called by this name?
At least five distinct categories: the interface published by the original project, community-built alternative front ends, archived snapshots held by web archives, documentation and source code repositories describing the design, and pages built by unrelated parties to imitate any of the first four. They differ in origin, in maintenance status and above all in intent.
The original interface is the referent most people have in mind, and it is the one that no longer exists in maintained form. Alternative front ends are a different matter. Because the contracts are public and documented, software that constructs transactions for them can be written by anyone. None of those projects inherits authority from the original, and their provenance ranges from openly identified developers to wholly anonymous publication.
Archives and documentation form a separate class again. An archived snapshot records what a page looked like on a date, which is useful for research and misleading if mistaken for a working service. Documentation and code repositories describe the design, and for a reader trying to understand the protocol they are the most informative referent as well as the least demanding of a wallet. The fifth category is why all of this matters, because impersonating pages are built to be mistaken for the others at the moment a searcher decides one result must be the right one.
How can you verify a domain claim against primary sources?
You state the claim precisely, identify who would have to be its source, look for it in a record that party does not control, check whether the supporting evidence is merely self-referential, and record anything unconfirmed as unconfirmed. The procedure below is a research method for testing claims, not a guide to using any protocol.
Step 1: State the claim in one sentence
Write the claim out in a single sentence, naming what the page says it is and who it says stands behind it, because a vague impression cannot be checked while a specific assertion can. Many pages weaken here, because they never say who publishes them.
Step 2: Identify who would have to be the source
Ask which party would need to exist and to have spoken for the claim to be true, such as a named organization, a maintainer of record or a court filing, because a claim with no possible source is not one you can confirm at all. If no party could issue it, the claim is unverifiable in principle, not merely unverified today.
Step 3: Look for the claim in a record the page does not control
Search for the same assertion in a record the page cannot edit, such as a government publication, a court docket or an established archive, because evidence hosted by the party making the claim proves only that the party made it. Primary records are slower to read and much harder to fake than a landing page badge.
Step 4: Test whether the supporting evidence is self-referential
Check whether the supporting links lead to genuinely independent records or back to pages run by the same party, because a ring of sites citing one another creates the appearance of corroboration without any of its substance. Following two or three citations to their origin shows whether the claim has an external anchor.
Step 5: Record unconfirmed claims as unconfirmed
Stop at the point where confirmation fails and record the claim as unproven rather than as probably true, because the cost of being wrong about the identity of a page that will ask for wallet access is not symmetrical. Research tolerates open questions comfortably; a signed transaction does not.
Does a dormant project still have a web presence?
Not necessarily. Contracts deployed on a public blockchain continue to execute with nobody maintaining them, but a website requires a registered domain, paid hosting and a party willing to be publicly associated with it. Those requirements can lapse completely while the on-chain component is entirely unchanged, and a lapsed name is available to whoever wants it.
This asymmetry between layers is the most misunderstood feature of the topic. Persistence on a blockchain is a property of replicated state, held by thousands of nodes with no coordination from the original authors. Presence on the web is a service someone pays for monthly and can stop paying for, so readers who assume the two rise and fall together go wrong in both directions.
Legal developments complicate the picture without resolving it. When Treasury published the action notice recording the March 2025 delisting, coverage prompted a wave of pages announcing relaunches and restorations. A change in sanctions status is a change in one government’s list, and it does not create, restore or endorse any interface.
What questions replace asking for the official site?
Four better ones: who publishes this page and can that be checked independently, what is it asking me to do, what would it gain if it were dishonest, and what would I lose if I were wrong. These move the inquiry away from identity, which is frequently unverifiable here, toward consequence, which almost always is.
Identity questions fail here because they assume a registry of legitimacy that does not exist. There is no authority to consult and no signature a reader can check against a known key belonging to a party still around to defend it. Asking which page is real invites a confident answer from whichever page is most motivated to give one.
Consequence questions behave better because they can be answered from what is in front of you. A page asking to be read costs you no more than bad information. A page asking a wallet to connect and approve is asking for authority over assets, and its worst case is the loss of everything that wallet controls. That asymmetry deserves far more weight than visual polish. For a reader whose purpose is understanding, the contracts are visible on public block explorers and the sanctions history sits in government publications, neither of which needs a wallet or an answer to the official question.
Five referents that share one name
The table sets the categories side by side, since the practical risk depends far more on which kind of page you have landed on than on the name in the address bar. It orients you to the landscape rather than judging any particular page.
| What you may have landed on | What it actually is | Why the distinction matters |
|---|---|---|
| The original project interface | A front end published by the associated team, unmaintained since 2022 | A page claiming to continue it asserts what nobody can confirm |
| A community-built alternative | Independent software that builds transactions for the same public contracts | Provenance varies and no authority vouches for any of them |
| An archived snapshot | A historical copy of a page as it appeared on a given date | Useful as a record, misleading if read as a working service |
| Documentation or a code repository | Descriptions of the design and the source that implements it | The most informative referent and the least demanding of a wallet |
| An impersonating page | A page built by an unrelated party to be mistaken for one of the above | Built to obtain keys, approvals or payment |
One row differs from the rest in a way worth noticing. Only the last category has an active interest in you believing that the question has a single clean answer, because ambiguity is the condition it exploits.
Frequently asked questions
Does a paid search advertisement carry any vetting?
Advertising placement reflects payment and policy review, not verification that an advertiser is who it claims to be. Advertisements have repeatedly put impersonating crypto pages above genuine results, and enforcement tends to arrive after the fact.
Is an archived snapshot of an old interface safe to open?
An archive is a historical record rather than a live service, and reading one differs from interacting with it. Treat an archived interface as a document to look at rather than software to connect a wallet to, since archived pages can still run scripts and are not curated for safety.
Do browser extensions or app listings using the name indicate endorsement?
No. A listing means a publisher submitted software and passed an automated review, not that any project authorized the use of its name. Name reuse in extension stores is a documented route for wallet-draining software, so store presence is not provenance.
What if a page displays a contract address as proof it is authentic?
Displaying an address proves nothing, because any page can print any string and a visitor comparing long hex values by eye is easy to fool. It is a common signal in impersonating pages precisely because it looks technical while costing the publisher nothing.