Binance $5.5B Hack: Using Advanced AI Models, Blockaid Detects the Biggest Theft in Crypto History

Exploit Summary

At least $5.5B was stolen from Binance’s hot wallets on October 29, 2026, across Ethereum, Arbitrum, Avalanche, Optimism, Bitcoin, and Tron by public tallies, the largest crypto theft on record. The attack centered on Binance 14, one of Binance’s largest and most active Ethereum hot wallets. The attacker first drained Binance 14 starting 20:24 UTC in a single transaction worth about $2.5B, minutes after a copy of the wallet’s key signed an EIP-7702 authorization delegating it to an attacker-deployed sweeper.. Within 12 minutes after that initial drain, 10 more Binance hot wallets on four chains sent funds to the same address, and the attacker then drained a Binance-owned smart account through the still-delegated wallet. Binance said it was investigating and had not confirmed any impact to user funds. All these drains have added up to $5.5B so far, and the exploit is still ongoing.

Blockaid’s detection flagged the drain under two minutes after the sweep and before any public report, and automated analysis confirmed a key compromise and the delegation mechanism within 11 minutes. Within the hour, Blockaid flagged the attacker’s addresses as malicious across its network, pushed the incident to all customers through the Ecosystem Incidents Feed, and traced the funds as they were split, swapped, and borrowed against. Tether and Circle froze about $1.8B in the main collection address, and Tether later said its freezes totaled more than $1.5B in USDT. The ETH, AVAX, OP, and ARB that cannot be frozen stayed with the attacker.

This report covers the attacker’s preparation, the EIP-7702 delegation and the sweep, the parallel key signatures across four chains, the laundering path and the freezes, and Blockaid’s detection and response. It is written for exchanges, custodians, and institutions that hold signing keys at scale, and it points at the two controls that decide outcomes in this category of attack: policy enforcement before a signature is produced, and continuous monitoring of funds once they are in motion.

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

Exchange hot wallets are the online accounts an exchange uses to pay out customer withdrawals and move funds between its own wallets. They hold large working balances and sign continuously, often thousands of transfers a day, and the private key behind those signatures is the only control between the balance and anyone holding a copy of it. On Ethereum and other EVM chains, these wallets have historically been externally owned accounts (EOAs), plain addresses with no code, where a valid signature moves funds and nothing else is verified onchain.

EIP-7702 lets an EOA run a smart contract’s code. The account signs an authorization naming a contract, and once a type-4 transaction carries it into a block, any call to the account runs that contract’s logic with full access to the account’s balances. The authorization is bound to the account’s nonce, and the delegation stays in place until the account signs another one that replaces or clears it. For a retail wallet, that enables batching and gas sponsorship. For a hot wallet, one leaked signature over the right nonce hands an attacker persistent, code-level control of the account, including every deposit that arrives afterward.

Blockaid verified four EIP-7702 incidents in the first half of 2026, totaling roughly $1.08M and each abusing a different aspect of delegation, and its H1 2026 Onchain Security Report forecast that the first seven-figure case would arrive before year end. This incident is that forecast realized, three orders of magnitude beyond it. The direct-transfer path is older and simpler. A compromised key signs ordinary transfers, and on a wallet sending thousands of withdrawals a day they look routine until destination, size, and timing are examined together. Both paths come down to the key, which is why detection in this category depends on behavior rather than a known signature or a contract bug.

The Exploit: How it Unfolded

All times are UTC on October 29, 2026, and the incident was still unfolding at publication.

1. Preparation

The operator address, 0x7C8601d4645b93cea45F71e118A729332e6B5CA0, was funded through three Tornado Cash withdrawals starting October 28. On October 29 it rehearsed the full delegate-and-sweep sequence on three wallets it controlled, moving $2 to $6 each time, and at 15:59 deployed the sweeper later used on Binance, 0x63e842B054Bd624a465454D533C33F573e9c6fAe. The contract is unverified, names the operator as its only authorized caller, and carries a sweep function that moves every listed token and the account’s ETH to a recipient, plus a forwarding function that lets the delegated account call other contracts.

