DeFi after Tornado Cash: the new line on dev liability

The partial verdict that redrew the map

On August 6, 2025, a Manhattan federal jury returned a partial verdict in the Tornado Cash case against developer Roman Storm. Jurors convicted him of conspiracy to operate an unlicensed money transmitting business and deadlocked on money laundering and sanctions counts. The government’s core story was that Storm helped run a service that accepted and transmitted value for the public while knowing it was used to move criminal proceeds. As summarized in the SDNY press release on the Storm verdict, the conduct that persuaded the jury included paying for infrastructure and profiting from fees, which prosecutors framed as operation of a transmitting business, not just code publishing.

This is not a blanket criminalization of privacy tech. It is a fact-specific finding that certain actions around a non-custodial protocol can add up to running an unlicensed money transmitting business. For builders, the question is no longer whether you take custody. It is whether your role looks like running a service that takes value from person A and causes it to reach person B as a business.

For the broader U.S. policy context shaping crypto design choices, see our explainers on Treasury’s GENIUS Act rulemaking playbook and the SEC’s generic rules that reset crypto ETFs.

What “money transmission” now signals to devs

U.S. law does not make money transmission hinge on keys alone. The federal crime for unlicensed money transmission often tracks whether someone accepts and transmits funds to the public as a business, fails to register as a money services business, or violates state money transmitter laws. In practice, prosecutors will build a narrative from functional facts:

You arranged or paid for critical infrastructure that moves value for users.
You set or shared in fees tied to that movement of value.
You or your team ran key operational components that determined whether, when, or how value moved.
You continued operating after learning the service was moving criminal proceeds.

Bottom line: non-custodial architecture is not immunity if the government can show an operational role, profit sharing, and knowledge of illicit use. The custodial line still matters, but it was not sufficient.

Where non-custodial builders face friction

Below are the areas most likely to draw the “you operated a transmitting business” theory and the specific actions that can trigger it.

Mixers and privacy pools

Running coordinators, sequencers, or relayers that accept user deposits or withdrawals on their way to miners or validators can look like accepting and transmitting value.
Charging a service fee that scales with throughput looks like running a business. End-to-end fee sharing across teams or front-ends adds weight.
Actively marketing anonymity while ignoring or minimizing known abuse can be framed as willful blindness.
A single operator that can pause, censor, or reorder flows suggests practical control even if user keys never leave the wallet.

Smart wallets, paymasters, and ERC-4337 relays

Paymasters and bundlers that front gas and get reimbursed by users are accepting value and transmitting on behalf of the public. If you control those components, take fees, and operate at scale, you are closer to the line.
Account recovery services that take inbound funds, pool them, and later disburse can look like transmission if not tightly designed.
Deployer teams that run the default relayer, set policies, and collect protocol fees occupy the operational center of gravity, which prosecutors can characterize as the business.

Cross-chain bridges and messaging relays

If a small group runs the lock-and-mint or burn-and-release machinery, decides liveness, and collects a fee on flow, the narrative looks like acceptance and transmission.
Where bridge operators can block or expedite transfers, even without key custody of end-user wallets, they still control value in flight.

DAO front-ends and interface operators

Front-ends that gate access, enforce allowlists or denylists, route transactions through affiliated relayers, and skim fees are not just publishing a website. They are operating an entry point to a transmitting service.
If the same team publishes the contracts, runs the relayer, controls the domain, and collects the fees, the non-custodial label will not shield them from an operational theory.

Where the custodial divide failed to protect

The Storm case shows that custody is only one factor. The government highlighted a pattern: funding and steering critical infrastructure, controlling defaults, collecting fees tied to flow, and continuing operations after notice of criminal use. Those facts allowed prosecutors to argue that Storm and colleagues ran a transmitting business in substance, even if users retained keys.

Key takeaways:

Control beats labels. If your team can materially change whether and how user value moves, expect scrutiny.
Fees equal business. If your revenue rises with the movement of value, regulators will say you are in the transmission business.
Notice matters. Once public attribution connects your service to criminal proceeds, staying the course without countermeasures looks willful.

