Does Circle have the legal right to freeze USDC accounts? Does this conflict with the common understanding of crypto as "decentralized"?
Yes, it's legal, and it's an explicitly documented feature built into USDC's Smart Contract design — not a bug or an exceptional workaround. Circle, as USDC's issuer, maintains a blacklist mechanism in the contract that lets it, in cooperation with law enforcement or court orders, blacklist specific addresses and freeze the USDC they hold. This mechanism has existed since USDC launched and is disclosed in official documentation — it isn't a hidden feature this incident just uncovered.
This does conflict with many people's intuitive picture of "crypto" — decentralization, censorship resistance, and the ability for anyone to transact freely are properties of native tokens like Bitcoin and Ether. But stablecoins like USDC and USDT, issued by a single company promising a 1:1 peg to fiat, are fundamentally closer to "a company's liability claim wrapped in blockchain technology." The issuing company must comply with the laws of its jurisdiction, including cooperating with court orders to freeze funds — which is exactly why fully decentralized stablecoins like DAI, with no single issuer able to freeze accounts, are seen by some users as closer to crypto's original censorship-resistant ethos, but consequently also lack the ability a centralized Stablecoin has to recover stolen funds or cooperate with law enforcement against fraud. Each design has its own tradeoffs, without one being unambiguously better.
In this incident, why couldn't Circle just freeze the specific address actually involved, instead of freezing the entire contract?
The key is that Zama's cUSDC is a pooled wrapper contract: all USDC deposited by users flows into the same single contract address, uniformly managed and accounted for by that contract, with each user's individual balance existing only within the contract's internal encrypted state (since cUSDC uses fully homomorphic encryption to hide balances). From outside the contract — including from Circle's view — all that's visible and operable is "how much USDC this one contract address holds"; there's no way to distinguish externally "which portion of that money belongs to whom."
Circle's technical mechanism for executing a blacklist works by adding a specific address to a blacklist at USDC's Smart Contract level, preventing that address from sending or receiving USDC — the smallest unit this action operates on is "an address," and because Zama's contract design has all users sharing the same address, the "implicated address" the court order required freezing was, in practice, the entire cUSDC contract address. Circle had neither the ability nor any technical channel to "only freeze the portion of the contract's balance belonging to one specific user" — this is a structural technical limitation of the pooled design, not Circle choosing not to do a precise freeze.
Going forward, is there a way to check whether a contract uses a pooled design before depositing funds into it, to avoid similar risk?
There are a few directions you can investigate yourself. First, check the contract's description or label directly on a Block Explorer (like Etherscan) — many pooled contracts get labeled with names like "Pool," "Vault," or "Wrapper," while segregated-design contracts typically show each user with an independent address or sub-account. Second, check the protocol's official documentation — legitimate protocols usually explain their custody architecture, whether it's "all user funds aggregated into a single contract" or "each user holds an independent on-chain position"; if you can't find this kind of explanation, it's worth actively asking in the community or via support. Third, you can directly check the contract address's past transaction history on a Block explorer — if you see large amounts of funds from many different users all flowing into the same address, with no further splitting into sub-addresses underneath it, that's likely a pooled design.
A more practical approach: if the amount you're depositing isn't small and you're genuinely concerned about this kind of shared-liability risk, prioritize protocols with public audit reports that explicitly describe a segregated-account architecture, or spread deposits across several smaller pools rather than concentrating most of your funds into a single pooled contract — the latter, even if the probability is low, concentrates your exposure more tightly should an incident like Zama's occur.
What might the follow-on consequences of this incident be for Circle, Zama, and Overnight Finance respectively?
For Circle, this incident will keep getting cited as a concrete example in the argument that "centralized stablecoins lack censorship resistance," particularly the part where innocent users got caught up in the freeze — this may prompt regulators or the community to start discussing whether issuers have an obligation, or the technical capability, to execute more precise freezes when carrying out court orders, rather than simply locking down an entire pooled contract. This kind of discussion is unlikely to change Circle's existing blacklist mechanism design in the near term, but over the long run it could influence whether similar wrapper protocols proactively avoid pooled designs in their architecture.
For Zama, while this incident confirmed the protocol itself did nothing wrong, the fact that "money you deposited can get frozen because of someone else's lawsuit" directly damages user trust in privacy-wrapper services — particularly ironic given that Zama's core selling point is protecting user privacy, yet the pooled nature of its contract design exposed all users to this same shared-liability risk. If Zama's team wants to rebuild trust going forward, they may need to redesign the contract architecture toward segregated accounts. As for the lawsuit between Overnight Finance and Maxim Ermilov, the ultimate disposition of these funds awaits the outcome of the June 1 hearing — that's a separate legal matter distinct from the risk inherent to the Stablecoin mechanism itself.
At 01:08 UTC on May 30, 2026, USDC issuer Circle executed a blacklist against the cUSDC contract run by privacy protocol Zama, freezing a total of $12,606,386 in USDC held inside it. What quickly became clear afterward: the vast majority of that frozen money didn't belong to the account that triggered the dispute — because cUSDC is a pooled contract, and once one account gets flagged, everyone else's money sitting in the same pool gets locked right along with it.
The chain of events started on May 11, when a wallet linked to DeFi yield protocol Overnight Finance deposited roughly $12.4 million in USDC into Zama's cUSDC contract — a "confidential USDC" wrapper Zama built using fully homomorphic encryption (FHE), letting users hold and transfer USDC without exposing their balances publicly. Three plaintiff funds subsequently sued Overnight Finance founder Maxim Ermilov in the U.S. District Court for the Northern District of California, alleging he moved more than $15.77 million out of the protocol's treasury just before a community vote to liquidate and distribute funds. On May 29, federal judge P. Casey Pitts issued a temporary restraining order (TRO) directing Circle to blacklist addresses connected to the disputed funds. Circle executed that order the following morning — but because cUSDC pools all user funds into a single contract address, the smallest unit Circle could freeze was the entire contract, not one individual account. The result: the disputed funds accounted for over 99% of the frozen pool, but the remaining less than 1% — deposits from entirely unrelated users — got locked right along with it, and Zama received no advance notice whatsoever.
The fact that Circle has a built-in blacklist mechanism in USDC's Smart Contract isn't itself news — centrally issued stablecoins like USDT and USDC almost universally retain the ability to cooperate with law enforcement and freeze suspicious addresses, one of the fundamental design differences from decentralized stablecoins like DAI. What's genuinely worth noting is the mechanism detail this incident exposed: once your funds sit inside a pooled third-party contract (a Cross-Chain Bridge, a privacy wrapper, or certain yield aggregators, for example), the risk you're actually exposed to isn't just "will my own address get flagged" — it's also "will anyone else sharing that same contract address get flagged." That's because an issuer's technical ability to execute a blacklist can only target the contract-address level; it has no way to distinguish which balance inside a shared contract belongs to whom. Zama's team subsequently confirmed the freeze stemmed entirely from a single depositor, with no wrongdoing alleged against the protocol itself — but as a precaution, Zama paused all three of its wrapper contracts: cUSDC, cUSDT, and cWETH.
If you hold centrally issued stablecoins like USDC or USDT, a baseline fact worth internalizing is that issuers retain freeze authority — that's a condition you're already accepting when using these tokens, and it isn't a new risk in itself. The genuinely new risk is that if you deposit these stablecoins into any pooled third-party contract — not just privacy wrappers, but also many cross-chain bridges and some yield-aggregating protocols — you're effectively tying your own funds' risk to the behavior of every other depositor in that same pool. Even if you've done nothing wrong yourself, you could temporarily, or even long-term, lose access to your funds because someone you've never met, sharing the same pool, got flagged for investigation. A concrete judgment call you can make: before depositing funds into any third-party contract, check whether it uses a pooled design (all user funds aggregated into a single address) or a segregated design (each user gets an independent on-chain address or sub-account) — with the latter, even a similar blacklisting event would typically only affect the flagged account, without dragging in unrelated users.