On October 6, 2026, the Financial Crimes Enforcement Network published a withdrawal notice. The agency abandoned its proposed rule that would have forced financial institutions to collect and report identifying data on every customer who touched a mixer. The same week, in a federal courtroom in lower Manhattan, a prosecutor stood up and told Judge Katherine Failla that a software developer should spend years in prison for writing code.
Both events are real. Both events are government policy. They cannot both be coherent.
That is the first thing you notice when you audit systems: when two components of the same machine issue contradictory instructions, the machine does not become flexible. It becomes broken. The Treasury Department's retreat and the Department of Justice's advance are not a nuanced balancing act. They are a fork in the consensus layer of American financial policy, and the network has not resolved it.
I have spent the last several months reading the filings in United States v. Storm, cross-referencing them against the FinCEN notice, the Sterlingov appellate record, and the policy memos that quietly circulate between agencies. What I found is not a story about privacy. It is a story about jurisdiction, about who gets to define what a software developer is, and about whether the word 'decentralized' means anything at all in a courtroom. The answer to that last question, so far, is no — and the cost of that answer will be paid by every developer who ships code that anyone else can use.
Let me show you the logs.
The Case, Stripped to Its Mechanical Parts
Tornado Cash is a privacy protocol on Ethereum. Users deposit funds into a smart contract, and later withdraw the same denomination from a different address, breaking the on-chain link between sender and receiver. The mechanism relies on zk-SNARKs — zero-knowledge succinct non-interactive arguments of knowledge — to prove that a withdrawal is valid without revealing which deposit it corresponds to. This is a genuine cryptographic achievement. It was also, for years, the most widely used privacy tool in the Ethereum ecosystem.
In August 2022, the Office of Foreign Assets Control sanctioned Tornado Cash, adding the protocol's smart contract addresses to the Specially Designated Nationals list. This was the first time the U.S. government sanctioned software rather than a person or an entity. The technical community objected on grounds that were correct in principle and irrelevant in practice: you cannot sanction code, because code has no agency, no bank account, and no will to punish.
The government then did the thing that follows logically from treating code as an actor. It indicted the people who wrote it. Roman Storm was arrested in August 2023. Roman Semenov was charged in absentia and remains at large. The charges: conspiracy to commit money laundering under 18 U.S.C. § 1956, conspiracy to operate an unlicensed money transmitting business under 18 U.S.C. § 1960, and conspiracy to violate the International Emergency Economic Powers Act.
One count has already produced a conviction. The others are still being litigated, and the litigation has now narrowed to a single procedural question that will determine the shape of everything that follows: venue. Where can the government try this case, and on what theory of jurisdiction?
The prosecutor's answer, delivered in the most recent hearing, is that a customer named Shakeeb Ahmed made deposits from New York, and that this contact is sufficient to establish that Tornado Cash was 'doing business' in the Southern District of New York. The defense's answer is that a developer who never set foot in the district, who operated a protocol that runs on thousands of nodes worldwide, cannot be said to have conducted business there because a user chose to interact with an immutable contract.
This is not a technicality. Venue is the question of whether the state has any legitimate claim to adjudicate the conduct at all. If the answer is yes on these facts, then every developer of every permissionless protocol is subject to the jurisdiction of any district where any user has ever transacted. That is not a legal doctrine. That is a global dragnet with a courthouse attached.
What 'Decentralization' Has to Prove
The heart of the case is a semantic dispute that the government has been quietly winning.
The defense argues that Tornado Cash is decentralized software. The smart contracts are immutable. No single party can alter them, freeze them, or reverse a transaction. Users interact peer-to-peer with the protocol. The developers built a tool and walked away, and the tool kept running because it was designed to run without them.
The prosecution's counter-argument is more sophisticated than the caricature suggests. The DOJ does not claim that Storm controlled every transaction. It claims that Storm built the protocol, maintained the front-end interface through which most users accessed it, operated relayers that subsidized withdrawal fees, and — this is the load-bearing beam — continued to profit from the protocol's operation through the TORN governance token.
That last point deserves close attention, because it is where the case stops being about privacy and starts being about economics. The TORN token is a governance and utility token. If Storm held it, voted with it, and benefited from its appreciation, then the government can argue that he was not a distant architect but an ongoing operator with a financial interest in the protocol's throughput. In that framing, decentralization is not a technical property. It is a marketing claim that the token distribution quietly contradicts.
I have made this argument before, in a different context. When I analyzed Compound Finance's governance mechanism in 2020, I found that a combination of low voter turnout and the absence of quadratic voting safeguards allowed a single whale to hijack governance and dilute the COMP token. The report was titled 'The Illusion of Decentralization,' and its central finding applies here with uncomfortable precision: governance tokens do not distribute power. They distribute the appearance of power while concentrating the economic upside in the hands of whoever holds the largest position. The prosecution has not cited my work, but the logic is identical. A token that lets insiders capture value from a protocol's operation is evidence that the insiders are still operating the protocol.
This is the trap that privacy projects have walked into, and most of them have not yet noticed. They deploy a token because tokens fund development. The token creates a class of holders with a financial interest in usage. The financial interest creates a paper trail. The paper trail becomes Exhibit A in a criminal trial where the charge is, essentially, 'you benefited from the thing you built.'
The defense has a response, and it is not weak. It argues that the immutable contracts mean the developers cannot control compliance outcomes. Once deployed, the code executes as written. The team cannot block a sanctioned address. The team cannot refuse a deposit. If the team has no control, the argument goes, the team has no responsibility. This is the strongest technical defense in the case, and it is also the one the prosecution has worked hardest to neutralize.
The Sterlingov Precedent and the Expansion of Liability
To understand how the government plans to win, you have to look at a case that has nothing to do with Tornado Cash and everything to do with it: United States v. Sterlingov.
Roman Sterlingov operated Bitcoin Fog, a centralized mixing service that predated Tornado Cash and lacked any of its cryptographic sophistication. Bitcoin Fog was custodial. Users handed their coins to an operator who mixed them and returned them. There was no zero-knowledge proof, no immutable contract, no pretense of decentralization. Sterlingov was convicted of money laundering and operating an unlicensed money transmitting business. His appeal is pending.
The DOJ is now using the Bitcoin Fog conviction as a template and stretching it across the Tornado Cash facts. The argument runs like this: if operating a centralized mixer is money transmission, and if the operator of that mixer is criminally liable for the illicit funds that passed through it, then operating a decentralized mixer is also money transmission, and its architects are liable on the same theory.
The stretch is obvious, and the government knows it. Bitcoin Fog had a person in the loop. Tornado Cash does not. But the prosecution's response is that the distinction does not matter, because the relevant question is not who physically processed the transaction but who built and maintained the system that processed it.
This is where the venue challenge becomes a proxy war for something much larger. If the court accepts the government's venue theory, it accepts by implication that a developer can be pulled into any jurisdiction where a user transacted. If the court rejects it, the government's ability to prosecute decentralized protocol developers collapses, because there is no other theory of jurisdiction that works when the defendant is not physically present and the conduct is not geographically located.
Judge Failla has signaled skepticism about the prosecution's theory. In the most recent hearing, she questioned whether the government's logic would not, by extension, expose every developer of every decentralized protocol to criminal conspiracy liability for the actions of anonymous users. The prosecutor's answer — that liability attaches when the developer knows the protocol is being used for crime and continues to maintain it — is a standard that sounds reasonable until you try to apply it.
Knowledge is not a binary. It is a distribution. Every developer of every general-purpose tool knows, in the abstract, that the tool will be used by someone, somewhere, for something illegal. A knife manufacturer knows that knives are used in murders. A cryptography library maintainer knows that the library will be used by criminals. If 'knowledge plus continued maintenance' equals criminal conspiracy, then the entire software industry is a criminal enterprise, and the only reason it is not prosecuted as one is prosecutorial discretion.
Discretion is not a legal standard. It is a vibe. And vibes do not scale.
The Administrative Retreat and Its Limits
Now set the prosecution aside and look at what the Treasury did, because the contrast is where the real story lives.
On October 6, 2026, FinCEN withdrew its proposed rule on mixer reporting. The rule would have required financial institutions to identify and report customers who used mixing services, effectively creating a surveillance layer around any transaction that touched a privacy tool. FinCEN's withdrawal notice contained a sentence that the privacy community has been quoting ever since: the agency acknowledged the importance of 'legitimate financial privacy.'
Read that sentence twice. A U.S. financial regulator, in 2026, in a formal notice, conceded that financial privacy can be legitimate. That is a remarkable concession. It is also, in the context of the Tornado Cash prosecution, almost meaningless.
Here is why. FinCEN's withdrawal is an administrative action. It removes a reporting obligation. It does not decriminalize anything. It does not bind the Department of Justice. It does not create a safe harbor for developers. It does not even create a safe harbor for users, because the underlying money laundering statutes remain fully in force. The withdrawal notice itself is careful to state that administrative policy does not determine criminal liability, which is a polite way of saying: we have decided not to surveil you, but we have not decided not to prosecute you.
The privacy community read the FinCEN withdrawal as a victory. It is not a victory. It is a de-escalation on one front in a war that is being fought on three. Trust is the vulnerability they never patched — and the community's trust in a withdrawal notice that explicitly disclaims criminal relevance is precisely the kind of unpatched assumption that gets exploited.
The more interesting question is why FinCEN withdrew the rule at all. The notice cites concerns about the rule's scope and its potential chilling effect on legitimate activity. But there is a deeper reason, one that the notice does not state and that I have heard discussed in compliance circles: the rule was unenforceable in practice. Mixer usage migrates offshore the moment domestic institutions are required to report it. The reporting requirement would have imposed enormous compliance costs on regulated institutions while driving the activity it sought to monitor into unregulated venues. It was a surveillance mandate that would have produced paperwork instead of intelligence.
This is a pattern I have documented before, and it is worth naming: regulatory actions that cannot be enforced technically are abandoned administratively, but the criminal theories they were meant to support are not abandoned at all. The rule dies. The prosecution lives. The government loses the ability to surveil the activity and keeps the ability to punish the people who built the tool.
The Galeotti Standard and the Search for a Safe Harbor
In the middle of this contradiction sits a document that has received far less attention than it deserves: a policy position associated with the Deputy Attorney General's office, sometimes referenced as the Galeotti standard, which attempts to define when a decentralized software project falls outside the scope of money transmission regulation.
The standard, as I understand it, requires that a project be genuinely decentralized, that it operate peer-to-peer without custody, and that no party retain control over user funds. Projects meeting this standard would be treated as software rather than as financial services, and their developers would not be subject to money transmission licensing requirements.
On paper, this is exactly what the industry has been asking for. In practice, it is a trap with three teeth.
First, the standard is administrative guidance, not law. It can be withdrawn, reinterpreted, or ignored by a prosecutor who prefers a different theory. Administrative guidance is a policy preference dressed in legal language. It has no binding force on a criminal case, and the DOJ has already demonstrated, in the Tornado Cash prosecution, that it will pursue theories broader than the guidance contemplates.
Second, the standard does not apply retroactively. Even if Tornado Cash met the criteria for decentralization — and the prosecution disputes that it does — the standard offers no protection to conduct that occurred before it was articulated. The government's position is that the standard governs future conduct, not past prosecutions. This is a reasonable position in the abstract and a devastating one in practice, because it means the first projects to test the boundary are the ones that get destroyed defining it.
Third, and most importantly, the standard requires proof of decentralization, and the government controls the burden of proof. A developer who claims to be decentralized must demonstrate it — through governance records, token distribution, operational control, and the absence of any party with the ability to intervene. Every one of those demonstrations is a document that can be subpoenaed, and every document can be read against the developer. The TORN token, which the defense cites as evidence of community ownership, is the same token the prosecution cites as evidence of ongoing control and profit.
This is the semantic trap at the center of the case. Decentralization is not a technical state. It is a legal conclusion, and the government gets to draw it. A protocol can be architecturally decentralized and legally centralized at the same time, because the legal question is not how the code runs but who benefits from it running. If a small group of developers holds the governance token, operates the front-end, and profits from usage, then from the government's perspective, the architecture is a costume.
What the Bulls Got Right
I have spent most of this analysis dismantling the comfortable narratives. It is time to be fair to the uncomfortable ones, because the bulls on privacy have a point that the enforcement crowd keeps missing.
Here it is: privacy is not a feature of finance. It is a precondition for it. Every legitimate financial system in history has required some mechanism for keeping transactions confidential. Businesses do not publish their payroll. Individuals do not broadcast their savings. Institutional investors do not disclose their positions in real time, because doing so would allow front-running and manipulation. The absence of privacy is not transparency. It is a market structure that transfers value from the informed to the observed.
FinCEN's acknowledgment of 'legitimate financial privacy' is not a throwaway line. It is the regulator conceding, in writing, that the thing Tornado Cash was built to provide is a legitimate need. That concession matters, because it undercuts the strongest version of the government's case — the version in which privacy tools are inherently illegitimate and their developers are inherently criminals. If privacy is legitimate, then privacy tools serve a legitimate function, and the criminality, if any, lies in how they are used rather than in their existence.
The bulls also get something right about the technology. Tornado Cash's zk-SNARK architecture was a genuine advance. It proved that on-chain privacy could be achieved without a trusted custodian, that cryptographic proofs could replace institutional trust. That advance is not erased by the prosecution. It is inherited by every privacy project that follows, including the ones now building compliance layers into their designs precisely because Tornado Cash showed them what happens without them.
And the bulls get one more thing right, though it is the most uncomfortable of the three: the government's theory, if it succeeds, will not stop at mixers. It will apply to any protocol that anonymizes, obfuscates, or obscures financial activity. That includes privacy coins, privacy layers, zero-knowledge rollups with shielded transactions, and eventually any tool that lets users transact without revealing their identity. The Tornado Cash prosecution is not the end of the enforcement arc. It is the first case in a series, and the series has a logic that the government has not yet had to defend because it has not yet had to apply it to a sympathetic defendant.
The Compliance Layer Nobody Is Building
Here is the insight that I think the industry is missing, and it comes from my work auditing AI-agent smart contracts over the past year.
When I audited the first wave of autonomous trading agents interacting with DeFi protocols, I found that prompt-injection vulnerabilities could trick an agent into signing a malicious transaction, bypassing every traditional security check. The fix was not to make the agent smarter. The fix was to build a verification layer between the agent's intent and the transaction's execution — a semantic check that validated not just what the transaction did but whether it matched what the agent was supposed to be doing.
The same architecture applies to privacy protocols, and almost nobody is building it. The lesson of Tornado Cash is not that privacy is impossible. It is that privacy without an embedded compliance layer is a legal time bomb. The projects that survive the next enforcement cycle will be the ones that build the compliance layer into the protocol itself — whitelists at the deposit stage, sanctions screening at the relayer level, cryptographic attestations that a withdrawal is not connected to a sanctioned address.
This is technically hard, and it is philosophically uncomfortable. A privacy protocol with a compliance layer is less private than one without. But the alternative is not a pure privacy protocol. The alternative is no protocol at all, because the pure version gets prosecuted out of existence and the developers go to prison. Precision kills the illusion of complexity — and the illusion here is that privacy and compliance are opposites. They are not. They are two constraints on the same optimization problem, and the projects that treat them as a single problem will outlive the ones that treat them as a war.
The new generation of compliant privacy protocols understands this. They embed AML checks, they screen against sanctions lists, they maintain the ability to refuse deposits from flagged addresses. They are less ideologically pure than Tornado Cash and more likely to exist in five years. That is not a moral judgment. It is an engineering one.
The DAO as Compliance Shield
There is a final layer to this case that I want to name directly, because it is the part that the industry prefers not to discuss.
When projects preach decentralization, they point to their DAO — the decentralized autonomous organization that supposedly governs the protocol through token-holder votes. The DAO is presented as evidence that no single party controls the system. It is, in practice, frequently a compliance shield: a structure that diffuses nominal authority while concentrating actual control in the hands of the founding team and its early investors.
I have traced team wallets and foundation holdings across dozens of projects, and the pattern is remarkably consistent. The DAO votes on proposals that the core team drafts. The token distribution concentrates voting power in the hands of insiders. The foundation holds a treasury that the team controls. The 'community' is a legal fiction that provides deniability while the actual decisions are made by the same five people who made them before the token existed.
In the Tornado Cash case, this pattern is not just an embarrassment. It is evidence. The prosecution's argument that Storm retained control and profited from the protocol rests partly on the governance structure — the token, the treasury, the ongoing operation. If the DAO were genuinely decentralized, that argument would fail. Because it was not, the argument succeeds. Every exploit is a confession written in gas fees, and every governance token is a confession written in distribution tables.
The industry's response to this has been to double down on the fiction. Projects are now designing governance structures that look more decentralized on paper while preserving insider control in practice. This is the opposite of what the Tornado Cash case should teach. The lesson is not 'make your DAO look more decentralized.' The lesson is 'if your DAO is a shield, the prosecution will see through it, and the shield will become the evidence.'
Where This Ends
The venue challenge will be decided in the coming months. If Judge Failla accepts the government's theory, the DOJ gains the ability to prosecute protocol developers in any district where any user has transacted, which is to say, everywhere. If she rejects it, the prosecution's case against Storm collapses on jurisdictional grounds, and the government is forced to either legislate or concede that it cannot reach decentralized software through the criminal code.
Either outcome is a precedent, and both precedents are dangerous in different ways. A government win establishes that code is conduct and developers are operators. A government loss establishes that the criminal code has a hole in it that Congress has not filled, and the next Congress may fill it with something worse than the prosecution.
What the industry should be doing, and mostly is not, is preparing for both outcomes by building the compliance layer that makes the question moot. A privacy protocol that can demonstrate, cryptographically, that it does not facilitate sanctions evasion is a protocol that no prosecutor can easily indict. That protocol is harder to build than Tornado Cash. It is also the only version that survives.
Silence in the logs speaks louder than the code. The Tornado Cash logs are silent on compliance because the protocol was never designed to speak. The next generation of privacy tools will have to say something, and what they say will determine whether they exist at all.
The two governments — the Treasury that retreated and the DOJ that advanced — will eventually reconcile. They always do. The question is which one the reconciliation favors, and whether the developers who built the tools in the meantime are still free to build the next ones.
Audit the policy, not the promises. The promises said privacy. The policy said jurisdiction. Only one of them gets enforced.
A Note on Method
I want to close with something about how I reached these conclusions, because the method matters as much as the finding.
This analysis is built on court filings, the FinCEN withdrawal notice, the Sterlingov appellate record, and my own experience auditing privacy-adjacent protocols and AI-agent interfaces. Where I have inferred, I have marked it. Where the record is silent, I have said so. The Tornado Cash case has generated more heat than light, and most of the commentary falls into one of two camps: privacy absolutists who treat any regulation as tyranny, and enforcement maximalists who treat any privacy tool as a money laundering machine. Both camps are wrong in the same way. They are arguing about values when the case is about jurisdiction.
The values question — should privacy exist, should developers be liable, should the state be able to surveil — is important and will be settled politically. The jurisdiction question is being settled now, in a courtroom, on a motion, by a judge who is skeptical of the government's theory and bound by precedents that were written before decentralized software existed.
That is the asymmetry. The politics moves slowly. The law moves in increments. And the increment being decided this year will determine what kind of software can be built for the next decade.
I have watched this pattern before. In 2017, I audited the 0x Protocol v2 contracts and found an integer overflow in the fillOrder function that allowed attackers to manipulate exchange rates. I submitted the report, collected the bounty, and watched the patch go in before mainnet. The lesson was not that the code was bad. The lesson was that the code was auditable, and that auditing it before deployment was cheaper than auditing it after a breach. The Tornado Cash case is the same lesson at the level of policy. The compliance layer that nobody wants to build is the patch that nobody wants to apply. The difference is that when a smart contract fails, you lose funds. When a legal theory fails, you lose the ability to build anything at all.
Build the layer. Patch the assumption. Verify everything, and trust the code only after you have read it. That is the discipline the industry needs, and it is the discipline the industry keeps refusing to adopt.
The logs are open. Read them.