How teams are adapting in the open

Most teams are not going back to custodial. They are engineering constraints and buffers around their role. This design shift mirrors the broader policy retooling we track in America’s stablecoin shockwave.

Front-end controls. Rate limits, withdrawal delays for suspicious flows, and on-device screening reduce abuse without harvesting PII.
Geo-fencing and jurisdiction-aware modes. Some projects lock out traffic from higher-risk regions or offer a constrained U.S. path that disables features tied most closely to transmission risk.
Compliance modules that preserve privacy. Sanctions and crime-screening oracles, proof-of-innocence circuits, and zero-knowledge attestations that funds are not linked to known exploits. These avoid broadcasting addresses while creating a verifiable exclusion of known-bad flows.
Client and operator diversity. Multiple independent relayers, paymasters, bridge validators, and front-ends with distinct governance reduce the appearance of a unitary business.
Clear operator separation. If your entity runs a relayer, segregate it from protocol governance and fee flows. Publish operator policies. Make them revocable and replaceable by users.
Audits and attestations. Security and compliance audits focused on no unilateral control, no pooled custody, and no privileged routing. Public attestations that operators cannot redirect user value.
Immutable or timelocked controls. If pausing or censoring is critical for safety, wrap it in a timelock or a multi-operator process. One-person switches look like control of funds.
Minimizing protocol-owned infrastructure. Use open mempool paths or decentralized networks rather than team-run relays where possible. If you must run infra, make it one of many and not the default.

Sanctions pushback matters, but it is not a shield

There has been judicial skepticism about applying traditional sanctions law to autonomous code. In late 2024, the Fifth Circuit held that immutable smart contracts are not property under the relevant statute, undercutting one legal basis for sanctioning the Tornado Cash contracts themselves. That opinion narrowed how far sanctions can reach into autonomous software, even as it left other theories intact. Courts may distinguish between sanctioning a codebase and sanctioning a person who operates a business around it, as in the Fifth Circuit opinion in Van Loon.

For builders, this backdrop is helpful but narrow. It can constrain list-based sanctions on immutable contracts, yet it does not resolve whether your role looks like operating a transmitting business. The Storm verdict shows prosecutors will pursue the latter theory if facts line up.

What happens next: retrial and appeal timelines

The partial verdict sets up multiple tracks:

Retrial decision. After a hung jury, prosecutors must decide whether to retry the unresolved laundering and sanctions counts. Courts often set a status conference within weeks to lock a plan. The Speedy Trial clock typically restarts after a mistrial, though complex-case exclusions and scheduling realities can push any retrial several months out.
Sentencing on the transmission count. Sentencing usually follows pre-sentence investigation and briefing. That can take three to six months. The judge will consider advisory guidelines, but the statutory maximum for the convicted count caps exposure.
Post-trial motions. Defense can renew motions for acquittal or seek a new trial on the transmission count within set deadlines. Those motions can adjust the schedule.
Appeal posture. A direct appeal normally follows final judgment and sentencing. If the government retries and wins on a hung count, timelines extend. If it does not retry, Storm can appeal the lone conviction after sentencing. Appeals in complex white-collar cases often take nine to eighteen months.

Expect the DOJ’s decision on retrial to hinge on resource calculus and whether the record on the hung counts looks meaningfully stronger following the first trial. Until then, the unlicensed transmission conviction is the live signal to the market.

A practical liability map by role

Here is how builders in common DeFi categories can recalibrate without neutering privacy.

Mixers and privacy pools

Separate roles. Distribute coordinator and relayer roles to independent operators with transparent onboarding and offboarding. Do not bundle code publishing, infra operation, and fee collection in one entity.
Rethink fee mechanics. Consider flat subscription-style pricing, not per-transfer fees that scale with value moved. Do not directly share in relayer throughput fees.
Publish an abuse response plan. Commit to routine list updates that exclude known exploit flows through privacy-preserving checks. Document the triggers and the process.
Reduce operator discretion. Move to proofs and rules embedded in contracts so individual operators cannot pick winners and losers.

