A 25-year-old developer sits in a Dutch prison cell. His crime? Writing code. Not exploiting it, not stealing funds, not defrauding users. He wrote open-source software that others used to obfuscate transactions. The software is a tool, like a hammer. But hammers don't go to jail. Alexey Pertsev does.
Pertsev is the lead developer of Tornado Cash, a privacy mixer on Ethereum. In August 2022, the U.S. Treasury’s OFAC sanctioned the smart contract addresses, making it illegal for Americans to interact with the protocol. Then the Dutch authorities arrested Pertsev. He has been detained for over a year awaiting trial. The charge? Money laundering, under the premise that he helped criminals hide illicit funds.
This is not a legal anomaly. This is the new frontier of crypto regulation. And it terrifies me.
Context: The Precedent That Wasn’t Supposed to Happen
Tornado Cash is a non-custodial, immutable smart contract. It does not accept deposits. It does not have a CEO. It is a set of deterministic rules running on a global computer. Users deposit ETH, and can withdraw from a different address using a cryptographic proof — a zero-knowledge proof. The privacy is its value. But the same privacy can be used by bad actors — the Lazarus Group, ransomware operators, and other sanctioned entities.
In 2022, OFAC sanctioned the Tornado Cash contract addresses, effectively banning the software itself. This was unprecedented. Sanctions traditionally target individuals or entities, not code. The subsequent arrest of Pertsev signaled that the government intended to hold developers personally liable for the misuse of their tools.
Now, the legal case against Pertsev is moving forward. The Dutch court has accepted the indictment. The argument: Pertsev designed a system that facilitated criminal activity, and he failed to implement adequate controls. The defense: the code is neutral, and the developer cannot control how it is used post-deployment.
This case is not just about Tornado Cash. It is about every open-source developer who writes code that could be used for privacy. And that is a very long list.
Core: The Moral Imperative of Precision — and Its Limits
I have spent years auditing smart contracts. In early 2017, I manually audited a DAO protocol called EthicChain. I found twelve critical reentrancy vulnerabilities that could have drained $4 million. I published a detailed open-source report. I believed then — and I still believe — that technical precision is a moral imperative. Code must be correct, secure, and transparent. But that precision is now being weaponized against developers.
The argument against Pertsev hinges on the idea that he could have designed the mixer differently. That he could have added a process to filter out known criminal addresses. That he could have implemented a "circuit breaker" to freeze assets. But that would defeat the purpose of a non-custodial mixer. It would centralize control. It would make the system vulnerable to coercion.
The core insight is this: The legal system is demanding that developers build in a way that contradicts the fundamental principles of decentralization.
If you build a truly decentralized, censorship-resistant system, you are liable for the illegal actions of your users. If you build a centralized, controlled system, you are not a blockchain developer — you are a fintech company. The choice is binary. And the legal system is pushing developers toward the latter.
This is not about privacy vs. security. This is about the boundaries of software liability. The code is not the agent. The developer is not the guardian. Yet the courts are treating them as such.
Contrarian: The Case for Developer Responsibility
Let me play the devil’s advocate. Some argue that developers have a responsibility to anticipate the misuse of their tools. If you build a gun that can be easily converted to full-automatic, you are liable for the resulting harm. If you build a mixer that explicitly facilitates money laundering, you are complicit.
There is some truth here. The Tornado Cash interface did not include any KYC. The documentation referenced "privacy" but did not warn against illegal use. The developers could have implemented a blocklist of known sanctioned addresses — it is technically possible. The fact that they did not suggests a certain willful ignorance.
But this argument collapses under the weight of scale. Open-source software is used by billions. The Linux kernel is used in servers, but also in missile guidance systems. Should Linus Torvalds be held liable for every missile strike? The answer is no. The law recognizes a distinction between building a general-purpose tool and building a weapon specifically designed for harm.
The Contrarian angle: The real blind spot is not the developer’s intent, but the government’s inability to distinguish between code and speech.
Writing code is a form of speech. It expresses ideas. The Supreme Court has ruled that encryption code is protected speech. But the Tornado Cash case is testing that boundary. If the code is itself illegal, then the developer is punished for the content of the speech. That is a First Amendment crisis.
Moreover, the sanctions treat the smart contract as a "property interest" of the developer. But the contract is not owned by anyone. It is a self-executing program. Sanctioning the address is like sanctioning a mathematical equation. It is nonsensical.
Takeaway: The Only Way Forward Is to Build for Solitude
I have seen the future. It is not bright. The legal pressure will only intensify. The Tornado Cash case is a warning shot. The next target could be any protocol that enables privacy, anonymity, or censorship resistance. The developers of Bitcoin, Monero, Zcash, and even Ethereum’s own privacy solutions are now at risk.
What can we do? The answer is not to capitulate. The answer is to build systems that are so distributed, so immutable, so autonomous that no single jurisdiction can hold them. That means deeper integration of zero-knowledge proofs, decentralized governance, and legal wrappers that protect developers.
But this is a hack, not a solution. The real solution is to change the legal framework. To argue that code is speech. To argue that developers are not liable for the actions of anonymous users. To argue that privacy is a fundamental right.
Until then, every line of code you write could be your last. Every commit could be evidence. Every open-source repository could be a target.
Trust no one, verify the solitude. The code is not the crime. The crime is the silence of the legal system.
Speed kills. Precision saves. But only if the law is precise enough to distinguish between the hammer and the hand that swings it.
Audit the algorithm, not just the code. The algorithm is the government’s intent. The code is your defense.
I am not afraid. I am vigilant. You should be too.