Binance hot wallet drain: EIP-7702 delegation detection, an auto-updating USDT/USDC freeze ledger, and stolen-fund exposure labels
What happened, as far as the chain shows
Reported losses range from $2.5B to $5.5B. The incident page only carries what can be verified on the Ethereum ledger.
| UTC (29 Oct) | Event |
|---|---|
| 20:20:59 | EIP-7702 SetCode transaction addressed to Binance 14: 50 authorizations, all pointing at a contract the attacker deployed that day, with consecutive nonces |
| 20:24:23 | Sweep through the delegated code: 167,464 ETH and 64 tokens move as internal transactions to 0x5227…2f8c |
| 20:24:47 | 28,005.6 ETH leaves Binance 16 in a plain transfer to the same recipient |
| 20:38:47 | 195,460 ETH consolidated to 0x8532…43d4 |
| 21:01:35 | Tether blacklists the USDT recipient (37 minutes after the sweep), together with the two addresses that had received 700M USDT before the freeze |
| 21:04:59 | Circle blacklists the USDC recipient (40 minutes); no USDC had left before the freeze |
| from 22:06 | Tether and Circle also blacklist Binance 14 itself, which reads as a measure against a second sweep while the delegation was live |
An EIP-7702 authorization can only be signed with the wallet's own private key. Fifty valid signatures strongly indicate that the signing key was in the attacker's hands. EIP-7702 was not the cause; it was the tool that let 65 assets leave in one call. The full walk-through is on the incident page.
What this changes for investigators
After a large exchange drain, stolen funds are swapped, split and consolidated within hours and show up at other exchanges' deposit addresses the next day. The team screening those deposits needs two answers on the spot: has this address touched the 29 October funds, and has the issuer already frozen it. The three additions below exist to answer that.
1. EIP-7702 delegation detection (E23)
On EVM wallet scans, ChainAnalyzer checks whether the address's code is the 23-byte EIP-7702 designator starting with 0xef0100. If the wallet is delegated, the result shows the delegate contract and whether it is verified.
- An unverified delegate contract is HIGH. An exchange, issuer or custody wallet being delegated at all is abnormal.
- Delegation plus the sweep signature seen here, a large internal ETH transfer and many ERC-20 transfers to one recipient within a short window, escalates to CRITICAL with the transactions attached as evidence.
- A verified wallet implementation as delegate stays at LOW, informational only.
Monitoring that only reads normal transactions misses transfers made through delegated code, because they are internal transactions. ChainAnalyzer includes internal transactions in the check.
2. Automatic updates of the USDT/USDC freeze ledger
An issuer blacklisting an address is the most reliable first-hand signal that the issuer itself judged it illicit. ChainAnalyzer has collected freeze events mainly for yen stablecoins; from now on every covered token, including USDT and USDC on Ethereum, Polygon and Avalanche, is collected every six hours and frozen addresses flow into ScamDB. Un-blacklist events are tracked too, so a released address is not kept dangerous forever.
Scanning the recipient address frozen on 29 October now shows "frozen by issuer" with the freezing transaction.
3. Stolen-fund exposure labels (hack exposure)
Starting from the attacker addresses registered in the incident database, ChainAnalyzer follows outgoing funds up to two hops and registers receiving addresses in ScamDB as recipients of stolen funds. From then on, any wallet scan, REST API call or MCP query on those addresses reports which incident's funds they touched and at how many hops.
- DEX routers, bridges, known exchange hot wallets and token contracts are excluded.
- When stolen funds reach a known exchange, the incident page shows the exchange name, not the address.
- Hop 1 is
danger, hop 2 iswarn, and nothing beyond hop 2 is followed. The cap exists so unrelated third parties are not swept in.
Technical note: reading a SetCode transaction
Delegation happens in a type 0x4 transaction whose authorizationList carries (chainId, address, nonce, signature) tuples. An authorization is only valid for the wallet's current nonce, and a hot wallet that sends several transactions per second moves its nonce constantly. This transaction bundled 50 signatures with consecutive nonces so that one of them would match. The technique presupposes an exchange hot wallet as the target.
Once set, the wallet's code becomes the 23 bytes 0xef0100 plus the delegate address. The delegate's code runs in the wallet's own context, so the transfers are recorded as the wallet's transfers, but as internal transactions. The sweep call 0x8a179be4(address recipient, address[] tokens) listed 65 addresses, the zero address at the front standing for ETH.
One more observation: minutes after the attacker's first test transfer, the test recipient started receiving zero-value transactions from addresses sharing its first four characters. That is address poisoning aimed at the attacker, and ChainAnalyzer's poisoning detector fires on it as it would on anyone else.
The incident details and attacker addresses are public at /hacks/binance-2026. EIP-7702 detection is on for EVM wallet scans on every plan; the freeze ledger and exposure labels reach every plan, the REST API and MCP through ScamDB matching.