Tornado Cash Crypto and the Crypto Mixer Category
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 crypto reporting almost always uses the phrase crypto mixer, and the phrase does a great deal of quiet damage. It covers custodial businesses that take possession of customer funds, non-custodial contracts that never hold anything, and coordination schemes where participants keep their own keys throughout. This article separates those arrangements and explains why collapsing them into one word produces confused coverage and confused policy.
What does the label crypto mixer actually cover?
It covers any arrangement whose purpose is to weaken the link between where value came from and where it went. That is a statement about intent rather than about architecture, so the label attaches equally to a company with employees and bank accounts and to contracts no person controls. The word describes an aim, not a structure.
This is unusual among financial categories. Terms such as broker, custodian or exchange describe what a firm does with client assets, which is what makes them useful in regulation. A label defined by an intended effect gives no answer to the questions that actually matter legally: who holds the funds, who decides that a transfer happens, and who can be told to stop.
The result is a category that groups together arrangements with almost nothing in common operationally. Two systems described in the same sentence of a news report may differ on every fact a lawyer or compliance officer would want to know, which is why the label is a poor starting point for any concrete question.
How do custodial and non-custodial designs differ?
A custodial service takes possession of user funds and sends back different coins from its own holdings. A non-custodial design never takes possession, because value stays in a contract that releases it against a proof rather than on anyone’s instruction. That difference determines whether an operator exists, and almost every legal consequence follows from it.
Custodial mixing is the older model and the simpler one to reason about. Someone runs the service, holds a float, sets the fee and can in principle refuse a customer, freeze a balance or hand over records. It is also the model where users bear counterparty risk, because a service that holds funds can lose them, steal them or be seized.
The non-custodial pattern removes the operator by construction. In the design at issue here, a deposit records a commitment derived from a secret the user keeps, and a withdrawal presents a proof and a nullifier so the contract releases each deposit exactly once. The core pool contracts were deployed with no owner, no pause and no upgrade path, so there was nobody to license, subpoena or instruct.
That absence is what drove the whole legal argument. When no operator exists, enforcement moves toward whoever is adjacent, which is why developers, governance participants and relayers became the subjects of proceedings rather than the contracts themselves.
Where do coordination-based approaches fit?
They sit between the two, because participants keep control of their own keys while a coordinator arranges a joint transaction. Nobody takes possession, yet a party performs an organising function and may charge for it. The result is a system with no custodian but with an identifiable participant who is doing something more than publishing code.
The mechanics are different from a pool. Instead of depositing into a contract and later withdrawing, several users construct one transaction together, so that inputs and outputs cannot be matched to each other with confidence. Funds never leave the users’ control at any point, and the privacy gained is again a function of how many participants join.
This middle position is exactly where categorisation gets difficult. A coordinator who never holds value looks nothing like a custodial service, but also does more than write software, and the question of whether such a role amounts to operating a money transmitting business has been argued rather than settled. The same question recurs for relayers who submit a withdrawal and pay its gas for a fee.
How can you classify a service by its custody model?
You ask whether anyone can take possession, identify what triggers a release of funds, check the code for administrative powers, trace who earns a fee and for what, and then record your conclusion with the evidence behind it. The procedure below is a research method for reading a system’s design, not guidance on interacting with one.
Step 1: Ask whether anyone can take possession
Determine whether any party ever controls the funds, meaning whether a key held by a person or company could move them somewhere the depositor did not choose, because that single fact separates custody from every other arrangement. Marketing language is not evidence either way here.
Step 2: Identify what triggers a release of funds
Find out what causes value to leave the system, whether it is an operator’s decision, an automated instruction or the presentation of a cryptographic proof, because the trigger tells you where discretion sits. Discretion is what regulators generally treat as the mark of a service.
Step 3: Check the code for administrative powers
Read the verified contract source for owner variables, pause switches, upgrade proxies or privileged roles, because a system described as non-custodial can still contain a key that lets someone intervene. An upgradeable contract is effectively controlled by whoever holds the upgrade right.
Step 4: Trace who earns a fee and for what
Work out which parties are paid and what service the payment corresponds to, because fee flows usually reveal the participants a regulator will treat as performing a function even when the core system holds nothing. Fees are also where the difference between a protocol and a business tends to appear.
Step 5: Record the classification with its evidence
Write down your conclusion together with the specific evidence for it and the date you checked, because custody arrangements change when code is redeployed or a front-end is replaced. A dated note with reasons is what makes a classification reviewable later.
Why does one label across all of them confuse reporting?
Because a reader who learns a fact about one arrangement applies it to all of them. A seizure of a custodial operator’s float becomes evidence that mixers can be shut down, and a ruling about immutable contracts becomes evidence that mixing has been declared lawful. Neither inference survives contact with the underlying differences.
The pattern repeats across the coverage of a single case. The Fifth Circuit held in November 2024 that immutable smart contracts are not property that can be designated, a conclusion that depends entirely on the contracts having no owner, and it was widely reported as a general verdict on mixing services. Treasury then recorded the removal from the sanctions list in March 2025, which was reported as a broader vindication than the record supports.
The same flattening runs the other way. A jury convicted Roman Storm in August 2025 on one count of conspiracy to operate an unlicensed money transmitting business and deadlocked on two others, which many summaries rendered as a finding that non-custodial software is illegal. It was a verdict about the conduct of a person, on specific counts, with a retrial on the hung counts scheduled for April 2027.
For a reader trying to form an accurate picture, the corrective is to refuse the category and ask the structural questions instead. Who held the funds, who could stop the system, and who was paid are answerable about any specific arrangement, and the answers rarely transfer from one to another.
Mixing arrangements compared
The differences are easiest to see when custody and responsibility are set out per arrangement rather than described in prose. The table summarises the structural facts that legal analysis usually turns on. It describes general patterns and is not an assessment of any particular service.
| Arrangement | Who holds the funds | Who can be held responsible |
|---|---|---|
| Custodial mixing service | The operator takes possession and returns different coins | An identifiable operator controlling customer funds |
| Non-custodial pool contract | Nobody; the contract releases each deposit against a proof | Contested, and argued so far through developers and adjacent parties |
| Coordination of joint transactions | Participants keep their own keys throughout | A coordinator who organises without ever holding value |
| Relayers and front-ends | Neither holds pooled funds | Unsettled, since each touches the transaction without controlling it |
| Protocol-level privacy on a chain | Not a service; concealment is a property of the network | No separable provider to license or designate |
Reading down the middle column shows how little the shared label explains. Two rows can attract the same word in a headline while differing on the only fact that determines what any rule can attach to.
Frequently asked questions
Is a centralised exchange a mixer if it pools customer deposits?
Pooling is a normal feature of custodial finance and is not what the label is aimed at, since the purpose of an exchange is trading rather than breaking a transaction trail. The distinguishing question is whether obscuring the link between inflows and outflows is the point of the service or an incidental effect of how it operates.
Does the word tumbler mean something different from mixer?
The two terms are used interchangeably in practice, with tumbler being the older usage from Bitcoin-era services. Neither word carries a technical definition precise enough to tell you about custody, so both require the same underlying questions to be asked.
Why do compliance systems flag funds regardless of the category?
Risk-based programmes score the observable fact that funds passed through a design intended to break traceability, which is visible on chain whatever the custody arrangement behind it. That is why a flag can appear even where the underlying system was never designated and no allegation attaches to the user.
Did the delisting change how the category is treated?
It changed the status of one name on one list and nothing about the category as a whole. Institutions continued to apply their own risk controls to funds associated with any mixing design, because those controls were never keyed to sanctions list membership in the first place.
