EIP-7702 is not the main cause of Binance's $6.3 billion theft; how the signature was obtained is.

Beijing time, October 30, 2026, 04:24.

On-chain records show the money went out from 0x28C6…1d60. This address is called Binance 14, one of Binance's largest Ethereum hot wallets, which sends out thousands of withdrawals a day. This transaction moved 167,464 ETH, $1.615 billion USDT, plus over 60 types of tokens, worth approximately $2.5 billion at the time. The wallet was left with 1 ETH.

The gas fee was 0.0004 ETH, less than $1.

Three minutes earlier, at 04:21, someone submitted an EIP-7702 type transaction to it, stuffed with 50 authorizations, with nonces ranging from 18,914,775 to 18,914,824. 49 were invalid, 1 hit. A hit means: from this second on, any call to Binance 14 executes the contract deployed by the attacker at 23:59 the previous night—an unverified sweeper with only one sweep function.

So Binance 14 is no longer a wallet. It became a shell containing someone else's program.

By 08:06 the delegation was still there. 3 hours 45 minutes, and no one revoked it.

And "revoking" this thing only requires the same key to sign once more. At 06:55 that morning, Binance was still using this key to transfer the scattered tokens that hadn't been swept back to its own wallet.

Is EIP-7702 the main cause of the attack

The logic of EIP-7702 is this: allow an ordinary address (EOA) to rent the code of a smart contract, with the address, balance, and private key all unchanged. The way to rent is to write 23 bytes into the code field of this address—0xef0100 plus the contract address. These 23 bytes are not executable code; they are a pointer. From then on, whoever calls this address, the EVM loads the code pointed to by the pointer and executes it in this address's own context: address(this) is still itself, the balance is still its balance.

It has no bug. Derek Chiang, founder of ZeroDev and a participant in EIP-7702, was direct in his statement on the day of the incident: EIP-7702 itself has no vulnerability, and wallet users who support this standard need not panic. He added one more thing: for an attacker to use 7702, they must either control the private key or trick Binance into signing a 7702 authorization.

It is also not the first time it has been used as an attack tool. After Ethereum's Pectra upgrade, Wintermute discovered within weeks that over 97% of 7702 delegations on the mainnet pointed to nearly the same "sweeper" contract; research has tallied approximately 3.66 million authorization transactions, of which about 63% were related to malicious contracts, with confirmed losses of $2.3 million; Blockaid verified four 7702 incidents in the first half of 2026, totaling approximately $1.08 million, and predicted that the first seven-figure case would occur within the year.

The result came in at ten figures, three orders of magnitude higher than their estimate.

This has led many to attribute the cause of Binance's $5.6 billion hack—the largest in human history—to EIP-7702. But is it really a 7702 problem?

How the Signatures Were Obtained

Before going further, one thing needs to be made clear: 50 authorizations means 50 signatures—so how exactly were those 50 signatures produced?

If the attacker had obtained the full private keys, why would he need to blind-snipe 50 nonces? If the keys had always been in Binance's hands, why did 11 wallets fall simultaneously within 12 minutes? There is still no explanation.

Twenty-four seconds after the main sweep, Binance 16 transferred out 28,005.6 ETH, $55.7 million USDT, $25.9 million RLUSD, and 84.5 WBTC, all to the same receiving address.

Within 12 minutes, another 10 Binance hot wallets did the same thing across four chains: Binance 55 on Optimism transferred out $44.2 million OP; four wallets on Arbitrum transferred out $74.6 million ARB and 8,426 ETH; four wallets on Avalanche transferred out 1.81 million AVAX and $8.41 million USDT.

None of these wallets contained any code. Every transaction was an ordinary transfer, signed by the wallet's own private key, sandwiched between routine withdrawals.

Someone who holds the private keys does not need to blind-snipe nonces. Checking eth_getTransactionCount takes one second.

The kind of person who needs to construct 50 authorizations covering 50 consecutive nonces in one go is a different kind of person: someone who can obtain signatures but cannot access the wallet's real-time state; or someone who can only submit a batch of pre-assembled authorizations all at once and let the system try them.

More notably, these 50 authorizations were approved all at once in a single transaction.

Security firm Blockaid's assessment is that "the key was misused" rather than the private key being directly extracted. Yuga Labs VP of Blockchain Quit also leans toward this direction: what the attacker obtained was "authorized signatures," not the private key, and using a relayer to submit may have been precisely to obscure the source of the signatures.

Shenyu mentioned a detail in his morning recap: until 06:55, Binance was still using the same private key to sign, transferring fragment tokens that hadn't been swept back to its own wallet.

This indicates that the key was still under Binance's control that morning.

Just now at 10:26, Binance gave its preliminary account: a DevOps engineer's laptop may have been compromised, through which the attacker gained access to service containers and submitted unauthorized withdrawal transactions; currently no evidence of wallet private key leakage has been found.

The Second It Was Lost Was Not On-Chain

So the core issue is not EIP-7702, but the segment before signing.

A hot wallet signs thousands of transactions a day, so it must be automated; it must be secure, so it needs HSMs, MPC, multi-sig, and approval flows. Thus the entire security model compresses into one sentence: can this process determine, before signing, that "this transaction should not be signed"?

The problem is that most judgment criteria only have two columns: amount and address.

7702 authorization has neither. It has no amount. What it changes is not "how much to transfer" but "what this address is."

It's not that Binance wasn't defending.

Three days before the incident, on October 27, it proactively disclosed something worth noting: over the past week, the security team had intercepted multiple North Korea-related attacks. The method is called Contagious Interview—the other party poses as a recruiter, using interviews, coding tests, and "just install a dev tool first" to trick people into running malicious programs; once the program runs, keys, internal networks, and subsequent fund movement all have an entry point.

But it failed to prevent "should this transaction be signed."