Smart wallets, paymasters, bundlers

Cap the surface area. If you must run a paymaster, avoid custody-like flows. Use non-custodial payment channels where user funds do not sit in an operator pool.
Make the default non-operator path obvious. Ship clients that connect to multiple third-party bundlers by default. Do not auto-select your own relay for every user.
Prove separation. Provide formal proofs or audits that operators cannot reroute or delay user value for business advantage.

Cross-chain bridges and relays

Rotate validators and relayers. Enforce operator churn and threshold signatures so no small group controls value in flight.
Derive revenue from ancillary services. Focus fees on data or insurance, not on per-transfer throughput.
Transparency on incidents. If the bridge sees an exploit, show how the governance process works and who has authority. Avoid one-team hotfixes without checks.

DAO front-ends

Minimize dependency. If your interface must rely on a relay, let users select from community-run options on first use. Disclose any fee splits clearly.
Split responsibilities. Have different entities manage domain, hosting, and interface maintenance. Document that separation.
Offer a local mode. Allow advanced users to run the interface locally with their own RPC and routing, reducing claims that you gatekeep the service.

Designing for privacy and compliance at once

Privacy does not have to be binary. Builders are weaving compliance checks into protocols without doxxing legitimate users.

Proofs of innocence. Users present a short proof that their deposit does not trace back to known exploits, without revealing their address history.
View keys and scoped disclosures. Users can disclose specific transactions to exchanges, auditors, or law enforcement without opening their entire wallet state.
Risk filters at the edge. On-device screening against compact bloom filters or commitment sets so the protocol never sees raw addresses.
Programmatic dispute channels. A narrow path for resolving mistakes or returning funds that does not create a standing operator custody role.

The builder checklist to minimize liability

Use this as a working doc with counsel. The goal is to reduce facts that look like you are operating a transmitting business while preserving user privacy.

Clarify the role

Are you operating infrastructure that accepts and transmits value, or only publishing code? If you operate infra, can independent parties run the same role without your permission?
Do you set or share fees tied to throughput? If yes, change the model.

Reduce operational control

Can any single person or entity pause, reorder, or censor transactions? Remove unilateral controls or put them behind multi-operator processes and timelocks.
Avoid defaulting users to an operator you control. Ship multiple operators by default and document how to switch.

Separate entities and flows

Do not combine protocol governance, relay operation, and fee collection in one entity. If unavoidable, ring-fence functions with independent boards and contracts.
Keep operator revenue separate from per-transfer fees. Prefer fixed subscriptions, grants, or donations.

Build privacy-preserving compliance

Integrate sanctions and exploit exclusion via zero-knowledge oracles. Log proofs, not addresses.
Publish an abuse mitigation playbook and update cadence. Show your work.

Document, attest, audit

Commission security and policy audits focused on control of value in flight. Publish attestations that operators cannot seize or redirect funds.
Maintain incident logs and operator policies. They will matter later.

Prepare legal hygiene

If any component arguably accepts and transmits value, consult on MSB registration, a written AML program, and SAR processes tailored to on-chain reality.
Keep counsel involved in decisions to continue or suspend operations after a major exploit touches your system.

Communication discipline

Marketing should match reality. Do not promise anonymity while glossing over known abuse channels. Avoid statements that imply you run a money movement business.

Bottom line

A jury just agreed that you can run an unlicensed money transmitting business even if you never hold user keys, if your actions make you the operator of a service that accepts and transmits value for the public. At the same time, courts have grown skeptical of sanctioning autonomous code as property, which narrows one enforcement tool without touching another. Those two truths can coexist. For DeFi builders, the path forward is to engineer away the facts that look like centralized operation, adopt privacy-preserving compliance, and keep the autonomy of your systems real rather than rhetorical. The line has moved. Your design, documentation, and incentives need to move with it.