Tether Blacklisting, One Year Later: Is the Freeze Window Any Safer?

Key findings (24 months of on-chain observation, May 2024 – May 2026):

• Tether destroyed $1.08B USDT via destroyBlackFunds over 24 months ($822M in the last year alone) — about 3× the prior year per period.
• $127.6M USDT left targeted addresses inside the public submit → execute window on clean cases — ×6.1 versus $20.9M a year earlier. This is gross over blacklisting events, not deduplicated by principal (see the methodology caveat).
• Growth is concentrated on Tron (×5.6, an already-industrial pipeline); Ethereum's ×7.0 is outlier-driven — the single largest case is 51% of the post-period.
• Tether can already compress the window to seconds in urgent law-enforcement takedowns (ETH median 0 minutes in March 2026) — but has not made that the default; ~85% of blacklistings still run through the slow public window.
• A new pattern emerged on Tether's own side — atomic addBlackList + destroyBlackFunds in a single block — but it is applied selectively (one $31.77M case carries nearly all the value).
• The vulnerability is architecturally unchanged: both multisigs (3-of-6 ETH, 2-of-3 Tron) saw zero owner or threshold changes in 24 months. Every speedup is behavioral, not contractual.

Key terms. addBlackList / removeBlackList — owner-only USDT calls that freeze / unfreeze an address · destroyBlackFunds — burns the USDT held by an already-frozen address · isBlackListed — the public on-chain flag marking a frozen address · submit → execute (freeze) window — the gap between the first multisig signature to freeze and the final one that executes it; the address is still spendable inside it · threshold confirm — the signature that reaches the required count (3rd on ETH, 2nd on Tron) and triggers execution · multisig (Gnosis-classic) — the owner wallet: 3-of-6 signers on ETH, 2-of-3 on Tron · interceptor (≠ wallet drainer) — an actor that pulls USDT out during the window, not a phishing/approval drainer · MEV — inserting a transfer ahead of the freeze · atomic destroy — addBlackList + destroyBlackFunds bundled into one block · clean / racing / partial / weak / noise — interception buckets by how fully the address was emptied (clean = ≥95% out and ≤5% left) · bal_sub / bal_exe — balance at submit / at execute; out_share = outflow ÷ bal_sub, bal_remain = bal_exe ÷ bal_sub · median / p90 / p99 / wmean — window-length statistics (wmean = amount-weighted mean lead) · T3 FCU — the T3 Financial Crime Unit (Tether + Tron Foundation + TRM Labs).

In May 2025, BitOK — a blockchain-analytics and AML firm — published research on how USDT blacklisting works on Ethereum and Tron. The core finding back then: between the moment a Tether multisig signer submits the first signature to blacklist an address and the moment the blacklisting actually executes, hours pass (sometimes more than a day) — and during that window the target address can see that it is about to be frozen. One public log entry is enough to beat the freeze and move the USDT to a clean wallet. Our conservative estimate at the time was that $30M+ of bad actors' funds had been saved this way — roughly $18.1M on Tron (80 episodes) and $13.0M on Ethereum (28 episodes), counting insider addresses that exited inside the submit → execute window ahead of the freeze.

A year has passed. Tether has taken a series of public steps — it announced "real-time disclosure of blacklisting" in September 2025, massively scaled up coordination with law enforcement through the T3 Financial Crime Unit, and ran a string of high-profile takedowns worth hundreds of millions of dollars. This is the re-measurement: how many blacklistings there are in total, how the "submit → execute" window changed, how much more (or less) carefully abusers exploit that window, and what new operational patterns Tether itself has developed.

Table 1 — The year at a glance: on Tron, blacklistings ×2.4 and USDT destroyed ×3.3; the median window fell 23–44%; yet clean in-window interception jumped ×5.6 (Tron) to ×7 (ETH).

The short version: over the past year Tether sharply increased the frequency of blacklistings (especially on Tron), tripled the destruction of funds, and shortened the typical (median) execution window. But the window's "tail" on Tron got heavier, and on both chains we hold direct on-chain evidence of automated interceptor bots that beat the multisig confirmation: in this one year alone their gross outflow on clean cases was $127.6M USDT ($52.4M ETH + $75.3M TRX, 107 addresses) — versus $20.9M a year earlier, i.e. in dollar terms exploitation of the vulnerability grew 6.1×. This is a sum over blacklisting events, not deduplicated by principal: on certain clusters an interceptor operator rolls the same USDT through several addresses that get blacklisted one after another, and each hop is counted separately (see the methodology section and the sister-series case of 28–29 July 2025 — there gross is $19.14M against a direct unique principal of ≤$7.66M). Another ≈$51M sits in borderline cases (racing/partial/weak) that we moved into appendices for individual AML review. In parallel, Tether itself developed a new operational pattern — atomic addBlackList + destroyBlackFunds in a single block for targeted LE operations, which barely existed before 2025; and a separate, persistent storyline — $65.7M USDT that landed on ALREADY-blacklisted addresses (463 addresses) and was destroyed at the next destroyBlackFunds (people keep transferring to addresses on the public blacklist).

The year's main meta-story. Over the year the two sides moved asymmetrically: Tether showed it can compress the window almost to zero in urgent takedowns (see "Bimodality: the urgent mode") but did not make that the default workflow; the interceptors, in turn, took already-existing window exploitation (pre-period: $20.9M gross clean-outflow / 62 cases — not zero) and turned it into industrial infrastructure — the post-period produced $127.6M / 107 cases. The 6.1× growth is not the appearance of new techniques, but the industrialization of already-existing window exploitation. As long as the public pending window remains the default, this infrastructure keeps working on whatever the next large targets are.

---

Contents

1. The scale of blacklisting over the year
2. The legal nature of blacklisting
3. Technical context and methodology
4. Blacklisting empty addresses
5. The submit → execute window
6. Exploiting the vulnerability — interceptor bots
7. Atomic destroy — the new pattern of 2025
8. What this means for Tether
9. Reproducibility: data and scripts

---

The scale of blacklisting over the year

Over the 24 months observed, Tether triggered the blacklisting of 7,562 addresses (775 + 718 on Ethereum + 1,778 + 4,291 on Tron) and destroyed $1.08 billion USDT via destroyBlackFunds (150 + 476 + 104 + 346). In the last year alone — $822 million of destroyed USDT.

Every number in this article is computed from open on-chain data — the full dataset and the scripts to recompute it are in the open repository on GitHub: you can independently re-check every figure below.

Table 2 — Blacklisting became a mass channel: on Tron addBlackList ×2.4 and removeBlackList ×4.0, while destroyed USDT rose ×3.2 on ETH and ×3.3 on Tron — more money burned per freeze.

The dynamics differ by period. On Ethereum the number of blacklistings barely changed (775 → 718), but the burn of destroyed USDT grew 3.2× — meaning that per blacklisting, Tether on average destroys noticeably more money. On Tron the count grew 2.4× and the burn volume 3.3×.

In absolute terms, across 2025–2026 Tether as a stablecoin issuer probably became one of the largest publicly observable on-chain enforcement instruments — by frozen and burned volume among stablecoin issuers. External summaries confirm the order of magnitude: the T3 Financial Crime Unit (Tether/Tron/TRM Labs) passed $300M+ in frozen assets across 23 jurisdictions by the end of October 2025; BlockSec independently counted $1.26B frozen / 4,163 addresses for calendar 2025 alone; Reuters puts the all-time figure at $4.2B frozen with Tether's involvement in 1,800+ investigations. Our sample confirms these numbers to within an order of magnitude.

The main takeaway: blacklisting USDT has stopped being a rare technical operation — it has become a mass enforcement channel that processes hundreds of addresses and tens-to-hundreds of millions of dollars every month.

---

The legal nature of blacklisting

A blacklisting is a call to addBlackList(addr) or removeBlackList(addr) on the USDT contract, which only the contract owner can make. Technically it is a trivial function — but legally it works because Tether, as the stablecoin issuer, reserved the right to freeze tokens at specific addresses. That right is written into the Terms of Service and was confirmed in the company's public communications back in 2017–2018, when the corresponding methods first appeared in the contract.

