Binance drain, the Ethereum leg: how one transaction took 167,464 ETH and 64 tokens through an EIP-7702 delegation, and three checks we added

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 "hot wallets" (the online wallets an exchange uses for day-to-day withdrawals) at the crypto exchange Binance. This article covers the Ethereum part.

Reported losses ranged from $2.5B to $5.5B (as of 30 October). The ChainAnalyzer incident page only carries what can be verified on the public Ethereum ledger (the transaction record anyone can read).

2. A few terms first

• Private key and signature: The "key" only the wallet's owner holds. Only instructions signed with it count as that wallet's instructions.
• EIP-7702 and delegation: A newer Ethereum feature that lets an ordinary wallet "behave like this program (contract)". Setting it up needs a permission (an authorization) signed with the wallet's own private key. This article calls it delegation.
• Internal transaction: A transfer made from inside a program. Unlike a normal transfer, it does not appear in the plain list of transactions; you only see it by reading what the program did.
• Sweep: Sending a wallet's contents out to one place in a single go.
• Nonce: The running number of the transactions a wallet has sent. An instruction is only valid if it matches the current number.
• Freeze (blacklisting): For stablecoins such as USDT and USDC (tokens built to keep the same value as the US dollar), the issuer (Tether for USDT, Circle for USDC) can stop the funds at a given address from moving. Nobody can freeze ETH.

3. Following it in order

All times are UTC on 29 October.

1. 20:20:59 A transaction that sets up an EIP-7702 delegation (a SetCode transaction) is sent to Binance 14. It holds 50 authorizations, all pointing at a contract the attacker deployed that same day, with consecutive nonces.
2. 20:24:23 Through the delegated program, 167,464 ETH and 64 tokens are swept to the attacker's recipient as internal transactions.
3. 20:24:47 Another hot wallet, "Binance 16", also sends 28,005.6 ETH to the same recipient in a plain transfer.
4. 20:38:47 195,460 ETH is consolidated into a further address.
5. 21:01:35 Tether freezes the USDT recipient (37 minutes after the sweep), together with the two addresses that had received 700M USDT before the freeze.
6. 21:04:59 Circle freezes the USDC recipient (40 minutes). No USDC had left before the freeze.
7. From 22:06 Tether and Circle also freeze Binance 14 itself. This reads as a measure against a second sweep while the delegation was still live.

4. How could 65 assets leave in one go?

An ordinary wallet can only send one kind of asset per transfer. A delegated wallet runs the way its delegate program says, so if the program says "send all of these here", everything goes in one call. This sweep instruction listed 65 addresses: the zero address (0x000…0) at the front stood for ETH, and the other 64 for tokens.

But an 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. In other words, EIP-7702 was not the cause; it was the tool that let 65 assets leave in a single call.

There is a reason for 50 authorizations. An authorization is only valid if it matches the wallet's current nonce, and an exchange hot wallet sends several transactions per second, so its number keeps moving. Bundling 50 authorizations with consecutive nonces meant that one of them only had to match. The technique presupposes an exchange hot wallet as the target. The full walk-through is on the incident page.

5. Time to freeze

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 are the parts that answer that.

6. What ChainAnalyzer now follows

(1) EIP-7702 delegation detection (E23)

On EVM wallet scans, ChainAnalyzer checks whether the address is delegated. A delegated wallet holds 23 bytes of code starting with 0xef0100, which is how it is recognised. If it is delegated, the result shows the delegate contract and whether its code is published and verified.

Monitoring that only reads normal transactions misses transfers made through a delegated program, because they are internal transactions. ChainAnalyzer includes internal transactions in the check.

(2) Automatic updates of the USDT/USDC freeze ledger

A record that an issuer froze an address is the most reliable first-hand signal of where the issuer itself judged funds illicit. We used to collect these 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 (our database of malicious addresses). Releases from a freeze are tracked too, so a released address is not kept dangerous forever.

Scanning the recipient frozen on 29 October now shows "frozen by issuer" together with the freezing transaction.

(3) Labels showing where stolen funds arrived (hack exposure)

Starting from the attacker addresses registered in the incident database, ChainAnalyzer follows outgoing funds up to two steps (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 shows which incident's funds they touched, and at which step.

• DEX (decentralised exchange) 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.
• Step one is danger, step two is warn, and nothing beyond step two is followed. The cap exists so unrelated third parties are not swept in.

7. How we checked

• Times are taken from Ethereum block times.
• For the delegation, we read the list of authorizations (authorizationList) in the SetCode transaction (transaction type 0x4). Each entry carries (chainId, delegate address, nonce, signature); we checked that every entry points at the same contract and that the nonces are consecutive.
• We read the sweep including internal transactions. The 65 addresses passed to the sweep call 0x8a179be4(address recipient, address[] tokens) confirm ETH plus 64 tokens.
• Freeze times and targets come from the freeze records Tether and Circle left on-chain.

8. A side note: the attacker was targeted by address poisoning too

Minutes after the attacker's first test transfer, the test recipient started receiving zero-value transactions from other addresses sharing its first four characters. That is address poisoning (slipping look-alike addresses into someone's history to provoke a mistaken transfer), aimed at the attacker. ChainAnalyzer's poisoning detector fires on it just as it would if anyone else were targeted.

9. Follow-up

Later developments in this incident are covered here:

• The TRON leg (31 October; tracing depth was widened to three steps there)
• The Solana leg
• The XRP leg
• The NEAR leg
• Two weeks on: a summary across all chains
• Incident page /hacks/binance-2026 (figures keep updating)