The Binance $6 Billion Heist: How the EIP-7702 Delegation Mechanism Was Used to Drain 11 Wallets

The original article comes from Web3 security company blockaid

Compiled by Quick Delivery Guy @Odaily

Incident Summary

On October 29, 2026, according to public statistics, Binance hot wallets on six chains—Ethereum, Arbitrum, Avalanche, Optimism, Bitcoin, and Tron—were drained of at least $5.5 billion, making it the largest cryptocurrency theft on public record. The attack centered on Binance 14—one of Binance's largest and most active hot wallets on Ethereum.

Starting at 20:24 UTC, the attacker first emptied Binance 14 with a single transaction of approximately $2.5 billion. Just minutes earlier, an EIP-7702 authorization signed with a copy of the wallet's private key had pointed the wallet's delegation to a sweeper contract deployed by the attacker. Within 12 minutes of the first sweep, 10 other Binance hot wallets across four chains funneled funds to the same address; the attacker then used the still-delegated Binance 14 to drain a smart account under Binance's name. Binance said it is investigating and has not confirmed whether user funds were affected. So far, the sweeps total $5.5 billion, and the exploit is still ongoing.

Blockaid's detection flagged the sweep within two minutes of it occurring—before any public report—and automated analysis confirmed the private key compromise and delegation mechanism within 11 minutes. Within an hour, Blockaid marked the attacker's addresses as malicious across its network, notified all customers of the incident through its Ecosystem Incidents Feed, and tracked the funds as they were dispersed, swapped, and used as collateral for loans. Tether and Circle froze approximately $1.8 billion on the primary receiving address; Tether later stated that the total USDT it froze exceeded $1.5 billion. ETH, AVAX, OP, and ARB that could not be frozen remain in the attacker's hands.

This report covers the attacker's preparation, the EIP-7702 delegation and sweep, the parallel private-key signing across four chains, the money laundering path, and the freezes. It is written for exchanges, custodians, and financial institutions that hold signing keys at scale, and it points to the two control points that determine the outcome of such attacks: policy enforcement before a signature is produced, and continuous monitoring after funds begin to move.

Background: Hot Wallets, Signing Keys, and EIP-7702 Delegation

Exchange hot wallets are online accounts that exchanges use to process customer withdrawals and move funds between their own wallets. They hold large amounts of working capital, sign continuously—often thousands of transfers a day—and the private keys behind those signatures are the only line of defense between the balance and anyone holding a copy of the key. On Ethereum and other EVM chains, these wallets have historically been externally owned accounts (EOAs)—plain addresses with no code, where a single valid signature can move funds and nothing further is verified on-chain.

EIP-7702 allows an EOA to run smart contract code. The account signs an authorization designating a contract; once a type-4 transaction includes that authorization in a block, any call to the account executes that contract's logic with full access to the account's balance. The authorization is bound to the account's nonce, and the delegation remains in effect until the account signs a new authorization to replace or clear it. For retail wallets, this enables batched transactions and gas sponsorship; for hot wallets, a single leaked signature landing on the right nonce hands the attacker persistent, code-level control of the account—including every deposit that arrives afterward.

In the first half of 2026, Blockaid verified 4 EIP-7702 incidents totaling approximately $1.08 million, each abusing a different facet of delegation; its "H1 2026 Onchain Security Report" predicted that the first seven-figure case would appear before year-end. This incident is that prediction coming true—three orders of magnitude larger than forecast.

The direct transfer path is older and simpler: a stolen private key signs ordinary transfers, and on a wallet that sends thousands of withdrawals a day, those transfers look routine until the recipient, amount, and timing are viewed together. Both paths ultimately come down to the private key—which is why detection for this class of attack relies on behavioral characteristics rather than known signature patterns or contract vulnerabilities.

The Full Exploit Timeline

All times below are UTC on October 29, 2026; the incident was still evolving at press time.

1. Preparation

Operator address 0x7C8601d4645b93cea45F71e118A729332e6B5CA0 was funded via three Tornado Cash withdrawals starting October 28. On October 29, it rehearsed the full "delegate—sweep" process on three wallets it controlled, transferring only $2 to $6 each time; at 15:59 that day, it deployed the sweeper contract 0x63e842B054Bd624a465454D533C33F573e9c6fAe later used against Binance. The contract is unverified, lists the operator as the sole authorized caller, and contains a sweep function (transferring every listed token and ETH in the account to a specified recipient) and a forwarding function (allowing the delegated account to call other contracts).

2. Nonce Spraying: 50 Authorizations, One Hit

At 20:20:59, the operator sent a type-4 transaction to Binance 14 (0x28C6c06298d514Db089934071355E5743bf21d60) carrying 50 EIP-7702 authorizations signed with Binance 14's private key, one for each nonce from 18,914,775 to 18,914,824, each delegating the wallet to the sweeper contract. At the time, Binance 14 was still processing customer withdrawals, so the attacker could not know which nonce was currently valid and simply signed an entire window. 49 were invalid; 1 hit, and the delegation took effect immediately—while Binance's own transactions continued to go out from the same wallet as usual.

3. The Sweep: $2.5 Billion in One Transaction

