The original article is from Web3 security company blockaid
Compiled by Expressman@Odaily Planet Daily
Incident Summary
On October 29, 2026, according to public statistics, Binance hot wallets on six chains—Ethereum, Arbitrum, Avalanche, Optimism, Bitcoin, and Tron—were stolen of at least $5.5 billion, the largest cryptocurrency theft on public record. The attack centered on Binance 14 (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 transaction of approximately $2.5 billion. Just minutes earlier, an EIP-7702 authorization signed with a copy of the wallet's private key directed the wallet's delegation to a sweeper contract deployed by the attacker. Within 12 minutes after the first sweep, 10 other Binance hot wallets on four chains sent funds to the same address; subsequently, the attacker used the still-delegated Binance 14 to empty 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 reports, and automated analysis confirmed the private key leak and delegation mechanism within 11 minutes. Within an hour, Blockaid marked the attacker's addresses as malicious on its network, notified all customers of the incident through the Ecosystem Incidents Feed, and tracked the entire process of funds being dispersed, swapped, and used as collateral for loans. Tether and Circle froze approximately $1.8 billion on the main 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 process, EIP-7702 delegation and sweeping, parallel private key signing on four chains, money laundering paths, and freezing. It is written for exchanges, custodians, and financial institutions that hold signing keys at scale, pointing to the two control points that determine the success or failure of such attacks: policy enforcement before signatures are produced, and continuous monitoring after funds start moving.
Background: Hot Wallets, Signing Keys, and EIP-7702 Delegation
Exchange hot wallets are online accounts used by exchanges to process customer withdrawals and transfer funds between their own wallets. They hold large amounts of working capital, sign continuously, often signing thousands of transfers a day; and the private keys behind these signatures are the only line of defense between the balance and anyone holding a copy of the private key. On Ethereum and other EVM chains, such wallets have historically been externally owned accounts (EOAs)—ordinary addresses without 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 specifying a contract; once a type-4 transaction packages this authorization into a block, any call to that account will execute 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 effective until the account signs a new authorization to replace or clear it. For retail wallets, this enables batch transactions and gas sponsorship; for hot wallets, a single leaked signature landing on the correct nonce is equivalent to handing continuous, code-level control of the account to the attacker, including every subsequent deposit.
Blockaid verified 4 EIP-7702 incidents in the first half of 2026, involving a total of approximately $1.08 million, each abusing a different aspect of delegation; its "H1 2026 Onchain Security Report" predicted that the first seven-figure case would appear before the end of the year. This incident is the fulfillment of that prediction, and three orders of magnitude higher than predicted.
The direct transfer path is older and simpler: a stolen private key signs ordinary transfers, which on a wallet that sends thousands of withdrawals a day look routine until the recipient, amount, and timing are viewed together. Both paths ultimately rest on private keys—which is why detection of this type of attack relies on behavioral characteristics, not known signature patterns or contract vulnerabilities.
The Full Exploit Process
All times below are October 29, 2026 UTC; the incident was still evolving at the time of publication.
1. Preparation
The 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 owned, transferring only $2 to $6 each time; at 15:59 that day, it deployed the sweeper contract 0x63e842B054Bd624a465454D533C33F573e9c6fAe that would later be used against Binance. The contract is unverified, lists the operator as the sole authorized caller, and contains a sweep function (transferring all listed tokens 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, and the attacker could not know which nonce was currently valid, so it simply signed an entire window. 49 were invalid, 1 hit, and the delegation took effect immediately—while Binance's own transactions continued to be sent from the same wallet as usual.
3. Sweep: One Transaction Takes $2.5 Billion
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 about 60 other tokens to a previously history-less receiving address 0x5227f603C1eE34CE3C06eFe6477003BDfCCB2f8c. Binance 14 was left with only 1 ETH. At prices at the time, this basket of assets was worth approximately $2.5 billion.
4. Ten Other Private Keys on 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. Each transfer was an ordinary transaction signed with the wallet's own private key, sent amid routine withdrawals. Public statistics also attribute 18,270 BTC on the Bitcoin chain and approximately $630 million on the Tron chain to the same actor (this part is marked in the original as pending threat intelligence confirmation; see translator's note).
5. Smart Account and Continuous Draining
At 20:41:23, the operator used the still-delegated Binance 14—which held a Circle smart account, Binance Hot Wallet 34—to transfer 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 come in after the first sweep. As of 22:00, the delegation was still effective, and any funds sent to Binance 14 could be taken without another signature.
Why Onchain Monitoring and Risk Exposure Matter Equally When Stolen Funds Are Moving
Institutions can control their own keys and signing processes, but they cannot control the venues through which funds flow, the counterparties depositing money to them, or the attacker who has already moved $3 billion across four chains. It is precisely this external risk surface that falls under the scope of Onchain Monitoring and Risk Exposure; and in this incident, both began working within seconds after the first transfer.
On-chain monitoring detects behavior, not signatures. The signals in this incident were: a hot wallet's code changed from blank to a delegation pointer; a vault address moved an inventory-sized amount to an address with no history; the same new address received funds from 11 flagged wallets across four chains within 12 minutes. None of these require a known attack pattern or contract vulnerability, so 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 the monitoring alert fires, Blockaid's response workflow can push a "sweep the balance" or "clear the delegation" transaction directly into the 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 cross-chain bridges and aggregator trades. Every pool, lending market, cross-chain bridge, market maker, and exchange along this path now holds or has processed these stolen funds, and compliance risk fell 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 other party could move the balance out, and once the exchange rotated to a new address, the private key was worthless. A private key that can sign delegations changes this.
One 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 stayed in place 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 remove it, because the delegation belongs to the address, not to the private key. Only signing another authorization with the leaked private key that points the account to the zero address can reset it; until then, every fund 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 keep inventory on any address whose delegation status is unclear; after a leak, clear the delegation first, then rotate keys and refill the wallet; and on every delegation transaction, forward the authorization list to the 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 exposed by this incident lies in signing flows that do not do so.
Conclusion
Private key leaks remain the largest source of on-chain losses. If public estimates hold, this will be the largest theft in history, more than three times the roughly $1.5 billion stolen from Bybit in February 2025. The private keys of 11 Binance hot wallets signed transfers to an address created just minutes earlier, and one of them also signed an EIP-7702 authorization, turning its wallet into the attacker's permanent infrastructure. Stablecoin issuers froze about $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 signature. The success or failure of this type of attack is decided at the moment of signing by policy—policy that checks what this private key is about to sign; and in the minutes that follow, by monitoring—tracking funds that can still be intercepted.
