OFAC, Stablecoins, and Tornado Cash: What Actually Got Banned?

What OFAC actually did to Tornado Cash in 2022

OFAC is the Office of Foreign Assets Control, a division of the US Treasury that administers economic sanctions programs. When OFAC adds an entity to its Specially Designated Nationals (SDN) list, US persons are forbidden from transacting with it, and any property in US jurisdiction is supposed to be blocked.

On August 8, 2022, OFAC added Tornado Cash to the SDN list. The official press release cited the protocol's role in laundering more than $455 million stolen by the Lazarus Group, a North Korean state hacker unit, including the proceeds of the March 2022 Ronin Bridge hack. Tornado Cash had also been used to launder funds from earlier exploits and to obfuscate the origin of ether stolen in non-fungible token (NFT) heists.

The unusual step was the choice of target. OFAC did not add the developers by name. It sanctioned the on-chain smart-contract addresses themselves: the deposit contract on Ethereum, the verifier contract, the governance contract, the proxy contract, and a few helper pools. In sanction law this was novel, because the SDN list had previously been used to designate persons, businesses, vessels, and aircraft, not self-executing code on a public chain.

Two things followed immediately. Circle, the issuer of USDC, a dollar-pegged stablecoin, added the Tornado Cash pool addresses to its internal blacklist and froze roughly $75,000 in USDC that had been sitting in those contracts. The domain tornado.cash was taken offline by the hosting provider under US-person guidance, and the GitHub organization belonging to one of the developers was suspended. A Dutch developer, Alexey Pertsev, was arrested in the Netherlands the following week; his case is still winding through European courts on money-laundering charges separate from the US designation.

Why this became a legal fight, not just a technical one

Sanctioning code raised an obvious question: what about the thousands of users who had deposited funds into Tornado Cash before the designation, only to find their withdrawals blocked or their funds trapped? Coinbase, Kraken, and others stood to absorb compliance risk if they processed those withdrawals. A group of users sued, backed by Coinbase's funding arm and the crypto advocacy group Coin Center.

The plaintiffs argued, in essence, that a smart contract is a tool, not a sanctioned party. Allowing the Treasury to blacklist autonomous code, they warned, would let OFAC effectively sanction any open-source software that touches illicit funds. The case, Van Loon v. Department of the Treasury, ran through a federal district court in Texas and reached the Fifth Circuit Court of Appeals.

In November 2023 the district court ruled that OFAC had overstepped, holding that an immutable smart contract is not property of a foreign national in the ordinary sense. OFAC appealed, and in November 2024 the Fifth Circuit affirmed that the immutable Tornado Cash contracts could not be blocked as 'property' under the International Emergency Economic Powers Act (IEEPA), the statute OFAC used. The court was careful, though, to say that this ruling did not bless the protocol or its users. It simply narrowed one legal theory.

What the 2024 ruling and 2025 guidance actually changed

In response to the Fifth Circuit decision, OFAC removed the original Tornado Cash smart-contract addresses from the SDN list in March 2025. But 'not on the SDN list' is not the same thing as 'clean.' Ofac keeps running list updates and continues to flag addresses associated with the Lazarus Group, the Russian sanctions-evasion services, and a long tail of cyber-crime entities. Tornado Cash itself remains under scrutiny in other jurisdictions, particularly in the European Union through its own sanctions framework.

In parallel, OFAC refreshed its compliance guidance for the digital-asset sector. The 2025 update, an extension of the 2021 guidance on virtual currency compliance, leaned heavily on blockchain analytics. Treasury now expects covered entities to use 'commercially reasonable' analytics tools to trace and identify counterparties, document the source of funds for high-risk flows, and reject transactions when an analytics confidence score exceeds internal thresholds. The exact thresholds are not published, which is itself a feature from OFAC's perspective; firms are expected to calibrate their own risk models and then defend those models during examinations.

The 2025 guidance is the practical bridge between the Tornado Cash precedent and the daily work of a stablecoin-using protocol. Before 2022, many compliance teams treated blockchain addresses as opaque strings. After 2022, those addresses became first-class risk vectors: each one needs a judgment about who owns it, where the funds came from, and whether a relationship is permitted at all.

