CV
Blog
binance
eip-7702
incident-analysis

The Binance Hack Ran Through EIP-7702. Here's the On-Chain Timeline

One transaction turned Binance 14 into a smart contract at 20:20:59 UTC on October 29. Three minutes and 24 seconds later it was empty. The verified timeline, what our monitor recorded, and what would actually have stopped it.

Duron Epps, Founder
9 min read
Share:X / TwitterLinkedIn

At 20:20:59 UTC on October 29, 2026, one Ethereum transaction turned Binance 14, one of the exchange's main hot wallets, into a smart contract. Three minutes and 24 seconds later the wallet was empty.

That's the part of the Binance incident you can check yourself, on-chain, right now. How the attacker got the signatures is still Binance's to explain, and its story has already changed once. This post sticks to what the chain shows, plus one thing our own monitoring recorded that I haven't seen reported anywhere else.

Status as of October 30, 2026: Binance hasn't published its post-mortem yet. Loss figures from different trackers range from $2.77B to $6.36B. I'll update this post when the official report is out.

The timeline, block by block

All times are UTC. Every transaction below is linked so you can verify it on Etherscan.

  • October 28: The address 0x7c8601d4645b93cea45f71e118a729332e6b5ca0 receives 0.1 ETH through Tornado Cash, according to CryptoTicker's reconstruction.

  • October 29, afternoon: That address deploys contract 0x63e842b054bd624a465454d533c33f573e9c6fae. Developer Alex M. reported that the contract only accepts calls from the address that deployed it.

  • 20:20:59: The attacker's address sends a type-4 transaction to Binance 14 carrying 50 EIP-7702 authorizations, every one of them pointing the wallet at 0x63e8…6fae (transaction). Crypto.news reports they cover 50 consecutive nonces, 18,914,775 to 18,914,824, most likely so that one would still be valid however many transactions the busy wallet sent in the meantime.

  • 20:24:23: The same address calls Binance 14, which now runs the attacker's code, and the wallet is drained in one transaction (transaction). Etherscan data cited by CryptoTicker shows 167,464 ETH and 1,615,409,499 USDT among 63 tokens taken.

  • 20:26: 28,005.6 ETH leaves Binance 16.

  • 21:18 and 21:25: Circle's Jeremy Allaire says more than 800 million USDC is frozen. Tether's Paolo Ardoino says more than 1.567 billion USDT is frozen.

  • 00:04 (October 30): Binance confirms the incident through Yi He.

  • 00:10:35: Binance 14 sends a type-4 transaction to itself authorizing address zero, which removes the delegation (transaction, block 26,301,896).

  • 02:23: Binance's update blames a compromised DevOps engineer's laptop that gave access to a service container, says it found no evidence of a private key leak, estimates about $6.3B affected and about $3B frozen, and says losses will be covered by its SAFU fund and company funds.

  • Later on October 30: Binance says the laptop explanation was incomplete and its investigation has found additional points of breach.

What EIP-7702 changed

Before Ethereum's Pectra upgrade in May 2025, a wallet like Binance 14 was just a key. It could sign transactions, and that was all. Its behavior couldn't change.

EIP-7702 lets that same wallet point its code at a smart contract with one signed authorization. After that, anyone the contract allows can make the wallet do whatever the contract says. That's how the attacker emptied a wallet holding billions without sending a single transaction from it: they called it, and the wallet's new code did the rest.

For a hot wallet, that means a new kind of risk. Watching for big outgoing transfers isn't enough any more. You also need to know the moment the wallet's code changes, because that change is the attack. The drain is just the cleanup.

What our monitor saw

I want to be precise here, because it would be easy to overclaim. We did not catch this attack. On the night of October 29 we were testing Contract Watch, our new on-chain monitor, and added Binance 14 to it around 23:55 UTC, three and a half hours after the drain, because it was the wallet everyone was talking about.

Its first snapshot showed the wallet's code as 0xef0100 followed by 63e842b054bd624a465454d533c33f573e9c6fae. That's an active EIP-7702 delegation to the attacker's contract, still in place long after the money was gone.

The checks a few minutes later still showed it. Then the check that ran right after 00:10 UTC came back with no code at all and raised an alert: the delegation had been removed. Looking back through the blocks, the change was Binance's revocation transaction at 00:10:35.

So the attacker's delegation stayed live for 3 hours and 49 minutes. If Alex M.'s reading of the contract is right, the attacker could have pulled anything that landed in Binance 14 during that window. I don't know whether anything did. But a delegation that outlives a drain by almost four hours is the kind of loose end that should page someone.

Would monitoring have stopped it?

No, and anyone who tells you their dashboard would have saved $6 billion is selling something.

The gap between the delegation and the drain was 204 seconds. Contract Watch checks every 5 minutes, so on a good night it might have alerted a minute before the money moved. On a bad one, a minute after. Even a perfect, instant alert gives a human about three minutes to understand what an EIP-7702 delegation is and do something about it.

What would have helped:

  • A hard rule that hot wallets never sign EIP-7702 authorizations. Whatever service signs for a hot wallet should refuse that message type outright. Exchanges have no business delegating their withdrawal wallets to contract code.

  • Velocity limits enforced outside the signing path. A hot wallet that can lose its whole balance in one transaction is a hot wallet holding too much.

  • Watching the setup, not just the theft. A Tornado-funded address deployed a contract that only it could call, hours before the attack, in public. That's a pattern worth a human look.

  • Alerts on code changes for every key you care about. They won't stop a 204-second attack, but they turn "we noticed when the trackers started posting" into "we knew within minutes, and we knew exactly what changed."

If you run a protocol or a treasury

  • List every hot key you control and check its code today. If eth_getCode returns anything other than 0x for an address you think is a plain wallet, find out why.

  • Get alerts on code changes for those wallets, plus ownership and admin changes on your contracts. Use whatever tool you like. We built Contract Watch for this, and it's free for one address.

  • Keep treasury funds in a Safe with a real threshold, and keep hot wallets thin.

If you're a Binance user

Binance says deposits are working normally and that it expects withdrawals to resume within about 48 hours. Scammers move fastest in moments like this. Treat any DM, email or "support agent" offering refunds, recovery or account verification as a scam, and only trust Binance's official channels.

I'll update this post when Binance publishes its technical post-mortem.

Sources

Published on
October 30, 2026