Binance drain, the TRON leg: a 46-minute freeze, the deposit-receipt escape, and tracing that follows receipts as value

What happened on TRON, as far as the chain shows

The previous post covered the EIP-7702 sweep on Ethereum. The same night, funds also left the TRON hot wallet "Binance-Hot 7". Every timestamp below comes from the TRON ledger and Tether's freeze events.

On TRON, 378.7M USDT ended up frozen in two addresses. Of the 300M USDT that moved before the freeze, 199M went to a swap contract, 33M to a DEX pool manager and 66M to the fresh address that was frozen five minutes later.

The deposit-receipt escape

Tether can freeze USDT per address. But when USDT is supplied to a lending protocol, the depositor receives a receipt token (jUSDT and the like). The receipt is issued by the protocol, not the issuer, so Tether cannot freeze it. Send the receipt to a new wallet, redeem there, and the redeeming wallet holds USDT at an address that is not on any blacklist.

Read against the timeline, the 10,000 USDT deposit at 21:14 looks like a test of exactly this route, five minutes after the first freeze at 21:09. The trick also defeats tracing: stolen-fund tracers follow native coins and major stablecoins, and if receipt-token transfers are dismissed as "other tokens of unknown price", the chain breaks right there.

1. Stolen-fund tracing on TRON

The tracer that follows outflows from the attacker addresses in the incident database (the "stolen-fund exposure labels" from the previous post) now runs on TRON as well as Ethereum. TRON addresses are base58 and case-sensitive, so the lowercase normalisation used for EVM would turn them into different addresses; the tracer handles that correctly and fetches transfers oldest-first from the contamination time. Attacker addresses attract heavy address-poisoning spam on the inbound side, so outbound and inbound transfers are fetched separately and the outbound page can never be pushed out by spam.

The binance-2026 incident now lists the TRON victim wallet, the primary receiver, the consolidation hubs, the frozen receiver and the TRX feeders. The first pass recorded 169 addresses at hop one and over 800 at hop two.

2. Deposit receipts as value

When a traced address sends a stablecoin out and receives exactly one other token in the same transaction, that token is learned as a value carrier for this incident. The rate is "USD sent ÷ tokens received"; nothing is hard-coded. From the test deposit above, 1 jUSDT ≈ 0.0109 USD was learned. From then on, transfers of that token are valued at the learned rate, the recipient is recorded one hop out, and above the threshold it is also registered in ScamDB.

• Only the attacker's own outbound transactions are used for learning. Inbound-only airdrops and spam tokens can never become carriers.
• If two or more tokens are received in the same transaction, the case is ambiguous and nothing is learned.
• A DEX swap has the same shape, so swap outputs are learned at the executed rate. For volatile tokens the valuation can drift; the ledger keeps the carrier-derived amount in its own column.

3. TRON exchange hot wallets and tracing depth

When stolen funds reach a known exchange, the incident page shows the exchange name, never the address. Many TRON exchange hot wallets are missing from our registry, so the tracer now consults the public address tags of TRON's canonical explorer: addresses tagged as exchanges count as exchange touchpoints, and DEX and bridge contracts are excluded.

Tracing depth goes from two hops to three. The depositing wallets mostly appear at hop two, and stopping there hides both the receipt learning and what happens next. Hop-three addresses are recorded in the ledger only and are never registered in ScamDB; the line that keeps uninvolved third parties out is unchanged.

What the chain shows about scale

Supply events on the lending protocol's USDT market, from the drain at 20:00 UTC on 29 October to 13:30 UTC on 31 October:

The six wallets share one route: TRX peeled off the attacker's hub, swapped to USDT on a DEX, supplied to lending. TRX → DEX → USDT → receipt, four hops in about a day. The other fifteen cannot be tied to the drain on-chain yet, either because the funding is further away or because they are unrelated, so they are not counted.

Time to freeze, from this incident's primary data

All values are computed mechanically from the block time of the freeze events and match the freeze-latency card on the incident page. Forty-six minutes on TRON is not slow, yet 300M USDT moved in that window and the receipt route was being tested five minutes after the freeze. A freeze stops the clock. It is not a recovery.