The front-end vs protocol split, in plain language

Tornado Cash has two distinct components, and US sanction law treats them differently. The protocol is the set of smart contracts deployed to Ethereum mainnet. Anyone can deploy a copy of the code on a different chain, or fork the GitHub repository, or call the original contracts directly through a node. The front-end was the website, tornado.cash, which simplified the deposit and withdraw flow into a one-click interface.

After the 2022 designation, OFAC made clear that operating a front-end that helped US persons interact with the sanctioned contracts was itself a sanctionable service. That is why the original .cash domain was seized, why community-run mirrors were taken down, and why a US-domiciled developer offering a hosted UI would face enforcement risk. By contrast, the Fifth Circuit held that writing and publishing the underlying code, including on GitHub, is protected speech under the First Amendment in that specific ruling. Note this is a US-specific constitutional argument and does not automatically translate to other legal systems.

The practical implication, two and a half years later, is the workhorse distinction compliance teams use every day. Code is rarely the legal risk in 2026. Distribution is. Operating, hosting, or marketing a service that helps users route funds through sanctioned addresses, even an 'educational' front-end, is where OFAC has been willing to act.

How Circle, Tether, and DAI actually freeze funds

Stablecoins come in two compliance flavors. The first is centralized, and this is the dominant one: USDC from Circle, USDT from Tether, and most exchange-issued tokens. These tokens have an admin role inside the contract that can hold or transfer individual addresses in a blacklist. When Circle blacklists an address, no USDC at that address can move, and the contract will reject any inbound transfer. Frozen USDC sits there indefinitely; in theory, only a court order or a Circle-internal process can thaw it.

The mechanics matter. Stablecoin freeze lists are public on-chain events. Anyone who runs an Ethereum node can read the contract's blacklist storage slot, and compliance teams do. Because freezes happen at the smart-contract level, they are tamper-resistant: even if a centralized exchange wanted to keep serving a blacklisted user, it could not, because the USDC itself would refuse to leave the user's wallet.

USDT, issued by Tether, uses the same model. Tether has frozen hundreds of millions of dollars in USDT tied to hacks and sanctions, sometimes without public announcement. Critics argue Tether is less transparent than Circle about which addresses are blocked and why, which makes USDT harder to use in compliance-sensitive contexts.

DAI, run by the MakerDAO protocol, takes a different path. DAI is overcollateralized crypto-backed stablecoin issued through Maker vaults, and its freeze mechanism is community-governed through MKR token voting rather than a centralized admin key. In practice, Maker has co-operated with US law enforcement through 'emergency oracle' shutdowns of specific vaults, and individual DAI holders can end up sanctioned if their counterparties are. DAI's compliance posture is governance-dependent, which is a feature for decentralization advocates and a risk for regulated institutions.

How exchanges and protocols screen stablecoin flows

Compliance work happens at the edge of a stablecoin network, not inside it. When a user deposits USDC into a centralized exchange, the deposit address goes through a screening pipeline that runs in milliseconds. Typical steps:

• Address screening. The deposit address is checked against commercial denylists (Chainalysis, TRM Labs, Elliptic, Merkle Science) and proprietary risk scores. A clean address passes; a high-risk address triggers manual review.
• Source-of-funds tracing. For higher-value or higher-risk deposits, the exchange backtracks the funds two to ten hops, flagging any indirect exposure to mixers, sanctions clusters, or known exploit proceeds.
• Destination screening. On withdrawal, the recipient address is checked the same way. Some exchanges refuse withdrawals to addresses that received funds from a sanctioned source within a recent window, even after several hops.
• Travel rule data. Transfers above roughly $3,000 to $1,000, depending on jurisdiction, must carry originator and beneficiary information. In crypto this is implemented through third-party protocols, because the on-chain USDC transfer itself carries no identity.
• Periodic re-screening. An address that was clean at deposit can become risky later, when the underlying owner is sanctioned. Exchanges re-run screening continuously and freeze accounts after the fact.