At 20:24:23, three minutes and twenty-four seconds later, the operator called sweep on Binance 14, transferring 167,464 ETH, 1.615 billion USDT, and approximately 60 other tokens to a previously untouched receiving address, 0x5227f603C1eE34CE3C06eFe6477003BDfCCB2f8c. Binance 14 was left with only 1 ETH. At prices at the time, the basket was worth approximately $2.5 billion.

4. Ten More Private Keys Across Four Chains

24 seconds after the sweep, Binance 16 sent 28,005.6 ETH, 55.7 million USDT, 25.9 million RLUSD, 84.5 WBTC, and five other tokens to the same address. Within 12 minutes, Binance 55 on Optimism sent 44.2 million OP; four hot wallets on Arbitrum sent 74.6 million ARB and 8,426 ETH; and four hot wallets on Avalanche sent 1.81 million AVAX and 8.41 million USDT.

None of these wallets had code. Every transfer was an ordinary transaction signed with the wallet's own private key, sent amid routine withdrawals. Public tallies also attribute 18,270 BTC on Bitcoin and approximately $630 million on Tron to the same actor (this portion was marked in the original as pending threat intelligence confirmation; see translator's note).

5. Smart Accounts and Continued Draining

At 20:41:23, the operator used the still-delegated Binance 14—which held a Circle smart account, Binance Hot Wallet 34—to move 780 million USDC from that account back to the receiving address, followed by another 43 million USDC. At 21:44, it swept Binance 14 again, taking 200 million USDT and 13 other tokens that had arrived after the first sweep. As of 22:00, the delegation remained active, and any funds sent to Binance 14 could be taken without another signature.

Why Onchain Monitoring and Risk Exposure Matter Just as Much When Stolen Funds Are Moving

Institutions can control their own keys and signing processes, but they cannot control where funds flow, the counterparties who deposit money with them, or an attacker who has already moved $3 billion across four chains. It is precisely this external risk surface that Onchain Monitoring and Risk Exposure cover—and in this incident, both began working within seconds of the first transfer.

Onchain monitoring detects behavior, not signatures. The signals in this incident were: a hot wallet's code changing from empty to a delegation pointer; a treasury address sending inventory-scale amounts to an address with no history; and the same new address receiving funds from 11 flagged wallets across four chains within 12 minutes. None of this requires known attack patterns or contract vulnerabilities, which is why Blockaid's detectors triggered 1 minute 55 seconds after the sweep, and within 7 seconds for each cross-chain transfer. The delegation itself was visible on-chain for 3 minutes 24 seconds—any institution monitoring its own address state changes had that window to act. When a monitoring alert fires, Blockaid's response workflow can push "sweep the balance" or "clear the delegation" transactions directly into an institution's custody platform, with response and detection starting within the same minute.

Risk Exposure addresses the other side of the same incident: everyone about to receive this money. Within 90 minutes of the sweep, the stolen funds touched Permit2, LI.FI, Uniswap, UniswapX, and Aave, followed by bridge and aggregator transactions. Every pool, lending market, bridge, market maker, and exchange along this path now holds or has processed these stolen funds, and compliance risk landed on them the moment the funds arrived. Risk Exposure gives these institutions real-time signals.

How EIP-7702 Turns a Leaked Private Key into Permanent Control

Before EIP-7702, a stolen hot wallet private key meant a race against time: the attacker had to complete every signature before the balance could be moved elsewhere, and once the exchange rotated to a new address, the key was worthless. A key that can sign delegations changes that.

A single authorization, valid at a single nonce, turned Binance 14 into a program owned by the attacker. The first sweep took the balance at 20:24 UTC, and the delegation remained untouched; at 21:44 UTC, the attacker took over $200 million in new deposits without the wallet signing another transaction. Rotating to a new private key does not revoke it, because the delegation belongs to the address, not the key. Only another authorization signed with the compromised key, pointing the account at the zero address, can reset it; until then, every dollar sent to Binance 14 is reachable.

For teams running large EOAs, the actionable steps are concrete: treat EIP-7702 authorizations as privileged operations and manage them under the same policy as cold wallet transfers; monitor code changes on every hot wallet address and prepare revocation transactions in advance; do not hold inventory in any address with an uncertain delegation state; after a compromise, clear the delegation first, then rotate keys and replenish the wallet; and on every delegation transaction, forward the authorization list to a screening layer—because stripped of that list, a delegation looks like an empty call to a trusted address. Blockaid's engine already evaluates this list, and Cosigner already forwards it; the gap this incident exposed is in signing flows that do not.

Conclusion

Private key compromise remains the largest source of onchain losses. If public tallies hold, this will be the largest theft in history—more than three times the approximately $1.5 billion stolen from Bybit in February 2025. Private keys from 11 Binance hot wallets signed transfers to an address created just minutes earlier, and one of them also signed an EIP-7702 authorization that turned its wallet into permanent infrastructure for the attacker. Stablecoin issuers froze approximately $2.4 billion within two hours, while native assets such as ETH remain in the attacker's hands.

A valid signature produced by a leaked private key looks no different on-chain from a legitimate one. The outcome of this class of attack is decided at the moment of signing by policy—policy that checks what the key is about to sign—and in the minutes that follow by monitoring—tracking funds that can still be intercepted.