Tornado.cash: What Happened to the Code Repositories

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

Tornado.cash produced one of the clearest recent tests of what happens when source code becomes the object of an enforcement response. Hosted repositories were restricted after the August 2022 sanctions action, access was later partly restored, and a long argument about whether publishing code is protected expression ran alongside both events. The episode is worth understanding on its own terms, because the technical facts constrain what any such measure can achieve.

What happened to the repositories after August 2022?

Following the designation, code hosting for the project was restricted and associated developer accounts were affected, so the canonical published copies of the source stopped being reachable in the ordinary way. Access to archived material was later partly restored. Nothing in either step altered the contracts already deployed on Ethereum.

The immediate reaction was widely reported as a takedown, but the mechanism was narrower than that word suggests. A hosting platform made an account-level decision under sanctions compliance pressure, which is a contractual and administrative act rather than a judicial finding that the material was unlawful. That distinction mattered later, because it meant the decision could be revisited without any court reversing anything.

What the restriction actually removed was discoverability and reference. Developers, auditors and researchers who wanted to read the code lost the obvious place to read it, and links in older articles and papers stopped resolving. For a project whose central claim was that anyone could inspect its behavior, losing the public reference copy was a real loss even though execution was unchanged.

Why is publishing source code treated as a free-expression question?

Because source code is human-readable text that explains a method, and courts in the United States have long treated the publication of such text as speech even when the method described has practical uses. The argument is not that code is harmless; it is that restricting its publication is a restriction on communication and needs to be justified as such.

The reasoning developed in cryptography disputes decades before this case. Publishing an algorithm in a book, a paper or a repository was held to be expressive activity, and the fact that a compiler can turn the same text into a running program did not remove it from that category.

Critics of the position emphasize function over form. Where text is directly executable, they argue, its publication is closer to distributing a tool than to describing an idea, and the analysis should follow the effect rather than the format. Courts have not adopted a single settled rule here, and this remains genuinely unsettled law rather than a question with a clean answer.

The distinction that matters most in practice is between publishing and operating. Prosecutions in this area have not rested on the bare act of publishing text; they have alleged conduct, such as running or profiting from a service. That framing is why the developer cases turned on what individuals did rather than on what they wrote.

How can you assess whether a code repository is the authentic one?

You assess it by reading the commit history rather than the landing page, checking whether the platform labels it a fork, comparing the source against verified on-chain code, treating added network calls as a warning sign, and recording what you checked and when. This is a verification procedure for researchers, not guidance about using any software.

Step 1: Look at the commit history, not the landing page

Open the full commit history and read the earliest entries, because a genuine long-lived project shows years of incremental work while a recent copy shows a single bulk import. Presentation is trivial to imitate and history is not.

Step 2: Check whether the platform marks it as a fork

See whether the hosting platform labels the repository as a fork and which upstream it names, since that label is generated by the platform rather than written by the account holder. Platform-generated metadata is far harder to fake than a description field.

Step 3: Compare the source against verified on-chain code

Compare the contract source in the repository with the verified source published for a deployed address on a public block explorer, because the chain holds the authoritative copy of what actually runs. A repository is a claim about the code, while the chain is the code.

Step 4: Treat added network calls as a warning sign

Note whether a copy has introduced code that contacts external servers or alters addresses relative to the version it claims to reproduce, since such additions are the usual signature of a tampered copy. Differences of that kind deserve more weight than a plausible-looking readme.

Step 5: Record what you verified and when

Write down which repository you examined, what you compared it against and the date, because repositories change and an undocumented conclusion cannot be rechecked later. A dated note also lets a colleague reproduce your finding.

Why does removing a repository fail as a control?

Because distributed version control makes every clone a complete copy. Anyone who had downloaded the project held the full history locally, and a hosted copy is a convenience rather than an original. Removing the hosted page reduces discoverability while leaving an unknown number of independent copies untouched.

The structure of these systems was designed for exactly this resilience, though for mundane reasons rather than adversarial ones. Distributed tooling was built so that developers could work offline and so that no single server outage would destroy a project’s history. The property that protects a team from a failed hard drive also protects a codebase from removal.

Publication makes the effect permanent. Once source has circulated widely, copies exist across archives, package caches, security research collections and other developers’ machines, and no party has an inventory of them. The question after removal is not whether copies survive but how easily one can be found, which is a much weaker form of control.

Repository measures compared with other controls

Set against the other layers involved in this episode, repository restriction is an unusually weak instrument. The table compares what each measure targets and how durable its effect is, described generally rather than as a statement about any current arrangement.

Measure	What it targets	Durability of the effect
Repository restriction	The canonical hosted copy of readable source	Low, because every clone is a full copy
Naming and hosting action	The familiar address of a public interface	Low to moderate, since interfaces are small and portable
Financial-edge screening	Funds crossing regulated exchanges and banks	High, because it is applied continuously by licensed firms
Sanctions designation	Named parties and identifiers on a published list	Variable, since listings are added and removed over time
Criminal prosecution	The conduct of identified individuals	High, and independent of any list or platform decision

The pattern in the table explains why the repository question receives more attention as a matter of principle than as a matter of effect. Its practical consequences were limited, while the precedent it raised about restricting published text was not.

What did the partial restoration actually settle?

Very little on its own. Restoring access to archived code is a platform decision reflecting a changed compliance assessment, not a legal ruling and not a statement that publication was always permissible. It made historical material readable again without resolving any of the underlying questions.

The legal record moved separately and by its own logic. In November 2024 the Fifth Circuit held in Van Loon v. Department of the Treasury that immutable smart contracts were not property under the governing statute and could not be designated, and in March 2025 Treasury removed the name from the sanctions list, so it is not currently designated. Neither event addressed the status of published source code directly.

The developer cases likewise turned on conduct rather than publication. Alexey Pertsev was convicted in the Netherlands in May 2024 and sentenced to 64 months, then conditionally released in February 2025 with an appeal pending. In August 2025 a jury convicted Roman Storm on one count of conspiracy to operate an unlicensed money transmitting business and deadlocked on two further counts, and a retrial is scheduled for April 26, 2027 in the Southern District of New York.

The honest summary is that the boundary remains unsettled and fact-dependent. Courts have engaged with operation, control and intent rather than the act of making text public, and a specific situation calls for qualified legal advice rather than inference from these outcomes.

Frequently asked questions

Does removing a repository delete copies people already have?

No. Distributed version control gives every person who cloned a project a complete copy of its history on their own machine. Removal affects the hosted copy and the convenience of finding it, not the copies already distributed.

Is a fork an endorsement by the original authors?

No. Anyone can fork a public repository without permission or notice, and the resulting copy can be modified freely. A fork indicates a shared starting point in the commit history and says nothing about who maintains it or whether the original authors are aware of it.

What is the difference between source code and deployed bytecode?

Source code is the human-readable text a developer writes, while bytecode is the compiled form actually stored and executed on the chain. A repository can be edited at any time, so comparing it against the verified source for a deployed address is the only way to know they correspond.

Does a restored repository mean a project is actively maintained?

Not by itself. Restoring read access to an archive is a hosting decision, and it says nothing about whether anyone is reviewing issues, applying fixes or continuing development. Commit dates and issue activity are better indicators than the mere presence of a page.