2. The Nonce Spray: 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 the Binance 14 key, one per nonce from 18,914,775 to 18,914,824, each delegating the wallet to the sweeper. Binance 14 was still paying out withdrawals, so the attacker could not know which nonce would be current and signed a window instead. Forty-nine were invalid. One matched, and the delegation took effect while Binance’s own transactions kept flowing from the same wallet.

3. The Sweep: $2.5B in One Transaction

At 20:24:23, three minutes and 24 seconds later, the operator called sweep on Binance 14 (transaction), sending 167,464 ETH, 1.615B USDT, and about 60 other tokens to a collection address with no prior history, 0x5227f603C1eE34CE3C06eFe6477003BDfCCB2f8c. Binance 14 was left with 1 ETH. At prices at the time, the basket was worth about $2.5B.

4. Ten More Keys Across Four Chains

Twenty-four seconds after the sweep, Binance 16 sent 28,005.6 ETH, 55.7M USDT, 25.9M RLUSD, 84.5 WBTC, and five other tokens to the same address. Within 12 minutes, Binance 55 on Optimism sent 44.2M OP, four hot wallets on Arbitrum sent 74.6M ARB and 8,426 ETH, and four on Avalanche sent 1.81M AVAX and 8.41M USDT. None of these wallets carried code. Each transfer was an ordinary transaction signed by the wallet’s own key, placed between routine withdrawals.

5. The Smart Account and the Standing Drain

At 20:41:23 the operator used the still-delegated Binance 14, which owns the Circle smart account Binance Hot Wallet 34, to move 780M USDC from that account to the collection address, followed by another 43M USDC. At 21:44 it swept Binance 14 again for 200M USDT and 13 other tokens deposited since the first sweep. As of 22:00 the delegation was still in place, and anything sent to Binance 14 remained reachable without another signature.

Why Cosigner Matters for Exchanges and Institutions Holding Keys at Scale

The delegation transaction was the point where this attack could have been stopped. Blockaid's transaction security engine classified the type-4 transaction that delegated Binance 14 as malicious on sight, with the reason that an EOA was being upgraded through EIP-7702 to an untrusted address. When EIP-7702 was introduced in May 2026, Blockaid had built such detection into our exploit detection  engine. The engine has already caught this class in production. 

Blockaid Cosigner is an independent signing layer that sits on a wallet and utilizes signals from our exploit detection engine to reject malicious transactions. It sits between an organization's signing infrastructure, whether MPC, multisig, or a custody platform such as Fireblocks, Fordefi, Safe, or Utila, and the chain. Every transaction, including the authorization list on a type-4 transaction, is simulated and screened before a signature is produced, and under Cosigner's default policies a transaction the engine classifies as malicious is rejected regardless of how many approvers signed off. A hot wallet whose signing path runs through Cosigner would not be able to authorize its own delegation to a contract like this one, because the authorization never leaves the policy layer.

Additionally, Cosigner enables the setup of policies such as destination allowlists, value caps per transaction and per window, and checks on counterparties that are new, unlabeled, or tied to mixer-funded activity. A compromised key still produces valid signatures, but with Cosigner enabled-policies enforced before signing, the key alone would not have been able to push a nine-figure transfer to a fresh address, and the transfers that defined this incident would have been rejected at the point they were proposed.For exchanges and institutions running hot wallets at scale, an architecture with Cosigner enforcing policy on every signature is the preventive measure for the category of attack this incident belongs to.

Why Onchain Monitoring and Risk Exposure Matter When Stolen Funds Are in Flight

An organization controls its own keys and signing flow. It does not control the venues its funds pass through, the counterparties that deposit into it, or the attacker who is already moving $3B across four chains. That external surface is what Onchain Monitoring and Risk Exposure cover, and in this incident both were working within seconds of the first transfer.

