The Tornado Cash saga produced two distinct legal outcomes that are frequently conflated: the OFAC sanctions designation and the developer criminal prosecution. These are separate legal theories with separate implications. Understanding both, and what the Fifth Circuit appeals ruling actually said, is essential context for anyone building or using privacy protocols in 2026.
What Tornado Cash Actually Was
Tornado Cash was a set of open-source smart contracts deployed on Ethereum. The contracts implemented a cryptographic mixing function: users deposited a fixed denomination of ETH or ERC-20 tokens, received a private "note," and could later withdraw the same amount to a different address using that note as a zero-knowledge proof of deposit. The contracts were immutable — once deployed, no one, including the original developers, could modify or stop them.
Tornado Cash was not custodial. The contracts never held funds on behalf of users in the traditional sense — they held pooled funds, and possession of a valid note gave the holder the right to withdraw. The developers created and deployed the contracts but could not access the funds, alter the rules, or shut it down.
What the OFAC Designation Said
In August 2022, the US Treasury's Office of Foreign Assets Control (OFAC) added Tornado Cash to the Specially Designated Nationals and Blocked Persons list. This was unprecedented: OFAC had previously sanctioned people and specific addresses associated with bad actors, but this was the first time a set of autonomous smart contract addresses was itself designated — independent of any person controlling it.
The designation prohibited US persons from interacting with the Tornado Cash contracts. It also caused many exchanges and dApps to block addresses that had ever interacted with Tornado Cash, creating a de facto blacklist across the ecosystem. The practical effect was significant: Tornado Cash usage dropped dramatically, and developers associated with the project faced criminal charges.
The Fifth Circuit Appeals Ruling
In November 2024, the United States Court of Appeals for the Fifth Circuit ruled in Van Loon v. Department of the Treasury, finding that immutable smart contracts cannot be sanctioned under the International Emergency Economic Powers Act (IEEPA). The ruling turned on a specific statutory question: whether immutable smart contract code constitutes "property" of a foreign national or entity (a requirement for OFAC sanctions). The Fifth Circuit found that it does not — an immutable contract has no owner who can exercise control over it, and therefore it is not "property" subject to OFAC designation.
This ruling did not say that mixing is legal. It did not say that using Tornado Cash is legal. It said that sanctioning the contract addresses themselves — as if the contract code were property belonging to a sanctionable entity — was outside OFAC's statutory authority. The ruling was narrow, applying specifically to the immutable contract pool contracts; mutable contracts or governance contracts were treated differently.
What It Means for Privacy Protocol Builders
The Fifth Circuit ruling clarifies one important boundary: building and deploying immutable open-source cryptographic infrastructure is distinct from being a money transmitter or financial institution subject to AML/KYC obligations. Tools are not laundering. The existence of privacy-preserving code does not make its authors liable for what people do with it, absent specific knowledge of and intent to facilitate illegal activity.
However, the ruling does not clear a path for developers to operate custodial services, centralized front-ends that facilitate sanctioned activity, or governance roles over contracts used primarily for illegal purposes. The boundary it draws is specifically around immutable, non-custodial, open-source code. Protocol builders who want to stay within this boundary must design accordingly: immutability, non-custody, and open-source publication are legally meaningful properties.
The Developer Prosecution: A Separate Question
The criminal prosecution of Tornado Cash developer Roman Storm (and separately, Roman Semenov) proceeded on different legal theories than the sanctions designation. The government's case rested on conspiracy to commit money laundering, unlicensed money transmission, and sanctions violations — theories that focus on the developers' alleged knowledge that the tool would be used for illegal purposes and their alleged participation in its operation as a service.
The developer prosecution raises a different set of questions from the sanctions case: at what point does building and maintaining a privacy tool become criminal facilitation of money laundering? This question remains unresolved in the US legal system. The prosecution is ongoing as of this writing, and its outcome will significantly shape the legal landscape for open-source cryptography development.
What Compliance-Compatible Privacy Looks Like
The legal environment post-Tornado Cash has pushed privacy protocol design toward what might be called "compliance-compatible privacy": systems that provide strong privacy by default while enabling selective, auditable disclosure for legitimate purposes. The key technical mechanism is the viewing key.
A viewing key is a cryptographic key derived from the user's spending key that allows the holder to decrypt and read all transactions associated with a shielded address, without the ability to spend funds. A user can share their viewing key with a tax authority, auditor, or regulated exchange to prove their transaction history — a selective disclosure mechanism that does not compromise other users' privacy.
This design pattern — privacy by default, auditable by key — separates the concerns of financial privacy from the concerns of regulatory evasion. It provides no additional protection to someone trying to hide illegal activity from a court order (because courts can compel key disclosure), but it provides strong protection against casual surveillance, data collection, and the financial exposure that public ledgers create for law-abiding users.
Why Sanect's Design Considers This
Sanect's shielded pool design includes viewing keys as a first-class concept. Each shielded address has a corresponding viewing key, derivable from the user's MetaMask signature. The viewing key enables scanning for incoming notes (so wallets can find their own transactions) and enables selective disclosure to authorized parties.
This is not a backdoor. The viewing key does not give Sanect, its developers, or any government party automatic access to transaction data. It is a capability the user holds and can choose to exercise selectively. A user who shares their viewing key with their accountant has not given anyone else access — only the specific recipient of the key gains visibility. The key can be shared per-transaction, per-period, or for the full account history, depending on what level of disclosure is appropriate.
Building with viewing keys from the start is not compliance theater — it is a design choice that makes the privacy system useful in the real world, where legitimate users sometimes need to prove their transaction history, without undermining the privacy of users who have no such need.