A few weeks ago, I was auditing a new privacy-focused L2. The code was elegant—zero-knowledge circuits, efficient merkle trees, a clean frontend. As I traced the data flow, a cold realization hit me: every line of this protocol could, under current US Treasury interpretations, be considered a crime. The same logic that landed Alexey Pertsev in a Dutch prison applies here. The only difference? His bug was more successful.
I’ve been in this space since 2017, watching whitepapers promise paradise while their tokenomics crumbled. But the Tornado Cash sanctions pierced something deeper than market volatility. They struck at the very foundation of open-source development. If writing a privacy protocol is illegal, then we’re not building a permissionless future—we’re building a permissioned one, with code as the crime.
Context: The Sanctions Precedent
In August 2022, the US Treasury’s OFAC sanctioned Tornado Cash, a non-custodial Ethereum mixer. They added its smart contract addresses to the SDN list, making it illegal for US persons to interact with them. This wasn’t a ban on a company; it was a ban on immutable code. The Treasury argued that Tornado Cash’s privacy features enabled money laundering, particularly by North Korea’s Lazarus Group. But here’s the problem: Tornado Cash is a protocol, not an entity. It has no CEO, no headquarters, no exit button. The sanctions effectively criminalized the act of using a specific technical tool.
Since then, the ripple effects have been devastating. Alexey Pertsev, Tornado Cash developer, remains in pre-trial detention in the Netherlands. Roman Storm faces trial in the US on conspiracy charges. GitHub has removed developer accounts just for reading documentation. The message is clear: write code that could be used for privacy, and you are complicit in any crime that code enables.
Core Analysis: The Code-as-Instrument Fallacy
Let’s get technical. Tornado Cash uses a smart contract that accepts ETH deposits and allows withdrawals with a zk-proof of deposit, breaking the on-chain link between sender and receiver. It is purely automated. No human makes decisions about which transactions to process. The code executes impartially for everyone, including criminals—just like email protocols enable phishing, or TCP/IP enables illegal file sharing.
Yet the legal argument rests on a dangerous premise: that writing and publishing code is equivalent to providing a service. Under this logic, every open-source developer becomes a potential felon. Look at the sheer volume: over 40 million lines of code are committed to public repositories every day. Every one of them could theoretically be used for crime. The Treasury’s interpretation creates a chilling effect that undermines the entire open-source ecosystem.
Based on my audit experience, I’ve seen how developers intentionally limit protocol functionality to avoid regulatory risk. During the bear market, I led a values audit at my own lending protocol. We discovered that our “decentralized” governance was actually controlled by three multisig signers. We changed it—but only because we could. Many protocols cannot. The Tornado Cash precedent forces privacy protocols to either pivot to centralized KYC or shut down. That’s not innovation; that’s conformity.
The numbers back this up. Since the sanctions, development activity on privacy-focused Ethereum projects dropped over 30%, according to Electric Capital’s 2023 developer report. Several promising zk-rollups changed their tokenomic designs to avoid any possible mixer-like association. The chilling effect is measurable.
Contrarian Angle: The Pragmatist’s Counter
But let’s play the devil’s advocate—because debate is the compiler for better consensus. Some argue that OFAC had no choice. North Korea allegedly laundered over $1 billion through Tornado Cash in 2022. The sanctions did reduce illicit flows. Furthermore, they argue, code is not speech; it is action. A smart contract executes automatically, and if that action facilitates a crime, the developer should be liable.
I understand this logic. It appeals to our desire for accountability. But it misses a critical distinction: intent and control. A knife manufacturer is not responsible when someone stabs another person. The law recognizes that tools have non-criminal uses. Tornado Cash is a tool for privacy, which is a fundamental human right. Over 50% of Tornado Cash users used it for legitimate purposes—donations, payroll, or simply avoiding surveillance capitalism. Punishing the tool punishes the victims too.
Moreover, the sanctions are technically unenforceable. Tornado Cash’s smart contracts still exist on the Ethereum blockchain. Anyone with an internet connection can interact with them from anywhere. The sanctions only criminalize the interaction for US persons, creating a patchwork of compliance that hurts innovation in the US while pushing it elsewhere. The biggest beneficiaries are non-US privacy protocols like Railgun and Secret Network, which have seen increased usage.
Takeaway: A Fork in the Road
We stand at a juncture. The crypto industry can accept the sanctions as a fait accompli and build privacy tools with KYC layers, essentially surrendering to centralized oversight. Or we can fight back—legally, technically, and rhetorically. The Tornado Cash case is now before the Supreme Court in the Netherlands. The outcome will define whether open-source code is protected speech or regulated conduct.
True ownership begins where the server ends. If we cannot write and deploy immutable privacy protocols, then the blockchain becomes just another database owned by the state. The question isn’t whether Tornado Cash’s code should have been sanctioned. The question is whether we want a future where code is law, or law is code—with no escape.
I don’t have answers. But I know that debate is the compiler for better consensus. It’s time to compile a better one.