Onchain Monitoring detects behavior rather than signatures. The signals here were a hot wallet whose code changed from empty to a delegation pointer, a treasury address sending inventory-sized amounts to an address with no history, and the same new address receiving from 11 labeled wallets across four chains within 12 minutes. None of those require a known exploit pattern or a contract bug, which is why Blockaid's detector fired one minute and 55 seconds after the sweep and within seven seconds of each cross-chain leg. The delegation itself was visible onchain for three minutes and 24 seconds before the sweep, and an organization monitoring its own addresses for that state change would have had that window to act. When a monitor fires, Blockaid's response workflows can propose the transaction that moves the balance or clears the delegation directly into the organization's custody platform, so the response starts in the same minute as the detection. 

Risk Exposure addresses the other side of the same event, which is everyone about to receive the money. Within 90 minutes of the sweep, the stolen funds touched Permit2, LI.FI, Uniswap, UniswapX, and Aave, followed by bridging and aggregator transactions. Every pool, lending market, bridge, market maker, and exchange on that path now holds or has processed proceeds of the theft, and the compliance exposure attaches to them the moment the funds arrive. Risk Exposure gives those parties the signal in real time. 

EIP-7702 Turns a Leaked Key into Persistent Control

Before EIP-7702, a stolen hot wallet key started a race. The attacker had to sign each theft while the operator could still move the balance away, and once the exchange rotated to new addresses the key was worthless. A key that can sign a delegation changes that. One authorization, valid at one nonce, turned Binance 14 into a program the attacker owns. The first sweep took the balance at 20:24 UTC, the delegation stayed in place, and at 21:44 UTC the attacker took more than $200M in new deposits with no further signature from the wallet. Rotating to new keys does not clear it, because the delegation belongs to the address. Only one more authorization signed with the compromised key, pointing the account at the zero address, resets it, and until that happens every deposit to Binance 14 is reachable.

For teams operating large EOAs, the practical steps are concrete. Treat EIP-7702 authorizations as privileged operations under the same policy controls as a cold wallet transfer. Monitor every hot wallet address for code changes, with a revocation transaction prepared in advance. Keep inventory out of any address whose delegation status is unknown. After a compromise, clear the delegation before rotating keys and refilling the wallet. And forward the authorization list to the screening layer on every delegation transaction, because stripped of that list a delegation looks like an empty call to a trusted address. Blockaid’s engine already evaluates that list and Cosigner already forwards it; the gap this incident exposes is in the signing flows that do not.

Conclusion

Compromised keys remain the largest source of losses onchain, and if the public tallies hold this is the largest theft on record, more than three times the roughly $1.5B taken from Bybit in February 2025. Eleven Binance hot-wallet keys signed transfers to an address created minutes earlier, and one of them signed an EIP-7702 authorization that turned its wallet into standing infrastructure for the attacker. Stablecoin issuers froze roughly $2.4B within two hours, while the ETH and other native assets stayed with the attacker.

A valid signature from a compromised key looks identical to a legitimate one at the chain level. The outcome in this category of attack is decided at the signature, by policy that checks what a key is about to sign, and in the minutes that follow, by monitoring that tracks the funds while they can still be stopped.

About Blockaid

Blockaid is the onchain security platform trusted by the largest companies operating in Web3. Built by veterans of elite intelligence and cybersecurity units, Blockaid provides end-to-end protection for financial institutions, protocols, and end users, combining direct wallet and dApp integrations with real-time monitoring, detection, and response across smart contracts, infrastructure, and externally owned accounts. Since 2025, Blockaid scanned over 6.3 billion transactions and blocked 585 million attacks. Blockaid is the security infrastructure behind Coinbase, MetaMask, Uniswap, Safe, and dozens of the most widely used platforms in the industry.

Learn more at blockaid.io, and follow us on X and LinkedIn.