Tornado Cash’s 2025 Pivot and the New Privacy Playbook

The moment that moved the perimeter

On March 21, 2025, the U.S. Treasury removed Tornado Cash from the sanctions list. That single update did not turn back time to 2021. It did, however, redraw the line between what code can be and what services must do. Regulators effectively said they will lean away from sanctioning autonomous, immutable smart contracts and lean harder into accountability for operators, interfaces, and people. If you touch users, custody, routing, or revenue, your obligations just became clearer. If you write open source that is truly autonomous and hands off, your obligations are narrower, but not gone. You still have to understand how your code gets used in a financial system that is under active supervision.

If there was one link that set the tone for the year, it was Treasury’s own language in the Treasury delisting announcement. The department said it was exercising discretion in light of novel legal and policy issues. Read that as a recalibration, not a retreat. The message to teams building privacy features is simple. The government will target behaviors that enable evasion and laundering, not neutral code that runs without control surfaces. That is a higher bar for prosecutors and a clearer assignment for compliance leads.

For broader context on how U.S. rulemaking is shifting the consumer perimeter, see our explainer on the GENIUS Act policy reset.

What delisting changes, and what it does not

Delisting means there is no blanket prohibition on interacting with Tornado Cash smart contract addresses as such. It does not mean the government approves of using mixers to hide stolen funds. It does not immunize operators that turn neutral code into a business with customer touch points. And it does not erase prior conduct risk for developers or companies that may have gone beyond publishing code into running or coordinating a service.

In August 2025, the criminal case against one Tornado Cash developer produced a split outcome that underscored the new perimeter. A Manhattan jury deadlocked on the most severe charges but returned a conviction for operating an unlicensed money transmitting business. Read Reuters’ coverage of the August jury verdict to see how the line between code and service became the fulcrum of the trial narrative. The signal is unmistakable. The farther you move from autonomous code toward facilitating or intermediation, the more you inherit classic financial crimes exposure.

The courtroom cues guiding 2025 design choices

Several legal cues now shape how teams should design privacy systems in the United States.

Immutability matters. Courts have shown skepticism toward treating immutable smart contracts as property that can be blocked in the same way as a bank account. If no one can alter, remove, or selectively control the contract, the theory of control looks weak.
Control surfaces are liability magnets. Any element that can pick and choose who transacts, sequence transactions, apply allowlists or blocklists, or monetize routing begins to look like a service. Services inherit licensing and AML obligations.
Intent is not a defense to function. Even benevolent aims do not excuse designs that predictably enable crime at scale. Prosecutors will ask what you knew, when you knew it, and what you changed. If your metrics tracked proceeds from known hacks while you shipped features that increased throughput, expect scrutiny.

The practical takeaway for builders is not to avoid privacy. It is to engineer privacy with selective disclosure and accountability out of the box while minimizing centralized control. For system design patterns that reduce trusted parties, track recent permissionless fault proofs progress.

The new compliance perimeter in 2025

Think of today’s perimeter as a set of concentric rings from pure code to full service.

1) Autonomous protocols

Characteristics: immutable smart contracts, no admin keys, no upgrade path, no fees routed to a controllable treasury, and no operator who can prefer one user over another.
Exposure: lower on sanctions theory tied to code, but not zero. Advertising criminal use, maintaining ancillary infrastructure that coordinates usage, or providing privileged relays reintroduces risk. Transparent documentation and a posture of neutrality matter.

2) Interfaces and relays

Characteristics: hosted front ends, RPC relays, default routing, paywalls, sequencers, or UX features that shape how users interact with onchain privacy.
Exposure: high. The moment an interface curates access, collects fees, or intermediates flows, you are operating something that looks like a financial service. Expect KYC expectations to attach, along with suspicious activity reporting triggers for U.S. persons or when you knowingly onboard users in the United States.

3) Custodial and quasi-custodial wallets

Characteristics: any wallet that can pause, reverse, or batch transactions, custody user assets, manage recovery keys, or run internal ledgers.
Exposure: very high. You sit inside the money transmission perimeter. You must have a written AML program, appoint a compliance officer, maintain customer identification and verification procedures, and file SARs when appropriate. Screening and travel rule interoperability are table stakes.

4) DeFi front ends and aggregators

Characteristics: discovery portals, execution routers, MEV protection layers, and cross-chain bridges with a consumer-facing UI.
Exposure: significant. Even if the protocol is immutable, the front end can be a regulated access point. Expect to show IP geofencing for embargoed jurisdictions, terms that prohibit illicit use, a sanctions screening process for offchain interactions, and a credible plan to respond to law enforcement requests.

5) Infrastructure providers

Characteristics: oracles, indexers, data availability services, and proofs-as-a-service companies.
Exposure: moderate to high depending on whether you influence transaction ordering, provide private channels, or sell preferential access. If you can change outcomes for specific users, your risk looks more like an operator than a neutral utility.

Privacy by design is not optional anymore

The privacy conversation is shifting from whether you have privacy to how you prove compliance without sacrificing it. The path forward features three design pillars.

1) Selective disclosure primitives

View keys for recipients and regulated third parties. Users can generate one-time proofs that reveal sources to a bank, auditor, or law enforcement without de-anonymizing them to the world.
Proofs of innocence. Let users attach a zero knowledge proof that their funds are not linked to known illicit clusters beyond a probability threshold. The proof travels with the transaction where it matters.
Programmable privacy scopes. Users can opt into narrower reveal windows for high-risk venues, such as centralized exchanges or fiat on-ramps, while remaining private for everyday peer-to-peer transfers.

2) Compliance modes that flip on only where needed

