The Binance hack's Ethereum leg used EIP-7702 with 50 pre-signed authorizations. Here's how it worked and why 7702 isn't the real culprit

While most of the coverage is about the $6.3B headline, the mechanics on Ethereum deserve their own thread. Based on TRM Labs' write-up:

What happened on-chain

1. At 20:20 UTC the attacker submitted a single transaction containing 50 EIP-7702 authorizations, all signed by a Binance hot wallet, each pointing it at a sweeper contract that only accepts calls from the attacker's operator.
2. Why 50? A 7702 authorization is only valid at the wallet's current nonce. A busy exchange hot wallet's nonce keeps moving with every withdrawal, so they pre-signed 50 consecutive nonces to guarantee one would still match at execution. One did.
3. 3 minutes 24 seconds later, the operator told the now-delegated hot wallet to send everything: 167,464 ETH + 63 tokens including 1.615B USDT, in one tx.
4. The delegation stayed in place, so every new deposit landing in that hot wallet got swept again at 20:41, 20:59, 21:04, 21:44, 22:39 and 23:56 UTC.
5. The same wallet was also the executor on a separate Binance smart account, which let them pull 823M USDC (Circle froze it shortly after).

Prep started ~36 hours earlier: small Tornado Cash withdrawals funded the operator wallet, and the sweeper was test-deployed and rehearsed on three wallets before the real run.

Why 7702 isn't the root cause

In the same ~30-minute window, Binance wallets on Bitcoin, Tron, XRP Ledger, Solana, Arbitrum, Optimism, Base, Avalanche and Polygon all sent funds to the attacker through ordinary signed transfers. Another Binance ETH hot wallet sent 28K ETH with no delegation at all. Different chains, key types and signing schemes, all producing valid signatures on demand. TRM's read is that the attacker could make Binance's signing system sign whatever it wanted. Binance's own statement says a compromised DevOps engineer's laptop led to a service container that submitted unauthorized withdrawals, and that no private key leaked.

So 7702 didn't create the breach. It made the Ethereum side faster and persistent: one batch of signatures bought hours of automatic re-sweeping.

Questions for the sub

• Should signers and custody policies reject 7702 authorizations by default unless explicitly expected, especially a batch spanning a range of nonces?
• Is anyone monitoring EOAs for unexpected delegation code? It's trivial to detect (code appears at an address that should have none), but I doubt most treasuries alert on it.
• Does this change how you think about 7702 for exchange or treasury wallets at all, or is it just "compromised signer is compromised signer"?

Source: TRM Labs blog on the Binance hack (Oct 29, 2026).