USDT freezes multiplied by eight in 2026: what 2,511 on-chain events show

Most published commentary on Tether freezes cites the same handful of headline seizures. Those are the visible tip. The interesting part is the base rate, because the base rate is what determines the chance that an ordinary counterparty in an ordinary P2P trade is holding coins that stop moving next week. That number is not published anywhere, so we built it.

The method, so you can judge the numbers

USDT is not a neutral bearer instrument. The contract exposes a function that lets the issuer mark an address, after which transfers from it fail. On Ethereum this emits an event; on TRON the equivalent is visible through the contract's event log. We poll both directly and store every event we see, with its timestamp and chain, in an append-only file. There is no vendor between us and the contract.

Two honest limitations. Our TRON window starts later than our Ethereum window, so cross-chain totals should be read as a floor rather than a complete history. And the TRON API does not return removal events, so unfreeze counts come from Ethereum only. Everywhere below, if a number is partial we say so.

What the series shows

From September 2025 through February 2026 the corpus records between forty and eighty-eight freezes a month. That is the quiet baseline. March 2026 records 141. April records 451. The months after that stay in the same new range: 328 in May, 364 in June, 489 in July. August is at 137 with half the month still to run.

The step is the story. A gradual rise would suggest organic growth in enforcement capacity. A single-month jump of roughly three and a half times, holding at the new level for five consecutive months, suggests a change in process rather than a change in volume of crime. Something in how requests are handled, batched or authorised changed in early 2026, and it has not reverted.

By network, the corpus holds 1,587 TRON events and 924 Ethereum events. TRON carries the larger share, which matches where retail USDT actually moves in the markets we serve. Anyone reasoning about their exposure from Ethereum data alone is looking at the smaller half of the problem.

Freezes are not reversible in practice

Against 2,511 freeze events the corpus records 287 removals, and those removals are Ethereum-only for the API reason above. Even reading that ratio generously, unfreezing is the exception. Destruction, by contrast, is routine: the corpus accounts for roughly 566 million dollars of USDT burned from blacklisted addresses.

The practical reading is that a freeze should be treated as terminal until proven otherwise, and that the recovery path, where one exists, runs through the law enforcement agency that initiated the request rather than through an appeal to the issuer. There is no consumer appeals portal. A petition from a private individual is not the mechanism.

This is also the number to hold up against anyone selling unfreezing as a service. If a provider implies that a blacklisted address can be cleared on request, ask them how their success rate compares with a base rate of roughly one in nine, measured on chain, on the network where removals are even observable.

What it means for a normal trade

Roughly three hundred addresses a month entering the blacklist is not a large number against total USDT users, and we are not going to inflate it into a panic. The exposure is not that your own wallet gets frozen out of nowhere. The exposure is second-order: you accept coins from a counterparty, those coins later turn out to have come from an address that gets marked, and the exchange you deposit into runs its own screening and holds your deposit. Your wallet was never touched. Your deposit is still stuck.

That is why screening a counterparty before a trade is worth the two seconds it takes, and why screening after the money has moved is worth much less. Once the transfer is on chain, your options narrow to explaining rather than avoiding.

What our own detection actually catches

We run a weekly backtest against our own corpus, and we publish the result even though it is not flattering. The method: take a random sample of addresses that were frozen, run our engine over them, and count how many our independent signals flag without being allowed to look at the blacklist itself. Including the blacklist would make the score trivially perfect and meaningless.

The most recent run scored 28 percent on a sample of sixty. The signals that fire are behavioural: high fan-in on fourteen of them, transit-like flow on four, address freshness on three. Known-scam database matches and sanctions matches contributed nothing on that sample, which tells you those lists lag the freezes rather than predicting them.

Twenty-eight percent is a coverage correlation, not a prediction, and we describe it that way deliberately. Without a paid clustering database the honest ceiling on keyless analysis is lower than the marketing of larger vendors implies. We would rather publish a modest number we can reproduce than a large one we cannot.

How the corpus compares with what vendors publish

Commercial analytics vendors do publish freeze statistics, and their numbers are generally larger than ours because they aggregate across more chains and buy access to data we do not have. That is a real advantage and we are not going to pretend otherwise. What we can offer that a vendor report cannot is the raw event stream with timestamps, so that anyone can recompute our figures rather than take them on trust. A number you can reproduce is worth more than a larger number you cannot.

It also means our series is auditable in a specific way: if a month looks anomalous, the individual events behind it are addressable, dated and checkable against the contract by anyone with an RPC endpoint. We have had exactly one case where a monthly figure looked wrong, and it turned out to be a batch of 131 addresses marked within a single hour on 1 July. That kind of clustering is invisible in a monthly total and obvious in the event log.

Batches, and why they matter for interpretation

Freezes do not arrive evenly through a month. They arrive in clusters, and the clusters correspond to whatever process authorised them. A day with a hundred and seventy events followed by a week of three or four a day is the normal texture of this data, not an artefact.

For an individual holder the implication is uncomfortable but useful: exposure is not a smooth risk that accumulates gently with time. It is lumpy. A counterparty who looked entirely ordinary last Tuesday can be inside a batch on Wednesday, along with several dozen addresses connected to the same investigation. This is the mechanism behind most of the "my coins were fine and then suddenly they were not" cases we see, and it is why the timing of a screening matters as much as the screening itself.

What we would need to say more

Three things would sharpen this analysis and we do not have them. Attribution of the initiating agency, which is not on chain and is not published. Clustering that would let us say how many separate investigations the 2,511 events represent rather than how many addresses. And a comparable series for stablecoins other than USDT, which would show whether the step change is issuer-specific or industry-wide.

Until those exist, the claim we are willing to defend is narrow and factual: on the two chains we observe directly, Tether blacklist activity stepped up roughly eightfold in early 2026 and has held at the new level for five months, unfreezing remains rare, and destruction of frozen balances is routine.

Use the data

The corpus updates daily and feeds our public radar page and the address pages that carry a dated freeze fact. Journalists and researchers are welcome to the numbers in exchange for attribution, and we will answer methodology questions in detail, including the parts where our coverage is incomplete.

If you want to check a specific address against the same source we use, the free checker reads the contract directly and shows the freeze date from this corpus where we have it. No account, no email.