Contextual toggles. A wallet can detect when a user is about to interact with a regulated counterparty and prompt a one-time disclosure rather than collecting identity information for all activity.
Data minimization. Collect only what is necessary for the specific transaction, retain it for the shortest time allowed, and use client-side encryption with user-held keys where possible.
Policy registries. Maintain an open registry of what proofs each venue will accept. Reduce the burden on users to guess which disclosure is required.

3) Operator-light architectures

Remove the power to discriminate. If your system can be coerced into silence for some users and not others, you will be treated like a service. Favor designs that eliminate human-in-the-loop decisions.
Stateless coordination. If you must coordinate flows, do it with publicly verifiable algorithms and time-limited commitments that do not create an account relationship.
Fee neutrality. Avoid fee switches or revenue routes that require an operator to decide who pays what. If revenue accrues, push it to a burn or to a DAO structure that cannot direct privileges to specific users.

A practical playbook before the next enforcement wave

Below is a field-tested plan product teams can execute over the next 90 days.

1) Map your control surfaces

List every place where a human or a company can prefer one user over another. Include DNS, hosting, analytics, relays, RPC default endpoints, API keys, allowlists and blocklists, and any hidden environment variables.
For each surface, decide to remove, automate, or wrap with an auditable process. If it is essential, layer role-based access control and dual control for changes.

2) Assign a compliance design owner

Name a single person who owns privacy-preserving compliance. Their charter is not to collect data. It is to eliminate unnecessary collection and to implement selective disclosure where required.
Stand up a cross-functional tiger team that includes a protocol engineer, front-end lead, ops, and counsel. Make the team responsible for a written plan your board can review.

3) Write a sanctions and AML memo for your product

Even if you are not a financial institution, draft a memo that explains your risk-based approach. Describe what you screen, what you do not, what triggers escalation, how you would respond to a lawful request, and who is responsible for decisions.
Include a model law enforcement request process. Define how requests are verified, what timeline you commit to, and how you protect other users’ privacy while complying.

4) Add selective disclosure to your roadmap

Choose one transaction type, such as an exit to a centralized exchange, and implement a proof-of-innocence flow. Instrument how often it is used, how many disclosures are generated, and how it impacts user experience.
Publish a short technical explainer for users. Explain what is revealed, to whom, and for how long. Promises without detail will not build trust.

5) Separate code from service

If you run a front end, clearly state its relationship to the underlying contracts. Document what the UI can do that the contracts cannot, and vice versa. If the UI is shut down, can users still interact directly with the contracts without differential outcomes? If not, you look like an operator.
Avoid privileged relays. If you must run one, treat it like a regulated access point with appropriate screening and user notices.

6) Prepare for the unlicensed money transmission test

Write down whether your product receives and transmits value for the public. If yes, and if you exercise control over those transmissions, assume licensing risk. Begin a gap analysis for money transmitter obligations in the states where you have users or operations, and consider whether you can refactor to reduce custody and control.

7) Build an incident response and disclosure program

When a hack routes through your tool, your public response is as important as your private remediation. Have pre-approved language that acknowledges abuse while underscoring the steps you take to deter it.
Identify escalation thresholds that trigger additional monitoring or rate limiting for specific patterns, without singling out individuals.

8) Audit your documentation and marketing

Remove copy that celebrates anonymity for its own sake. Replace it with precise claims about privacy for legitimate users and the mechanisms you provide for lawful selective disclosure.
Keep a change log of compliance-relevant updates so you can show a consistent good-faith posture over time.

The wallet, mixer, and DeFi front end checklist

Wallets
- Implement context-aware compliance mode. Only prompt for proofs when the counterparty requires it.
- Add view key exports tied to specific transactions, with user-held encryption.
- Show provenance risk scoring in the UI without sending data off-device by default.
Mixers and privacy pools
- Publish a policy on proofs of innocence and make it easy for users to attach them when exiting to high-risk venues.
- If you run any relays or coordinators, treat them like financial services with screening and reporting playbooks.
- Avoid admin keys. If you must have them, lock them behind time delays and transparent multisigs with public alerting.
DeFi front ends
- Geofence embargoed jurisdictions where feasible, and explain your rationale plainly.
- Maintain a sanctions response plan for offchain services you control such as DNS or hosting. Practice a fail-open strategy for the onchain path when legally permissible and safe.
- Keep your allowlist and blocklist change logs public. Mystery lists look like arbitrary decisions and increase regulatory suspicion.

What to watch next

Enforcement posture toward interfaces. Expect more cases that test how far a hosted UI can go before it becomes an unlicensed money transmitter. The 2025 jury outcome suggests this is now the primary risk area for privacy projects with front ends.
FinCEN transparency rules. Proposals aimed at international virtual currency mixing remain on the table. Translate that as increased reporting expectations for U.S. financial institutions when they see mixing patterns, and potential second-order pressure on interfaces that serve those users.
Standards for selective disclosure. Banks and exchanges will converge on a small set of proof formats they trust. Join those discussions early and publish a compatibility roadmap so users are not confused by one-off implementations. For adjacent market structure changes that may pull new users into DeFi, review the SEC generic ETF standards.

The bottom line

The policy and courtroom signals of 2025 did not kill onchain privacy. They placed it on a track where privacy must ship with accountability. Autonomous, immutable code is less likely to be sanctioned as property. Interfaces, relays, and operators that can pick winners and losers are squarely in scope for licensing and AML obligations. The future belongs to teams that combine user-controlled privacy with targeted, auditable disclosure. Build that now, and you will be ready before the next enforcement action or rulemaking lands.