For decentralized protocols, the picture is murkier. A lending market like Aave or Compound, both widely used DeFi protocols for borrowing and lending, cannot easily block sanctioned addresses without a governance vote, and even then only specific functions (front-end hosting, oracle feeds, interface listings) are addressable. The smart contracts themselves do not know who you are. This is why the regulatory focus has stayed on the front-end layer: it is the one with identifiable operators.

What US sanction exposure looks like for a USDC-using protocol in 2026

Suppose a US-domiciled team runs a protocol that accepts USDC deposits, holds reserves in a multisignature wallet, and pays out yield to non-US users. Each piece of the stack has its own OFAC risk profile.

The wallet layer: a multisig held by US persons is the easiest target for enforcement. Treasury can require those signers not to approve transactions to sanctioned addresses, and the analytics tools to detect those attempts are mature. The de facto expectation is that any multisig with US signers runs a screening step before signing.

The application layer: the front-end must refuse to generate deposit addresses or initiate withdrawal flows that touch flagged clusters. Most regulated teams now require users to pass sanctions screening at sign-up and re-screen periodically.

The treasury layer: the protocol's own stablecoin reserves are a sleeper risk. If the protocol ever receives USDC from a sanctioned source, Circle will freeze those funds on arrival. That is, the protocol loses the capital without anyone at the protocol having done anything wrong. The usual workaround is to monitor inbound transfers in real time, return any tainted funds manually, and keep a legal reserve to absorb the rare write-off.

The team layer: in 2026, OFAC's expectations extend to the people side. Founders, employees, and significant token holders can themselves become sanctioned parties, so basic diligence includes background checks, sanctions screening of contributors, and ongoing monitoring of investor wallets.

Read OFAC's stablecoin enforcement critically

Stablecoin sanctions enforcement moves quickly and so does the news around it. Tracking which addresses are sanctioned, which protocols are under investigation, and which enforcement actions are settled is a full-time job. Zippfeed surfaces regulation headlines, including OFAC updates, Tornado Cash follow-ups, stablecoin freezes, and DAO governance calls, with sentiment scoring (bullish, neutral, or bearish) and an importance rating, so you can separate signal from noise and act before your protocol or your portfolio is the next headline.

FAQ

Is Tornado Cash still banned?

The Tornado Cash smart-contract addresses were removed from OFAC's SDN list in March 2025 after the Fifth Circuit ruled they could not be sanctioned as property under IEEPA. The protocol itself is not actively sanctioned at the contract level today, although OFAC continues to flag associated addresses, several European regulators treat it as a sanctioned entity, and developer Alexey Pertsev remains under prosecution in the Netherlands.

Can Circle freeze my USDC for any reason?

Circle can freeze USDC at any address that ends up on its blacklist, typically when that address is tied to a sanctions designation, a known exploit, or a court order. Frozen USDC stays at the address; it is not destroyed or burned, and a thaw is theoretically possible but rare. In practice, the most common reason a retail user is frozen is indirect exposure: the user received USDC from a wallet that itself received funds from a sanctioned source.

Do I need to screen stablecoin addresses in my dApp?

If your dApp has any US-person touchpoints, including US-based team members, US-hosted front-ends, or US-jurisdiction users, the conservative answer is yes. Screening at the front-end is the practical enforcement boundary OFAC has used, and it is much cheaper to install than to litigate later. Decentralized-protocol-only projects with no US nexus have more room to experiment, but the question of who runs the UI eventually surfaces.

Why did OFAC sanction a smart contract instead of the developers?

OFAC's 2022 designation framed Tornado Cash as a 'cyber-enabled activity' that laundered virtual currency, so it sanctioned the deployed contracts directly to maximize disruption. The choice drew immediate legal challenges on the grounds that immutable code is not 'property' of a foreign national. The Fifth Circuit agreed in 2024, which is why OFAC delisted the contracts in 2025 but shifted the practical enforcement weight to addresses, operators, and front-ends.