Binance drain, the TRON leg: USDT frozen in 46 minutes, and the deposit-receipt route around the freeze

Rewritten for readability on 8 Nov 2026 (figures are as of the original date).

1. What happened

On 29 October 2026, assets were drained from several "hot wallets" (the online wallets an exchange uses for day-to-day withdrawals) at the crypto exchange Binance. The previous post covered the Ethereum side. The same night, funds also left the TRON hot wallet "Binance-Hot 7".

On TRON, 378.7M USDT ended up frozen in two addresses. This post explains what happened around those freezes, and the "deposit receipt" route that was tried to get around them.

2. A few terms first

• USDT and freezing: USDT is a token built to keep the same value as the US dollar (a stablecoin). Its issuer, Tether, can stop USDT at a given address from moving (freeze it). TRX, TRON's own currency, cannot be frozen by anyone.
• Lending and receipt tokens: A lending service lets you deposit assets and earn interest; on TRON, JustLend is widely used. Deposit USDT and you get a token such as jUSDT back as a "receipt". Whoever holds the receipt can withdraw the deposited USDT.
• DEX (decentralised exchange): A way to swap crypto assets through an on-chain program rather than through an exchange company.
• Hop: A step in a chain of transfers. Whoever receives directly from the attacker is hop one; whoever receives from them is hop two.
• Base58 addresses: The way TRON writes addresses. They are case-sensitive. An Ethereum address still means the same thing in lowercase; doing the same on TRON produces a different address.

3. Following the money in order

The times below come from the TRON ledger and Tether's freeze records (UTC, 29 October). The addresses involved are called "Address A to C" and "the hub" by their role (the actual addresses are on the incident page).

1. 20:20:00 A 10,000 TRX test transfer from Binance-Hot 7 to a freshly created Address A, followed by 46,394,098 TRX.
2. 20:22:45 612,729,468 USDT to the same Address A.
3. From 20:45:51 Address A moves 300,000,000 USDT to Address B in three tranches.
4. 21:09:12 Tether freezes Address A, 46 min 27 s after the drain. The remaining 312.7M USDT can no longer move.
5. 21:14 Address B deposits 10,000 USDT into JustLend and receives 918,238.74 jUSDT receipt tokens in the same transaction.
6. 21:16 65,990,000 USDT from Address B to a freshly created Address C.
7. 21:21:12 Tether freezes Address C, about five minutes after it was funded. All of it is frozen.
8. 00:06 the next day 46,383,069 TRX goes to a TRX hub. TRX obtained by selling USDT on a DEX also arrives there, as three transfers of 120,000,000 TRX. The hub then sends it out in more than 800 transfers of 15–32M TRX each.

The 300M USDT that moved before the freeze went here:

4. Getting around a freeze with a deposit receipt

Tether can freeze USDT address by address. But once USDT is deposited into JustLend, what you hold is no longer USDT but a receipt token. The receipt is issued by the lending program, outside Tether's control, so Tether cannot freeze it.

Send that receipt to a new wallet and withdraw there, and the withdrawing wallet holds USDT at a "clean" address that is not on any blacklist. Read against the timeline above, 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 works against tracers too. Stolen-fund tracing normally follows currencies such as TRX and the major stablecoins. If receipt transfers are dismissed as "other tokens of unknown price", the trail breaks right there.

5. What ChainAnalyzer now follows

(1) Stolen-fund tracing on TRON

The tracer that follows outflows from attacker addresses in the incident database (the "labels showing where stolen funds arrived" from the previous post) now runs on TRON as well as Ethereum.

• TRON addresses are case-sensitive, so they are never lowercased the way Ethereum addresses are.
• Transfers are fetched oldest-first within a time window starting from when the funds became tainted.
• Attacker addresses attract large amounts of address-poisoning spam (look-alike addresses slipped into the history to provoke mistaken transfers). Outgoing and incoming transfers are therefore fetched separately, so the outgoing list can never be pushed out by spam.

The incident page (binance-2026) now lists the TRON victim wallet, the first receiver, the consolidation hubs, the frozen receiver and the TRX senders. The first pass recorded 169 addresses at hop one and more than 800 at hop two.

(2) Receipts as value

When a traced address, in one transaction, sends a stablecoin out and receives exactly one other token back, that token is learned as "something carrying this incident's value". The rate is "dollars sent ÷ tokens received"; nothing is fixed in advance. From the test deposit, 1 jUSDT ≈ 0.0109 USD was learned.

From then on, whoever receives that token is recorded as a recipient one hop out, with the amount converted to dollars, and above the threshold is also registered in ScamDB (our database of malicious addresses).

• Only the attacker's own outgoing transactions are used for learning. Airdrops or spam tokens that merely arrive can never qualify.
• If two or more tokens are received in one transaction, it is unclear which one counts, so nothing is learned.
• A DEX swap has the same shape, so tokens received in a swap are learned at the rate of that swap. For tokens whose price moves the conversion can drift, so the record keeps amounts converted via receipts and similar tokens in a separate column.

(3) TRON exchange hot wallets, and tracing depth

When stolen funds reach a known exchange, the incident page shows the exchange name, not the address. Many TRON exchange hot wallets are missing from our registry, so we filled the gap with the public address tags of TRON's canonical explorer (a site for viewing transaction records). Addresses identified as exchanges count as "reached an exchange", and DEX and bridge contracts are excluded.

Tracing depth went from two hops to three. Most depositing wallets appear at hop two, and stopping there hides both the receipt learning and what happens next. Hop-three addresses are only recorded and are never registered in ScamDB; the line that keeps unrelated people out is unchanged.

6. What the chain shows about scale

We counted USDT deposits into JustLend from the drain at 20:00 UTC on 29 October to 13:30 UTC on 31 October.

The six wallets share one route: they received TRX peeled off the attacker's hub, swapped it to USDT on a DEX and deposited it into lending. TRX → DEX → USDT → receipt, four steps in about a day. The other fifteen are either funded from further away or unrelated, and cannot be tied to the drain from on-chain records, so they are not counted.

7. Time to freeze

Forty-six minutes on TRON is not slow. Even so, 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.

8. How we checked

• Times in the flow come from the TRON ledger and Tether's freeze records.
• Time to freeze is computed mechanically from the block time of the freeze records, and matches the freeze-latency card on the incident page.
• The receipt rate comes from the attacker's own test deposit (the transaction that deposited 10,000 USDT and received 918,238.74 jUSDT).
• For scale, we counted JustLend USDT deposits over the period above, traced each wallet's TRX back through transfer records, and counted only those connected to the attacker's hub.

9. Follow-up

Later movements of the funds in this incident are covered here:

• The Solana leg (the same receipt hand-off pattern turned up with Jupiter Lend on Solana)
• The XRP leg
• The NEAR leg
• Two weeks on: a summary across all chains
• Incident page /hacks/binance-2026 (figures keep updating)