The overwhelming majority of 2025–2026 blacklistings happen at the request of law enforcement (Secret Service, DOJ, OFAC, FBI, Guardia Civil, Royal Thai Police, Turkish police, the Iranian-sanctions OFAC regime, and many others) or through purpose-built structures — first and foremost the T3 Financial Crime Unit (a joint project of Tether, the Tron Foundation, and TRM Labs), launched in August 2024, which in 2025 alone turned USDT freezing into a systemic instrument of international financial control. In a subset of cases Tether acts preemptively — for instance during major hacks (Bybit-Lazarus, $1.5B), when it freezes addresses receiving the stolen funds.

A detailed overview of the legal nature of stablecoin freezes is in BitOK's recent piece, "Willkie Farr & Gallagher: the legal practice of stablecoin freezes".

Timeline of notable public takedowns, 2025–2026

A brief rundown of what matters over the period — what reached the public sphere and forms the backdrop against which we measure the quantitative shifts. The bullets cover all of 2025–2026 (i.e., slightly wider than the post-period of May 2025 → May 2026) so the reader sees both the pre-publication context and the post-publication dynamics:

• 2025-01-11 — $182M USDT frozen across 5 Tron wallets at the request of US LE (The Block).
• 2025-01-27 — T3 FCU + Guardia Civil: $26.4M (Tether release).
• 2025-02-22..24 — Tether froze 181,000 USDT after the Bybit/Lazarus hack ($1.5B) (The Block).
• 2025-03-06 — $27–28M frozen on Garantex after the EU's 16th sanctions package (CoinDesk); in parallel the USSS recognized Tether for assisting in a $23M recovery.
• 2025-06-18 — DOJ filed a civil forfeiture complaint for $225.3M USDT in a pig-butchering scheme and formally recognized Tether for its assistance (Tether release, Decrypt). Note the timeline: the freeze of 39 wallets holding ~$225M happened back in November 2023 (Tether + OKX at the DOJ/USSS's request), and the burn-with-reissuance to a USSS wallet was authorized by a court in June 2024 (the largest seizure in Secret Service history at the time) — 18 June 2025 refers only to the filing of forfeiture documents and the public acknowledgment of Tether.
• July 2025 — $1.6M of terrorism-linked funds frozen (BuyCash/Gaza) (Tether release).
• 2025-10-31 — T3 FCU > $300M across 23 jurisdictions (Tether release, CoinDesk).
• November 2025 — Royal Thai Police + USSS: $12M, 73 arrests (Tether release).
• 2026-02-07 — Turkey: $544M USDT (the Şahin network's illegal gambling) (Bloomberg).
• 2026-02-25 — DOJ: $61M USDT seizure (NC pig-butchering) (The Hacker News).
• 2026-04-23..24 — Operation "Economic Fury": $344M on 2 Tron wallets of the Central Bank of Iran; OFAC ran a parallel SDN listing (Tether release, CoinDesk, Chainalysis).

Tether's policy statements

• 9 September 2025. Tether announced publication of every blacklisting in real time (WiseLawAI summary). This is a step toward transparency: AML services and third parties can react to a freeze's status immediately, without waiting for their own feeds to update.
• 12 September 2025. Announcement of USAT — a separate, GENIUS-Act-regulated USDT for the US. CEO is Bo Hines (former executive director of the White House's Crypto Council), the issuer is Anchorage Digital, and the reserve custodian is Cantor Fitzgerald (Tether release). Long-term this means part of the "blacklist" burden moves into a natively more regulated construct in which KYC/AML compliance is built into the issuance loop itself.
• 31 March 2025. MiCA took effect. Tether did not obtain MiCA authorization; USDT was delisted in the EEA by Binance, Crypto.com, and Kraken (Decrypt). In parallel, Tether first announced freezing residual USDT on 5 legacy chains (Omni, BCH SLP, Kusama, EOS, Algorand) effective 1 September 2025, but walked the plan back in August 2025 and simply left those chains "unsupported." For our research this means: the number of chains where the studied vulnerability operates did not grow — the bulk of blacklisting is still ETH + TRX.
• 26 November 2025. S&P downgraded USDT's stability to "weak." Ardoino's reaction — "We wear your loathing with pride" (CoinDesk). Context for the overall "Tether-as-enforcement-instrument" picture: even amid criticism of its reserve structure, the company keeps scaling up LE cooperation, and both processes run in parallel.
• May 2026. External summary from BlockSec for 2025: $1.26B frozen / 4,163 addresses; 55.6% destroyed via destroyBlackFunds, only 3.6% unfrozen. Our sample independently confirms these numbers to within an order of magnitude.

The full list of sources and quotes is in docs/sources_tether_statements.md.

---

Technical context and methodology

Contracts and owners

The key point. Across all 24 months observed, neither multisig had a single OwnerAddition, OwnerRemoval, or RequirementChange. That is, architecturally Tether did nothing that would shrink the wait window via a 1-of-N scheme or a single "urgent" signer. Every speedup we'll see below in the submit→execute window is behavioral, not contractual: signers started reacting faster, offline coordination emerged for urgent takedowns, but the multisig mechanism itself stayed the same.

Current signers of the ETH multisig (6 total, threshold 3):

0xAC3B242E2E561da9F4cE34746E67d004E6341FA0
0xEe5207d3c88562fc814496Af0845B34CFD4afc8c
0x61D5a4d5Bd270e59E9320243e574288e2a199fED
0x25bB61643e4881147E6aabb65e6DD45CF2904155
0x4096a34E582664F969753b34dA6E72D55b3C85C1
0x4D915Dd2c56814BD3Db51a1dA35b302BCC9c8973

Tron (3 total, threshold 2):

TYn9kGVaNbXCsdqDCvKu4ubDvj3ZSxmyN1
TKHuVq1oKVruCGLvqVexFs6dawKv6fQgFs
TRLi4KskHxfACnxKzLrf2wNHauWUQpwziN

The blacklisting cycle and the measurement points

   submit                    threshold reached            actual execution
        │                          │                            │
        ▼                          ▼                            ▼
 Submission(txId)        Confirmation #N (N=required)      Execution(txId)
        │                          │                            │
        └────────────── "vulnerability" window ───────────────────┘
                                                       │
                                                       ▼
                                              AddedBlackList(addr)
                                                  on the USDT contract

The window is the time from Submission(txId) to Execution(txId) (or, equivalently, to the AddedBlackList event on the USDT contract). In the Gnosis-classic multisig on which both owner wallets are built, submitTransaction already emits both Submission and the first Confirmation (from the submitter). The final Confirmation (the third on ETH, the second on Tron) executes executeTransaction in the same transaction — so the moment of threshold confirm ≈ the moment of Execution. The exploitation window available to an outside observer opens with the first Submission and closes with the final signature.

The comparison window

"Before" — 1 May 2024 — 30 April 2025 (the 12 months before the research was published). "After" — 1 May 2025 — 9 May 2026 (12 months + 9 days). The boundary is the publication date of the May piece on the vulnerability.

What we did: data and checks

To get a "clean" comparison, we re-pulled and re-computed every event over the 24 months. A summary map of sources:

Since Tron does not offer cheap access to historical balanceOf state via public RPC (only latest), for Tron balances and flows we supplemented the data with an internal indexer — this is simply a re-aggregation of all USDT Transfer events within the relevant time windows, and it is fully reproducible from the contract's open events if desired. To make sure the internal indexer introduces no systematic distortions, we ran the same indexer on Ethereum too — where we separately have an RPC balance measurement via eth_call — and reconciled the two sources.

ETH cross-check (RPC balances vs internal indexer), 1,492 cases:

• starting balance: 99.93% match (1,491 / 1,492);
• ending balance: 99.46% (1,484 / 1,492);
• in-window outflow: 98.79% (1,474 / 1,492);
• "drained" flag: 99.06% (1,478 / 1,492).

10 of the 18 discrepancies are small differences ($1–3k) at the window edges (timestamp resolution). 8 discrepancies are the atomic-destroy cases (see the atomic destroy section): RPC sees bal_exe = 0 (eth_call returns state after the destroy in the same block), while the indexer-via-Transfers does not see the destroy and therefore considers the balance unchanged. Both figures are technically correct — this is a signal of an atomic destroy, and for the Tron classification we additionally stitched the indexer data together with data/tron_blacklist_events.csv to correctly separate atomic from the regular workflow.

99%+ agreement between two independent sources means the methodology is robust — and the Tron figures, for which no RPC check exists, can be interpreted the same way as the ETH figures.

---

Blacklisting empty addresses

Before analyzing the window's duration and its exploitation, we need to separate out a distinct class of operations — blacklistings of addresses that already held no USDT at the moment of submit (or held a dust balance under $100). They count toward the overall addBlackList tally, but they carry no material for a risk cut: there's nothing to "drain" on an empty address, and analyzing speed/interception on it is meaningless.

All numbers in this section are computed on the multisig-action universe (addresses that went through an executed addBlackList multisig chain) — it differs from the AddedBlackList events of the USDT contract in the Section 1 headline by 1–2 cases, which does not affect the interpretation.

Table 3 — Opposite trends on empty (<$100) blacklistings: on Tron the share rose 24.9% → 35.7% (mass cluster sweeps), on ETH it fell 18.6% → 10.9%.

On Tron in the post-period, more than a third of all addBlackLists go to addresses with a balance under $100 — in absolute terms a 3.4× rise (444 → 1,532). On ETH the trend is the opposite: from 18.6% to 10.9%, an absolute decline even (144 → 78).

What happens next to these "empty" Tron-post blacklistings:

• Of 1,239 addresses with an exactly zero balance, only one received a subsequent destroyBlackFunds ($0.5M). The other 1,238 simply sit on the blacklist with no movement at all.
• The submit → execute window on empty Tron-post addresses takes a median of 35 hours; on addresses with a balance — 51 minutes. That is, Tether processes the "empty" ones in low-priority batches, while the "money" ones go noticeably faster.

The overwhelming majority of empty Tron blacklistings are forward-defensive cluster sweeps: Tether (probably via T3 FCU with LE data) blacklists whole groups of related addresses at once, including empty cluster nodes, to prevent their reactivation. There's no money there and most likely won't be, but isBlackListed=true is set preemptively. On ETH the practice is more selective — hence the falling share of empty ones.

This reframes the Tron ×2.4 growth claimed in Section 1 (1,780 → 4,289 in the multisig universe): the real financial load grew only ×2.1 (1,336 → 2,757 non-empty addresses). Most of the increase is the industrialization of LE cooperation via mass sweeps, not more actual money targets.

From here on in the risk cuts (window length as attack surface, exploitation of the vulnerability, lifecycle decomposition) we use only the non-empty-balance subset (bal_sub > $100); empty addresses have no meaningful risk scenario and only dilute the statistics. The window's own metrics (median/mean/p99 — these are a property of Tether's workflow) are computed on the full sample. One counterexample to the worry that the filter "hides" effects: March 2026 ETH (133 blacklistings, 0-minute window median) — of which 24 are empty and 109 have a balance, and the median for both subsets is identically 0 minutes. So the "urgent mode" (see below) is about the composition of multisig operations, not about separate handling of empty ones.

---

The submit → execute window

After the research was published, the main question for Tether was: will it close the window? There was no direct architectural answer — the multisigs didn't change, the threshold wasn't lowered. But operationally the company clearly did something over the year: in some post-period months the median falls to minutes, in others it rises to hours. Let's break down what happened across three layers:

• Architecturally — no: 6/3 and 3/2 signers, threshold 3/2, not a single OwnerAddition / OwnerRemoval / RequirementChange over 24 months. The attack surface itself (a public submit minutes before the finale) is intact.
• Operationally — yes: the median window shrank by 23–44%, and a distinct "urgent mode" with near-synchronous blacklistings appeared.
• Risk-model — no: the tails did not close (p99 on ETH grew ×2.3, the max on both chains rose), and crucially — even short windows remain exploitable, which we'll show below.

Window metrics

The window metrics themselves are a property of Tether's workflow (how quickly the multisig confirms a blacklisting), and for them it makes sense to use the entire sample, including blacklistings of empty addresses from the previous section:

Table 4 — The median window shrank (−44% ETH, −23% Tron) but the tails did not: ETH p99 rose ×2.3 and Tron's mean nearly doubled (4h 53m → 9h 6m).

Note that on Tron empty addresses are blacklisted noticeably slower than "money" ones (median 35 hours vs 51 minutes): these are large cluster sweeps that Tether submits in low-priority batches. If you excluded the empty ones, the Tron-post median would fall to ~50 minutes rather than 1h 30m — meaning the "real" progress is faster than it looks on the full dataset. For the risk cut below (window length → drainer rate), empty addresses are excluded explicitly (bal_sub > $100).

The distribution is clearer on histograms (capped at p99):

Fig. 1 — Most freezes confirm within ~2 hours, but a heavy multi-day tail persists: even as medians fell, ETH p99 rose ×2.3 and Tron p90 ×3.1.

And the month-by-month dynamics of the window median, in log scale:

Fig. 2 — Two workflows in one system: urgent months collapse to minutes (ETH 0 min, March 2026), while batch months climb to ~36 hours (Tron, July 2025).

On Tron the typical blacklisting sped up by 23%, but the tail got heavier: the mean almost doubled (4h 53m → 9h 6m), and p90 grew threefold (from 11h 46m to 1d 12h, ×3.1). This is a side effect of activity spikes — when Tether submits a batch of hundreds of addBlackLists at once (1,071 in July 2025; 760 in March 2026; 426 in April 2026), some transactions wait several extra days for signatures. On ETH the median improved more sharply (−44%), but the extreme tails grew: p99 ×2.3 (2d 7h → 5d 4h), max +28%. Here the p99 rise is entirely explained by one batch of 8 transactions on 29 August — 4 September 2025: the same signer was apparently offline for almost a week, and the final signatures all arrived in a bunch 5+ days after submit. Without that batch, the post max < the pre max — in "normal mode" the ETH tail shrank, didn't grow. The p99 signal is an artifact of a small ETH sample (n=739), not a systemic regression.

And one more caveat to the falling median: it might not be "signers started reacting faster" but a mix-shift — the post-period has disproportionately many coordinated LE takedowns with pre-prepared signatures that land in a single block within minutes and pull the median down. That is, the overall "physical" speed of the workflow may have changed less than the median suggests; the composition of operations is changing. This is confirmed by the next cut.

Bimodality: the "urgent mode" as a separate workflow

The "mix-shift" hypothesis isn't a guess — it's an observable fact. Looking at the window median by month, in several post-period months it drops by orders of magnitude relative to the "normal" level:

Table 5 — A distinct "urgent mode": in some months the median collapses to 0–10 minutes (ETH March 2026, Tron April 2026), while batch months sit at tens of hours.

Across the post-period in total, 117 of 717 ETH blacklistings (16.3%) and 741 of 4,289 Tron (17.3%) executed in under 2 minutes. This is not one or two episodes — it's a parallel, sustained workflow. When needed, Tether can do near-synchronous blacklistings in which 2–3 different signers land in a single block with a minimal public window. The plausible mechanism is law-enforcement-coordinated takedown operations with pre-prepared transactions: ECDSA signatures are prepared off-chain and sent sequentially within one or two blocks. This isn't directly proven (we have no access to Tether's workflow), but empirically on ETH in March 2026 some 90 blacklistings executed in the same block as the submit — a pattern that, on a 3-of-6 multisig, is essentially unexplainable without off-chain coordination and pre-built confirms.

What matters: the "urgent mode" does not close the vulnerability for the remaining blacklistings. When Tether applies this coordination, the window shrinks to seconds; when it doesn't, the window stays open for the standard hours. These are two different workflows in one system, and until the company makes the "urgent mode" the default, the other ~85% of blacklistings remain exploitable.

Window length as attack surface

The basic question: how directly does window length convert into interception risk? We bucket every executed addBlackList with a non-empty balance (bal_sub > $100, atomic destroy excluded) by window length and look at what share of addresses inside each bucket had an outflow:

Fig. 3 — A longer window means a higher interception rate (Tron: 1.2% under 1h → 19.4% over 24h) — yet 60% of the stolen dollars leave in the <1h bucket.

On Tron post (n=2,755 addresses with a balance):

The picture is two-sided:

1. The drainer rate rises with window length — on Tron post, from 1.2% (<1h) to 19.4% (>24h). This is a mechanical dependency: more time = more chances to fire (a bot, a human with an alert, an incidental outflow). Reading the any-outflow rate (which includes racing/partial/weak) gives the same trends but higher levels: up to 41.9% in >24h.

2. But the big money leaves in SHORT windows: $44.94M of the $75.25M Tron-post clean total (60%) sits in the <1h bucket — that's the $37.30M TD3bLbnV case (5.7-minute window) plus several other fast episodes. So long windows are many small addresses with a high probability of a non-automated exit; short windows are few but large addresses with a fast bot. Two different stories, one chart.

The ETH sample is too small (n=37 post with a balance > $100) for reliable bucketing; it's shown on the chart for comparison, but should be interpreted cautiously. There the same top-1 case ($27.12M) fully determines the <1h bar.

Deliberate selective delays?

Since we're building the "long window → higher chance of interception" picture, it's logical to check the adjacent hypothesis: is Tether leaving windows open selectively for specific addresses? The data does not support this version: the long >24h tail on Tron post is 62 cases with a median bal_sub of $111k and a maximum of $3.0M (top-1 is classification=none, a residual frozen one; among clean targets the max is $1.5M); the largest interceptions sit precisely in short windows where the multisig fired normally. Under a "hold the window for specific targets" model, we'd expect $5–10M targets in the tail, not $100k averages. The absence of $$ concentration in the tail doesn't prove the absence of selectivity (it could be rare and pinpoint), but it rejects the simple "long windows = deliberate delays" model.

Window length is a property of Tether's system. The attacker's reaction speed is a separate property, and their product gives the real risk. Reaction speed is the next section.

---

Exploiting the vulnerability — interceptor bots

Terminology. "Interceptor" is the general term for any actor that withdraws USDT from an address in the window between submit and the final confirm of Tether's multisig. The spectrum runs from a MEV bot with a private mempool and sub-second reactions to a human with a Telegram alert and a pre-built RAW transaction. When we specifically mean the MEV-class automation, we write "interceptor bot"; the general case is just "interceptor." In both scenarios the function is the same: beat the third (on ETH) or second (on Tron) multisig signature and take the funds while isBlackListed=false. Not to be confused with a "wallet drainer" in the mass-UX sense (phishing sites, fake approvals) — that's a different phenomenon.

In the scripts and data tables we kept the technical term drainer (it appears in field and file names — eth_drainer_classification.csv, drainer_destinations_full.csv, etc.); in the article text and chart captions all of it is "interceptor."

Classification methodology

For each addBlackList call we ran two checks:

1. Balances. On ETH — archival balanceOf via eth_call at the submit and execute blocks. On Tron — the balance from the indexer (via the sum of all Transfer events up to the block).
2. Control via Transfer events. For each "potentially drained" address — we pull all Transfer(from=address) in [sub_block, exe_block] on the USDT contract, look at the block of the last Transfer, and compare it with the block in which the multisig received the final (third on ETH, second on Tron) Confirmation. If the outflow happened strictly BEFORE the threshold confirm — it's an interception. If the outflow is in the same block as addBlackList+destroyBlackFunds — it's an atomic destroy (classified separately). If the outflow is only after — it's normal behavior (the address was drained before Tether even noticed it; the blacklisting arrived at an already-empty address).

Bucket classification: clean / racing / partial / weak / noise

The mere presence of a Transfer in the window is not enough — an address with active trading can see ordinary traffic during an hour-long window. To separate "the bot fired successfully" from "a random outflow in the window," we classify each case by two symmetric metrics:

• out_share = outflow / bal_sub — what fraction of the original balance the bot withdrew;
• bal_remain = bal_exe / bal_sub — how much of the original balance remained on the address at the moment addBlackList executed.

Table 6 — Only "clean" cases (≥95% out, ≤5% left) enter the headline — 14 ETH / $52.4M and 93 Tron / $75.3M post-period; racing/partial/weak are held back for individual AML review.

Only clean cases go into the headline — this is the strictest and most defensible definition of "the bot fired successfully." The other four buckets are materialized as separate CSV files for individual AML review and do not enter the headline ETH+TRX post vs pre comparison:

• data/summary/racing_drainer_for_review.csv — 48 cases / $28.23M
• data/summary/partial_drainer_for_review.csv — 52 cases / $12.56M
• data/summary/weak_drainer_for_review.csv — 105 cases / $10.13M

So our headline estimate of $127.6M post is the gross sum of drainer outflow over clean cases, where clean = out_share ≥95% AND bal_remain ≤5%. This is a lower bound in the sense of "by classification strictness": if manual review finds that some racing/partial cases were real interceptions, the figure should rise. ETH cross-check RPC vs internal indexer across 1,492 cases: 99%+ agreement on all key fields (bal_sub, bal_exe, outflow, drained flag) — the methodology is robust.

An important methodological caveat about the nature of "gross." $127.6M is the sum of outflow over blacklisting events, not over unique principal. On certain clusters the same USDT is rolled through several addresses that get blacklisted one after another: the operator drains to the next fresh wallet, Tether blacklists it, the operator drains to the next — and each blacklisting is counted as a separate event with its own outflow. A spot-check on the sister-series cluster of 28–29 July 2025 (5 addresses, gross $19.14M in the headline; breakdown below) shows: the direct-edge unique principal in that cluster is about $3.83–7.66M. At the level of the whole dataset the overcount is not estimated (it requires raw-edge tracing of all 253 cases); the Stage 2.5 spot-checks indicate that on individual series the overcount can reach up to 80% of that series' gross. For the pre/post comparison and the monthly dynamics, the gross metric is reproducible and valid; for an absolute "how much unique USDT was stolen," use it with caution.

Headline numbers: clean interceptions

Table 7 — The headline: 107 clean interceptions for $127.6M post-period vs 62 / $20.9M before (×6.1), and the average ETH drain grew $0.58M → $3.74M.

Σ post-period: 107 cases / $127.63M versus 62 cases / $20.87M in the pre-period — a 6.1× rise in dollars on the strictest measurement. The dynamics differ between chains: on Tron it's an already-working pipeline (×5.6 in dollars, ×1.9 by number of addresses), on ETH it's episodic large stories (×7.0 in dollars at the same number of addresses). For ETH a disclaimer: the result is heavily outlier-driven — the top-1 case ($27.12M) gives 51% of the post, the top-7 cases give 89%. Without the top-1, ETH post = $25M (still ×3.4 of pre, but not ×7); without the top-7, ETH post < ETH pre. At n=14, one or two episodes move the aggregates a lot.

Who exploits the window: MEV bot or manual-compatible?

Before going chain by chain, an important cut across the whole corpus. If we look at how much time the attacker had between Tether's first signature (submit) and their outflow — i.e. how much reaction time there was — the clean post-period cases distribute like this:

Table 8 — Not all bots: 78% of clean Tron interceptions had ≥10 minutes of reaction time (manual-compatible) against 43% on ETH — sub-second MEV is the exception, not the rule.

On Tron post, 78% of clean interceptions had ≥10 minutes of reaction time — this is the manual-compatible zone: enough time for an alert-driven process given pre-arranged access to a key and a transaction. On ETH it's 43%. Time compatibility doesn't prove a human operation (a bot can also run in a relatively slow mode), but it rules out the reverse: sub-second MEV speed is not needed to exploit the Tron window, and on ETH it's required in only half the cases.

Bot-territory (reaction <1 minute) on Tron post — only 2 of 93 cases (2%). On ETH — 5 of 14 (36%). This rewrites the simplistic "it's all bots" narrative: in fact we're looking at two different exploitations of one vulnerability. The Tron story is mostly alert-driven (a Telegram notification + a pre-built RAW transaction, a light stack, no private mempool needed). The ETH story is half in the full MEV zone (including the sister-series of 28–29 July 2025 with a 12–24-second reaction after submit and a 24–96-second lead over the final signature) and half in the same manual-compatible zone.

The architectural recommendations in the conclusion account for this — both have to be closed, not just the sub-second case.

Tron — the industrial pipeline

Fig. 4 — Tron interceptions are mostly manual-compatible: 78% had ≥10 minutes of reaction time, so no sub-second MEV is needed. Σ clean $13.4M → $75.3M (×5.6).

Interceptions existed on Tron before the publication too — it's an already-working pipeline from 2024. The research's publication didn't "launch" the phenomenon; it arrived at an already-existing infrastructure and increased the share of successful interceptions.

Key numbers on the clean Tron subset:

• The median lead over the final signature dropped from 145 to 86 minutes (×1.7 faster).
• The minimum lead on the clean subset is 105–114 seconds (35–38 blocks). On the wider drainer set (with racing/partial cases) a 3-second (1-block) minimum appears too — that's already MEV-bot territory, but it's empty in the clean definition for the post-period.
• Wmean (the amount-weighted mean lead, see the dashed line on the chart) — pre 3h 33m → post 2h 24m. In the post-period the wmean is pulled up ~$5M by several medium cases with multi-hour leads (TQpVWVhf, TXjgmgqa, etc.) — the typical "someone saw it and fired by hand" scenario.
• Σ drained: $13.39M → $75.25M (×5.6), number of addresses: 49 → 93 (×1.9), average size: $0.27M → $0.81M (×3.0).

The single largest interception across the entire observation corpus — 5 June 2025, $37.30M on Tron:

• target address: TD3bLbnVvcvucnJm8uhvVYGwinUzFUFgud;
• balance at submit: $37.30M;
• submit → execute window: 5.7 minutes (114 blocks);
• the bot beat the final signature by ~120 seconds (40 blocks);
• destination: TEVcwpWwS8wYz837TSBPd8fwMYBYrhnTQC — the only address that doesn't appear anywhere else in our sample.

Top-5 Tron clean post:

Full top-20 — data/summary/top_tron_drainer.csv.

Context on the pre-period case TBikF4W7…aoYAVqnF ($11.95M, 2024-09-17): the target is not a one-day collector but a settlement service with $7.31B lifetime throughput over 8 months of activity (Kraken 61% counterparty, Stillman Digital 22%, Enigma Securities 6.5% per BitOK's AML attribution, deep≈9). The $11.95M interception is <0.2% of its lifetime turnover. The destination TFjBdjN… over the next day distributed $33M to eight exchanges — Binance $13.94M, OKX $5.91M, Kraken $1.67M, BrasilBitcoin $1.20M, Bybit $0.97M, HuionePay $0.96M, HTX $0.96M, Bitget $0.85M.

Sidebar: SunSwap evasion. The largest Tron interception ($37.30M on TD3bLbnVvcvucnJm8uhvVYGwinUzFUFgud, 5 June 2025) showed that minutes of window are already enough to escape into an asset outside the USDT contract's jurisdiction. Within 4 minutes of receiving the USDT, the bot sent the entire amount to the SunSwap V3 router across seven transactions; per BitOK's updated Tron indexer (with native-TRX support), all 7 swaps are confirmed on the output side too — 133.7M TRX did indeed arrive at the drainer destination. After such a swap, addBlackList is structurally powerless — the asset is physically no longer USDT and cannot be burned with destroyBlackFunds. This strengthens the argument for a zero window: as long as there is any time between submit and the final confirm to transfer to a DEX router, this hole remains. Fully closing it requires not "speeding up the multisig from hours to minutes," but eliminating the public pending window (atomic blacklist, pre-signed signatures) — ordinary "workflow speedups" do not close this class of attack. A technical breakdown plus two other escape-automation patterns (with different endings — Tether's marathon and a lightning chase) is detailed in a forthcoming companion piece, "Racing Tether: three escape-automation patterns". For early access, write to pr@bitok.org.

Ethereum — episodic large stories

Fig. 5 — On Ethereum the typical lead over the final signature dropped 46 → 10 min (×4.5), but the post-period is outlier-driven: the top-1 case ($27.12M) is 51%, the top-7 are 89%.

On ETH the red dots are on average shifted left relative to the gray ones: the median lead dropped from 46 minutes to 10 minutes (×4.5 faster). In the top row (post), large dots appeared in the sub-minute zone that didn't exist a year earlier: $27.12M at a 528-second lead, a series of five $3.83M cases in 24–96-second windows.

Disclaimer on statistical significance. At n=13 pre and n=14 post, the median difference of 46 → 10 minutes does not reach the usual significance level (Mann-Whitney U-test: p ≈ 0.14). The trend is visible to the eye on the strip plot, but a strict statistical test does not let us declare it. The Tron sample (49/93) is more robust: the median difference 145 → 86 minutes — there it's not a question of interpreting one or two cases.

ETH minimum leads: 36 → 24 seconds (3 → 2 blocks). On ETH the minimum tightened only slightly — because one pre case already operated in 3-block mode. But the typical interceptor in the post-period started reacting 4.5× faster, and the sub-minute zone now holds not single episodes but a whole series (see below).

Wmean on ETH (the dashed line on the chart): pre 1h 14m → post 13 minutes. Heavily shifted left relative to the median because of the $27.12M case (528-second lead, 51% of the post-period's total weight). This wmean more honestly shows "where the average dollar sits": on ETH post, the average stolen dollar left ~13 minutes before the window closed. Sensitive to the top-1 — subtracting the $27M case returns the post wmean to the hourly range.

The largest on ETH — 26 July 2025, $27.12M:

• target address: 0x928b8864151ee6C1E057964460bf5c7ADDbcA97f;
• balance at submit: $27.12M;
• submit → execute window: 14 minutes (70 blocks);
• the bot beat the final signature by 44 blocks (~528s) — the outflow happened halfway through the window, before the multisig managed to collect the third signature.

Top-5 ETH clean post:

Full top-20 — data/summary/top_eth_drained.csv.

Case 28–29 July 2025: a series of five identical interceptions

On 28–29 July 2025, Tether blacklists five ETH addresses one after another, and out of each, right before executeTransaction, almost exactly $3.83M leaves (three amounts identical to the cent — $3,827,941.90; two differ by $15 and $45). The bot beats Tether's final signature by 24–96 seconds — a signature of automation; a human cannot react that fast.

But looking at the raw transfer edges between the blacklistings, this is not five parallel cases — it's a single stream that Tether chases address by address. B2 → B3 → B4 → B5: the same $3.83M amount rolled through 5 sequential addresses over 7 hours; B1 is a separate stream through the hub 0x414cf116 (the same one that earlier, on 26 July, received the $27.12M from the largest ETH interception). The finale — 6 April 2026, eight months later: Tether in one coordinated batch (12 seconds between transactions) destroyed $25.66M downstream — five addresses in one block for $21.83M plus a final pin 0xD29Ca88b ($3.83M) in the next block.

That is, the gross over blacklisting events in this series substantially exceeds the unique principal, and part of the downstream was later destroyed by Tether — this is a spot-check on the headline caveat about gross. A full breakdown of the race, the flow direction, and the destroy finale of 6 April 2026 is in the same forthcoming companion piece.

Case 27 November — 1 December 2025: multi-protocol DEX-evasion on ETH

A structurally different scenario from the sister series is visible on 27 November — 1 December 2025. Tether blacklists the mother address 0x0996d2538F0E342B0410015CBaf179F21E2Fdb76 on 27 November at 15:13 UTC; over ~22 hours the bot distributes $14.2M downstream to three fresh parallel addresses (A3 0xF92AD00A — clean; C2, C3 — racing/partial, not in the clean headline). On 28 November Tether does a submitTransaction to blacklist the three children, but the final signature arrives only on 1 December at 18:54–18:56 UTC — the submit→execute window for A3/C3 = 3 days 5 hours (the longest among the top post-period cases). During that window the bot pushed $12.70M, mostly through cross-chain bridge-deposit contracts ($4.19M Chainflip — to BTC/SOL/DOT/ARB + Hyperliquid via Hyperunit; $1.06M Near Intents solver; of which $1M went through a fan-out via the relay address A3 with 11 fresh intermediate per-swap deposits) and through Aave infrastructure ($3.45M DEX→Aave staking; $1.50M Aave yield pool); $2.50M was "re-chased" via a follow-up Tether blacklist on one next-hop wallet (0xe493, frozen $4.5M).

The finale differs from the sister series not quantitatively but structurally: the destroy wasn't done not because Tether failed to chase it down via AML, but because there's nothing left to heal. By the time a destroy would have made sense, 80% of the extraction was on other chains (BTC/SOL/DOT via Chainflip) or in native ETH / aUSDT via on-chain swaps. The USDT contract's destroyBlackFunds is inapplicable to those in principle.

A detailed breakdown of all stages (Setup / Cross-chain Stage 2a / On-chain Stage 2b / Tether-follow-up Stage 2c) with raw edges and Arkham entity-mapping is in the same companion piece.

Anatomy of the bot: what it takes to operate like this

To reproduce what we see in the data, an operator needs:

1. Real-time monitoring of all Tether multisig signer addresses — ideally via a private mempool (for speed and to avoid being front-run themselves). On ETH that's 6 addresses, on Tron — 3.
2. An on-the-fly multisig-transaction payload decoder: pull transactions(uint256) via eth_call and recognize addBlackList(addr) to learn which target address will be in the window.
3. A pre-held private key or signed transaction template for each "potentially at risk" address. Precisely because the bot fires with a one-ETH-block-second reaction — there's no time to request a signature offline.
4. A pre-built transfer(...) transaction with aggressive gas to make it into the next block. On ETH it's a standard MEV setup. On Tron the logic is a bit more complex (energy/bandwidth + super-representatives), but reproducible.
5. Exit-layer infrastructure: pre-configured deposit channels at cross-chain bridges (Chainflip / Near Intents / Across / Synapse / etc.), pre-built DEX-swap templates (Uniswap V4 / SunSwap V3 / 1inch) to convert USDT → native asset in the very first hop, and optionally perp-trading accounts on Hyperliquid (via the Hyperunit bridge) for leveraged monetization. This is a separate architectural layer that turns the interceptor bot from "move USDT to the next fresh wallet" into "knock USDT out of the infrastructure on a blacklist signal." In this form the bot does not "outrun the multisig" — it moves into an asset to which destroy is inapplicable — on ETH via Chainflip + Uniswap V4 (Pattern 2 in the companion piece), on Tron via SunSwap (Pattern 3). Reaction speed here is not necessarily sub-second: a pre-configured Chainflip channel accepts USDT in the submit→execute window (hours-to-days), and even a manual operator with a pre-arranged setup works.

Architecturally this is an absolutely standard MEV setup at the level of base mechanics (you don't even need a private mempool — the Submission after the first confirm is already in a public block, and the final signature is still ~12–30 seconds away). The only question is the target and the exit layer: instead of ordinary arbitrage or liquidation, here the optimized scenario is "pull USDT before blacklist and exit the USDT infrastructure."

Destination clustering

Fig. 6 — Fragmented exit on Tron: 93 clean cases paid out to 272 distinct destinations — many independent operators, not one ring.

Fig. 7 — The opposite on Ethereum: a single node 0x414cf1… absorbed $30.95M from two different interceptions — a shared routing hub.

On Tron the destination graph is fragmented: across 93 clean post-period cases we have 272 unique destination addresses (over 353 outflow Transfers; some interceptions split into several small transfers). A few destinations received transactions from 2–8 different cases (top — TSUYvQ5tdd3DijCD1uGunGLpftHuSZ12sQ with 8 cases for $1.46M); the large Tron interceptions each have their own unique destination. So the Tron side looks like a multitude of mutually non-overlapping operators, each with its own circuit.

On ETH the picture is exactly the opposite. Across the clean post-period cases we have 14 addresses and far fewer unique destinations: one of them stands out sharply — 0x414cf116d546185911361782361fa541424c662a received $30.95M from two different interception cases (the July $27.12M from 0x928b8864... and one of the July $3.83M sister-series cases — 0xfFc99C05, B1). This is a shared routing node between two related interceptions: from there the funds went out via fresh hops, and BitOK's multi-hop AML attribution links part of the downstream to five addresses that Tether later blacklisted — and all five Tether destroyed in one batch on 6 April 2026 for $21.83M, plus the final pin 0xD29Ca88b ($3.83M) in the next block, $25.66M in total (see the sister-series breakdown above).

The full breakdown of all 1,163 outflow Transfers (over the wide drainer set, with source, date, amount, and explorer links) is in data/summary/drainer_destinations_full.csv; of those, the clean sample accounts for 70 ETH + 353 Tron = 423 events.

What must be said about attribution

It's tempting to explain the rise in interceptions with the direct logic "the 2025 research described the vulnerability → interceptors appeared." But this attribution survives careful scrutiny only as a correlation — in parallel, over the May 2025 — May 2026 window, a whole series of other things happened:

• T3 FCU reached industrial scale ($300M+ in frozen assets by October 2025);
• MiCA took effect (31 March 2025), pushing part of the "gray" activity off regulated venues toward OTC and gateways;
• Tether announced USAT (12 September 2025) and real-time blacklist publication (9 September 2025);
• the volume of public takedowns grew roughly 5–7×, which means larger and more "important" (from the bad actors' standpoint) targets entered the sample — targets worth building a bot for.

Which of these contributed more to the doubling/tripling of clean Tron interceptions and the appearance of large single ETH episodes — the data cannot separate. The correct phrasing is "in the year after publication, exploitation of the vulnerability rose sharply"; "the publication specifically launched it" is already a hypothesis, and it competes with the alternatives above.

That said, the shape of the growth itself (interceptions were already happening before publication; afterward they became more frequent, larger on average, and faster) fits well with the industrialization of already-existing window exploitation rather than the invention of a new technique. For that you don't need to posit a fundamentally new stack on the bots' side: maturation of automation around an already-known gap is enough, plus the fact that the setup cost became more justified against larger and more frequent targets. This doesn't separate the drivers (publication / T3 / MiCA / USAT / larger targets / their combination) — it just says that whatever factors drove the growth, the observed shape looks like infrastructural maturing, not a technological breakthrough.

---

Atomic destroy — the new pattern of 2025

After analyzing the exploitation of the vulnerability — a separate storyline on Tether's own side, which became a noticeable operational pattern precisely in 2025. It is completely unrelated to interceptor bots: the bot targets the window BEFORE addBlackList executes, whereas atomic destroy is about how Tether closes blacklisting and burning simultaneously, and it happens at the moment of the final confirm. Different operational scenarios, different cases, different addresses. There's a second storyline unfolding in parallel — on Tether's own side: its workflow has also been evolving over the past year, and atomic destroy is the most noticeable operational change.

In the normal Tether workflow, destroyBlackFunds arrives days-to-weeks after addBlackList: first a separate multisig chain blacklists the address, then another multisig chain initiates the burn. Starting in 2025 a second pattern appeared: addBlackList and destroyBlackFunds are bundled into a single block.

Technically destroyBlackFunds requires that the address already be blacklisted (require(isBlackListed[user])), so formally the burn cannot happen BEFORE addBlackList executes. But within one block, addBlackList executes first (lower logIndex), then — 2–3 events later — destroyBlackFunds (higher logIndex). That is, Tether submits two different txIds to the multisig at the same time (one for blacklist, the second for destroy), and both final signatures land in one block:

block N:
   tx_index K     addBlackList(addr)         → AddedBlackList event       (logIndex N)
   tx_index K+1   <multisig housekeeping>    → ...                        (logIndex N+1, +2)
   tx_index K+2   destroyBlackFunds(addr)    → DestroyedBlackFunds event  (logIndex N+3)

This is specifically a 2025 practice

At first it might seem this is just a standard Tether workflow feature that always existed. But if you pull AddedBlackList + DestroyedBlackFunds events across all of USDT-Ethereum's history (from the contract's deploy in November 2017 to today, ~20.4 million blocks) and search for same-block addBlackList+destroyBlackFunds pairs for a single address — isolated cases exist since 2020, but it became a mass operational pattern specifically in 2025:

Table 9 — Atomic destroy is a 2025 phenomenon: just 4 pairs / $1.78M across all of 2017–2024, then 7 pairs / $32.0M in 2025 alone.

Over 8 years (2017–2024) — just 4 atomic pairs for $1.78M, all small. In 2025 — 7 pairs for $32M at once, with one case (the GAIB-related $31.77M of 8 November 2025) accounting for almost all the value. The full list of 12 historical pairs is in data/eth_atomic_pairs_history.csv.

ETH vs Tron asymmetry

In our 24-month window:

On Tron this pattern is essentially unused — all Tron destroys go through the normal workflow (a separate multisig chain days after the blacklist). The probable reason: the Tron multisig is 2-of-3, the threshold is lower, the wait window is shorter, and burning after the fact is safe enough. On ETH the multisig is 3-of-6 — the window is longer, and for large seize operations it makes sense to bundle.

What atomic destroy actually provides

• operational speed — one joint operation instead of two sequential multisig chains; days of waiting become a single block;
• a guarantee for law enforcement — when it's known in advance that there will be a seize in someone's favor (USSS, DOJ, OFAC), LE wants the blacklisting to be immediately followed by a burn (with subsequent reissuance of tokens to their wallet). Atomicity removes the risk that, between blacklist and destroy, a signer changes their mind or a stray removeBlackList gets submitted;
• operational cleanliness for small dust cases — a separate subcategory where Tether closes small leftovers in one move instead of two (see below).

8 ETH cases: one big and seven small

The eight ETH cases of 2025–2026 should be read as two different storylines:

Storyline 1: one large case, structurally resembling a coordinated seize. The case of 8 November 2025 for $31.77M. The target address is the AIDAlphaWithdraw contract of the GAIB protocol (a DeFi protocol of AI stablecoins AID/sAID, after $200M+ of pre-deposits in a pre-launch campaign). The chronology around this case is curious:

• 7 November 2025 — GAIB officially opens the withdrawal portal for AID Alpha users (a two-week window).
• 8 November 2025 — Tether atomically blacklists and burns $31.77M USDT inside AIDAlphaWithdraw.
• 21 November 2025 — the portal closes, the protocol migrates to new AID/sAID contracts.

Coincidence or not — without a public explanation from GAIB or Tether, one cannot say. Structurally the picture looks like a coordinated seize: per BitOK's AML overview³, the $31.77M in AIDAlphaWithdraw had an institutional inflow profile (Binance — 73%, then Bitfinex 5%, VALR 4%, Aave 3%, CoW Protocol 2%, OKX 1%); a plausible scenario is that the funds of one or two specific depositors were flagged by sanctions/FATF, and Tether with an LE partner seized exactly those by targeting AIDAlphaWithdraw (since those users' USDT effectively sat on the contract). The alternative is a contract compromise or its use for laundering. Neither version is publicly confirmed or refuted; for the article what matters is the very existence of the $31.77M atomic destroy pattern, which previously appeared only in the context of coordinated seize operations. The legal nature of the GAIB case specifically remains in "structurally consistent" mode.

Storyline 2: seven small dust cases. The other 7 ETH atomic pairs are amounts of $1.4k – $100k, averaging $37k per address. Structurally this resembles not coordinated LE operations (sub-$30M+ public takedowns are usually bundled separately via T3 FCU) but administrative dust cleanup: Tether noticed that some blacklisted cluster has a leftover on an address and, to save multisig operations, ran addBlackList + destroyBlackFunds in a single pass. The weight of such cases for the overall picture is microscopic — $0.26M against $31.77M for GAIB.

In other words: the new "atomic destroy" pattern appeared specifically in 2025, but behind the term sit two different phenomena — (1) a single $31.77M storyline, structurally consistent with a coordinated seize (without public legal confirmation), and (2) a series of small housekeeping cases that, without GAIB, add up to no narrative at all. Merging them into a combined "$32M of LE coordination" figure would be an exaggeration — the defensible narrative here is specifically about GAIB.

Overall in the post-period, the large public T3 FCU takedowns (January 2025 — $182M Tron, June 2025 — $225M DOJ, February 2026 — $544M Turkey, April 2026 — $344M Iran) go either through a direct transferFrom/reissuance or through the regular non-atomic workflow. The atomic pattern is apparently a separate tool that Tether applies selectively: for the GAIB scenario it was needed, for most others it wasn't.

---

What this means for Tether

Has the window vulnerability become less dangerous over the past year? In the sense of "partly — yes," in the sense of "architecturally — no."

This is not simply a race against ever-faster bots. The data looks more like a structural equilibrium: Tether already demonstrates the capability to compress the window to seconds in urgent series, but the routine workflow still leaves a public pending window; over the year the bot side turned already-existing exploitation of that window into industrial infrastructure. As long as the gap remains the default, future large targets will be served by the same infrastructure even if the median window keeps shrinking. The durable fix is not to keep chasing faster each time, but to remove the public gap.

To give an overall assessment, let's first look at the most aggregate picture — where the targeted USDT that Tether aimed to blacklist actually goes, and how that picture changed over the year.

Where the targeted USDT goes

Let's sum the balances of all addresses at the moment of submit (this is the "target" — what the blacklisting was aimed at) and trace the fate of each part up to today. We get six categories:

• still in blacklist — frozen, no post-execute actions taken;
• unfrozen — Tether later called removeBlackList for the address;
• destroyed later — Tether called destroyBlackFunds days/weeks after the blacklisting (the normal workflow);
• destroyed atomically — destroyBlackFunds in the same block as addBlackList (Section 7);
• intercepted in window (clean) — an interceptor bot pulled out ≥95% of the original balance before the multisig's final signature, and the address remained emptied (Section 6);
• other in-window outflow — all other fund movement in the window: borderline interception cases (racing/partial/weak), small housekeeping traffic, etc.

The sum of these six ≈ bal_sub (the original balance of the targets at the moment of submission). A small overcount of $3–4M on Tron is intra-window inflows that the bot pulled out together with the original balance; formally they arrive at the address inside the already-open window, so they don't fit the decomposition by bal_sub (see data/summary/lifecycle_extra_inflows.csv).

Tron

Fig. 8 — On Tron, in-window interception rose from 1.2% to 3.9% of targeted USDT ($75.3M); the 86.9% "still frozen" share is inflated by fresh LE operations not yet burned (recency).

What stands out:

• The "still in blacklist" share grew from 73% to 87% — at first glance it looks like Tether more often leaves addresses frozen without burning. In reality this is mostly a recency effect (see below).
• "Unfrozen" — stably low (5% → 3%), as on ETH.
• "Destroyed later" fell in relative share (20.2% → 5.9%) — again recency: the fresh large takedowns haven't yet had time to go through the destroy cycle.
• "Intercepted in window (clean)" grew from 1.2% to 3.9% in relative share, 5.6× in absolute numbers ($13.39M → $75.25M), and 1.9× by number of addresses (49 → 93).

Recency caveat for Tron. destroyBlackFunds in the normal Tron workflow arrives days-to-weeks after addBlackList. So fresh blacklistings in our sample physically haven't had time to enter the "destroyed later" category. And it's precisely the last months of the post-period that are packed with large LE operations: January 2026 — $461M (including the $182M Tron operation), April 2026 — $457M (including $344M Iran). These sums currently sit in "still in blacklist," but in a couple of quarters part of them will move to "destroyed later." If you control for the age of the blacklisting (taking only records older than 6 months), the picture becomes more symmetric:⁴

Table 10 — Controlling for blacklisting age, the post-period destroy rate is no lower than the pre (42.3% vs 31.8% in the 12–18-month bucket): Tether did not slow destroyBlackFunds — the "86.9% frozen" headline is a recency artifact.

In the comparable 12-18-month bucket, the destroy rate in the post-period is even higher than in the pre (42.3% vs 31.8%). That is, Tether did not slow destroy on Tron — if anything, it sped it up. And the apparent "86.9% still frozen" summary is an artifact of the post-period having disproportionately many fresh LE operations that haven't yet reached the destroy phase.

Ethereum

Fig. 9 — On Ethereum, ~1 in 5 targeted dollars did not stay frozen after publication: $52.4M intercepted (13%) plus $31.9M atomic-destroyed (8%), while "unfrozen" collapsed 18.8% → 1.2%.

Key shifts:

• "Unfrozen" collapsed from 18.8% to 1.2% ($90.6M → $5.0M). In the post-period Tether practically stopped returning addresses to circulation — this aligns with BlockSec's independent estimates (3.6% removal rate in 2025).
• "Destroyed atomically" appeared out of nothing ($0.08M → $31.94M, of which $31.77M is the single GAIB case; see Section 7 on atomic destroy).
• "Intercepted in window (clean)" grew 7× ($7.48M → $52.38M). The number of clean cases barely changed (13 → 14), but the average drain size grew from $0.58M to $3.74M.

That is, every fifth dollar of USDT that Tether aimed to blacklist after the publication did not stay quietly frozen on the address: something was yanked by an interceptor bot ($52.4M), something Tether destroyed atomically ($31.9M), something left otherwise ($5.6M).

The recency caveat applies to Ethereum too: the post-period includes the last months of 2026, in which blacklistings haven't had time to go to destroyBlackFunds — so "still in blacklist" here is also partly overstated in the long run, and part of these sums should move to "destroyed later" within 6–12 months. The ETH sample is smaller and less skewed toward fresh large LE operations, so the recency effect on ETH is milder than on Tron.

Deposits to already-blacklisted addresses (above-stack)

Beyond the money sitting on the address at the moment of submit (this is "targeted" in the tables above), there's a separate persistent flow: USDT arrives at the address after the blacklisting has executed and the address is on the public isBlackListed list. A transfer from a blacklisted sender can't be done on such inflows (the contract reverts), and at the next destroyBlackFunds Tether burns whatever accumulated:

Table 11 — Senders keep paying frozen addresses: $65.7M USDT landed on 463 already-blacklisted addresses and was later burned — $36.7M on Tron even after Tether's September 2025 real-time disclosure.

That is, over two years Tether burned $65.7M USDT that landed on 463 unique addresses AFTER they were already blacklisted. This is money that senders sent with their own hands to addresses on Tether's public blacklist — whether out of ignorance (an old memo, a cached AML feed, a stale watchlist) or because deposits flow through an automated system that doesn't check the blacklist on every transfer. This sum is not part of the targeted decomposition above — it's a separate above-stack metric. And it vividly shows that real-time publication of blacklistings (announced by Tether in September 2025) is useful but does not automatically solve the "blind sender" problem: on Tron post-period, $36.7M went up in smoke after the announcement.

The source is data/summary/lifecycle_extra_inflows.csv. The same table has an adjacent metric, intra_window_inflow_drained ($7.31M total over two years) — these are inflows that arrived at the address inside the already-open blacklisting window and were immediately pulled out by the interceptor bot together with the original balance.

The cumulative picture over time

The cumulative lifecycle charts make this arithmetic especially clear. Before the publication the yellow "unfrozen" sector was noticeable; afterward it almost vanished; the red "interception" sector appeared exactly at the moment of publication; the purple "atomic destroy" sector appeared out of nothing (one large GAIB case plus a series of small ones).

Fig. 10 — The red "interception" band opens at the publication date and keeps widening through the post-period.

Fig. 11 — Post-publication on Ethereum: the "unfrozen" band nearly vanishes while the "atomic destroy" band appears from nothing (the GAIB case).

What improved

• The median confirmation speed shortened by almost half on Ethereum and by a quarter on Tron.
• An observable "urgent mode" appeared, with a window of tens of seconds for urgent takedowns (probably under law-enforcement coordination).
• Blacklisting volumes grew (especially on Tron), and destroyBlackFunds came to be used significantly more often and at larger sizes. Over 2025, Tether (via T3 FCU and directly) became one of the largest publicly observable on-chain enforcement instruments among stablecoin issuers — with $1.26B frozen and $300M+ of international takedowns in the T3 statistics alone.
• A new operational pattern appeared — atomic addBlackList + destroyBlackFunds in a single block. One genuinely large case (GAIB, $31.77M) looks like an LE-coordinated seize; the other seven are small dust cleanup. So Tether applies the atomic tool selectively, not as a standard for all LE operations.
• Tether announced public real-time visibility of blacklistings (9 September 2025), which in theory gives third-party AML services a chance to react earlier.

What stayed the same

• The hole itself — the public visibility of submitTransaction hours before execution — hasn't gone anywhere. The contract scheme is the same; Tether has not yet promised anything "atomically pre-signed."
• The multisigs 0xC6CDe... and TBPxhVA... physically did not change: 6/3 on ETH, 3/2 on Tron, not a single OwnerAddition/OwnerRemoval/RequirementChange over 24 months. The threshold was not lowered. No "pre-signed freeze pool" mechanism appeared (where signatures are prepared in advance and pushed atomically) — we found only empirical series of "fast takedowns" in a sub-minute window, explainable by ad-hoc off-chain coordination.
• The window's tail on Tron got worse during spikes, not better.
• Across the post-period in total, gross outflow on clean cases was $127.6M USDT ($52.4M ETH + $75.3M TRX, 107 blacklisting events) — 6.1× more than the pre-period ($20.9M, 62 addresses) and more than 4× all the documented exploits in the original 2025 article. This sum is gross over blacklisting events (not deduplicated by unique principal): on certain clusters (see the sister series of 28–29 July 2025 in the breakdown) gross substantially exceeds the unique principal — in that series gross $19.14M against direct $3.83–7.66M. Another ≈$51M in borderline cases (racing/partial/weak) is moved into appendices for AML review — the full estimate by definition strictness may be higher, by deduplication strictness — lower.
• On Tron interceptions existed before the publication too (×5.6 in dollars on a base of $13.4M); on ETH the ×7.0 growth is formally larger but heavily outlier-driven — the top-1 case gives 51% of the post, the top-7 = 89%. Without the top-1, ETH post = $25M; without the top-7 — less than pre.
• The minimum lead over the multisig's last signature on the clean sample is 24 seconds on ETH (2 blocks) and 105 seconds on Tron (35 blocks). On the wider drainer set with racing cases, a 3-second (1-block) minimum appears on Tron — that's already the MEV zone, and it existed on Tron since at least 2024.
• The loudest single episodes of the post-period: $37.30M in 120 seconds (Tron, 5 June 2025) and $27.12M in 528 seconds (ETH, 26 July 2025) — neither has an analog in the pre-period.

What should be done architecturally

The 2025 research's recommendation still stands: as long as the mechanism for adding an address to the blacklist remains visible in the mempool/block hours (and sometimes tens of seconds) before the actual freeze, big money will leave in that window — even if the median speeds up. Interceptors are a solution that is technically invariant to window length: they don't care whether the multisig waits 3 hours or 30 seconds; what matters is that between "submit + 1st confirm" and "threshold confirm" there is at least one block in which they can insert their transfer.

The only real technical solutions:

1. Atomic execution of addBlackList in a single transaction with the initial submission (e.g., via off-chain signature collection and one on-chain transaction with ready ECDSA signatures). Technically this is a variant of the EIP-712 / Safe "atomic execute" that fully eliminates the window.
2. Private (off-chain) signature coordination landing in a single block without public visibility — e.g., via a Flashbots bundle on ETH or a direct channel to super-representatives on Tron.
3. An alternative "emergency contract" with a single signer (or with a pre-built multisig bundle) for urgent cases — separate from the normal workflow.

So far none of these solutions is implemented. If Tether develops a formalized fast lane (and not just empirical series of fast blacklistings), that will be the first real architectural move worth paying attention to.

A regulatory dimension

USDT freezing is no longer a niche compliance tool — it is a channel the DOJ, OFAC, the Secret Service, and the FBI now rely on, institutionalized across 23+ jurisdictions through the T3 FCU. A public pending window in an instrument of that standing is therefore not only Tether's operational risk but a question for the stablecoin-regulation debate now underway — the GENIUS Act framework and Tether's own GENIUS-regulated USAT included. We deliberately stop short of forecasting a dollar figure for the next large target: the gross-vs-principal caveats above would make any single extrapolated number more misleading than informative. The structural point stands on its own — as long as the default workflow leaves the public gap open, the next large targets will be served by the same interception infrastructure even if the median window keeps shrinking.

---

Reproducibility: data and scripts

The full research dataset — raw blacklisting events, decoded multisig payloads, balances, summary tables — together with all pipeline scripts and a provenance file map is in the open repository on GitHub. It also contains a README with run-it-yourself instructions, docs/NUMBERS.md (an "every number -> source + formula" map), and a data dictionary at data/summary/README.md. Node access keys (NowNodes, QuickNode, TronGrid) are not committed — a .env.example template is included.

All numbers in this article come directly from a single run of the scripts in scripts/. The comparison window and contracts are the same as in the May 2025 research. The "drained" heuristic was reworked: instead of a balance-based threshold (balance < 20 USDT or balance < 5% of starting balance), we moved to volume-based bucketing — out_share = outflow / bal_sub and bal_remain = bal_exe / bal_sub with five buckets (clean / racing / partial / weak / noise). The headline in the article is clean cases only (out_share ≥ 95% AND bal_remain ≤ 5%), which is stricter than the original heuristic; the other four buckets are materialized as separate CSVs for individual review.

---

If you have factual corrections, errors, or methodology questions — you can open an issue in the repository or write to pr@bitok.org. All CSV exports and scripts are public — we'd be glad if someone independently re-checked our numbers.