The $6.3B Binance Hack: How Binance 14's Own Key Signed the Takeover

On the evening of 29 October 2026, attackers took about $6.3 billion from Binance hot wallets on eight chains, by Binance's own estimate the largest crypto theft on record. We traced the Ethereum, Arbitrum and Avalanche side as it happened, $3.79B of it. The short version: nobody exploited a bug. Binance 14's own key signed an EIP-7702 delegation that turned the wallet into the attacker's code, and Binance has since traced the breach to the service that submits its withdrawals.

All figures below come from public on-chain data, valued at prices at the time of the drain (ETH at $2,313). The account of the night reflects the chain at 21:24 UTC on 29 October; the box above and the table further down are as of 06:25 UTC on 30 October. Changpeng Zhao posted on the night that "It does look like a hack on Binance" and that "As a shareholder, I expect all user funds will be fully covered." Times are UTC.

What happened, minute by minute

How a stranger moved Binance 14's funds

Binance 14 (0x28C6…1d60) is one of the busiest wallets on Ethereum, with nearly 19 million transactions. It is a plain wallet controlled by one key, not a smart contract. Yet the transaction that emptied it was sent by a different address. That is only possible because of EIP-7702, which Ethereum activated in May 2025.

EIP-7702 lets a plain wallet point to a contract and run that contract's code as its own. The wallet's key signs a short message called an authorization, naming the contract and the wallet's current nonce. Anyone can then submit that authorization on-chain. From that moment, any call to the wallet runs the contract's logic against the wallet's own balance.

At 20:20:59 the attacker's initiator submitted a transaction carrying 50 such authorizations for Binance 14, all naming its sweep contract. We recovered the signer of each one cryptographically. All 50 were signed by the Binance 14 key. Whoever prepared them had either the key itself or the ability to make Binance's signing system sign whatever they asked.

The number 50 is a clue. An authorization only takes effect if its nonce matches the wallet's nonce at that instant, and Binance 14 was sending a customer withdrawal every few seconds. The attacker signed one authorization for each nonce from 18,914,775 to 18,914,824 so that one would match whenever the transaction landed. One did: nonce 18,914,809. The lowest nonce in the batch was Binance 14's live nonce at 20:17:47, three minutes earlier, which suggests the signatures were produced in real time rather than stockpiled.

The sweep contract is unverified, but its bytecode is short. It accepts calls only from the initiator's address, and its sweep function sends every listed token and all ETH except 1 ETH to an address of the caller's choosing. After the drain, Binance 14 held exactly 1 ETH.

Hot Wallet 34 (0xEe7a…4055) is a smart wallet that executes instructions from Binance 14. Once Binance 14 ran the attacker's code, that trust became a second door: the attacker had Binance 14 instruct Hot Wallet 34 to pay out 823M USDC.

It was not one key

Twenty-four seconds after the sweep, Binance 16 (0xDFd5…963d) sent nine ordinary signed transfers to the same receiver. No EIP-7702 was needed there: these were regular transactions signed with Binance 16's key. Two details stand out. Their nonces follow directly after two small routine transfers in the same block (799.40 and 36.36 USDT), and they use the same 170 gwei fee cap as Binance 16's own transactions, with a higher tip. Every amount is rounded down to one decimal place.

Between 20:30 and 20:36 the pattern repeated on two more chains, again with amounts rounded to one decimal. On Arbitrum, a wallet publicly labelled as a Binance hot wallet sent 74,559,805.2 ARB, and three other high-volume wallets sent 8,426.2 ETH. On Avalanche, four high-volume wallets (between 0.9 and 5.1 million transactions each) sent 1,814,099.3 AVAX and 8,409,928.4 USDt. We could not label the Avalanche wallets independently.

Taken together, this pointed away from a single leaked key and towards the layer that signs for many hot wallets across chains. On the night we called it a hypothesis, because the chain shows what was signed, not how. Binance has since said its initial investigation points to a compromised DevOps engineer's laptop that gave the attacker access to a service container submitting withdrawal transactions, and that it found no evidence of a private key leak.

One detail deserves attention in the post-mortem Binance has promised. An EIP-7702 authorization is not a withdrawal transaction: it is a separate message type with its own prefix. For Binance 14 to be delegated, whatever the attacker reached must have been willing to sign that message, 50 times, for a hot wallet. A withdrawal service that can sign arbitrary payloads is a far bigger problem than one that can only send withdrawals.

The preparation happened in public

The initiator was funded by three 0.1 ETH withdrawals from Tornado Cash on 28 and 29 October. A backup wallet, funded by one 0.1 ETH and one 1 ETH Tornado Cash withdrawal, paid the initiator's gas and financed a test wallet.

The rehearsal is all on-chain. At 13:51 the initiator delegated two of its own wallets with EIP-7702, packing several authorizations into each transaction, as it later did for Binance 14. It then swept a few dollars of USDT and USDC out of them. At 16:20, with the final contract deployed, it ran the full sequence again on a third wallet. Four hours later it did the same to Binance 14.

Racing the freeze

Most of the haul was in stablecoins that their issuers can freeze, and the attacker acted like it knew that. Within ten minutes of the drain it split 500M and 200M USDT into fresh wallets and began selling. Over 35 minutes, four laundering wallets sold 435M USDT for 160,451 ETH through UniswapX orders, solver fills and Uniswap pools. They paid an average of $2,711 per ETH while the market traded between $2,256 and $2,315, 17 to 20% above market, to get out before the freeze. One wallet took a different route: it supplied 60M USDT to Aave V3 and borrowed 19,762 ETH against it.

Tether chased the funds hop by hop. It froze the receiver and the first laundering wallet at 21:01:35, then six more addresses by 21:18:59, often within minutes of the USDT arriving. One wallet forwarded 130M USDT 48 seconds before its own freeze. Circle froze the 823M USDC at 21:04:59. Tether also froze the USDt on Avalanche.

There were spectators too. Within a minute of each new wallet appearing, address-poisoning bots sent the receiver fake USDT and ETH transfers from look-alike addresses, hoping the attacker would copy the wrong one. One stranger sent the initiator an on-chain message asking for a donation.

Eight chains, $6.3B

We traced the Ethereum, Arbitrum and Avalanche side. CertiK engineer Dickson published a breakdown of all eight chains at the time of the drain, totalling about $6.28B, close to Binance's own estimate of around $6.3B. His figures for the three chains we traced match ours. The attack started on XRP at 20:04:52 UTC, sixteen minutes before the Ethereum delegation.

Where the EVM money sits now

On the three chains we traced, 58% of the $3.79B taken is frozen in stablecoins alone, and about 64% once the Arbitrum funds and the issuer-frozen tokens are counted. The ETH is the part that matters for recovery: issuers cannot freeze it, so whether it can be recovered depends on where it surfaces next, at an exchange, a bridge or a mixer. Binance 14 carried the attacker's delegation until 00:10:35, which is why the second, third and fourth sweeps worked.

What custodians should take from this

• An EIP-7702 authorization is a withdrawal of everything. It is not a transaction, so withdrawal policies that inspect transactions may never see it. Signing services, HSMs and MPC policies should refuse authorization messages (the 0x05-prefixed payload EIP-7702 defines) for hot wallets unless explicitly enabled.
• Rehearse the revocation. Binance removed the delegation with a single signed authorization to the zero address, but it took 3 hours 50 minutes. That signature should be a runbook step measured in minutes.
• Watch your own wallets for code. A hot wallet that suddenly has code is an emergency. Checking it every block is one cheap call per wallet, and here it would have given a three-minute warning.
• Stop the flow into a compromised wallet. Binance 14 kept processing withdrawals and receiving deposits after the drain. The attacker swept it again after 40 minutes, and a third time 80 minutes in, right after another Binance wallet topped it up with 200M USDT.
• Do not let a hot key command other wallets. Hot Wallet 34 trusted Binance 14, so one compromised key emptied two wallets.
• Have issuer escalation ready before you need it. Tether and Circle froze $2.01B within an hour. Every minute counted: one wallet moved 130M USDT 48 seconds before its freeze.
• Rehearsals are visible. A Tornado-funded address deploying a contract that only it can call, then delegating and sweeping its own wallets, is a pattern worth alerting on before it reaches yours.

What we do not know yet

How a laptop and a service container led to signatures on 50 EIP-7702 authorizations and on transfers from Binance hot wallets on eight chains; Binance has promised a full post-mortem. Where the 500,938 ETH on Ethereum and the Bitcoin will go. Whether attribution to North Korea holds. We will keep updating this analysis. Addresses and transaction hashes are linked above so that anyone can check our work.

How Ondology Labs can help: We traced this incident with our own AI Investigator in the first hour. If your platform or your clients are affected, we provide transaction tracing across chains, incident investigations and court-ready blockchain forensics, including the evidence issuers and exchanges need before they freeze funds.

Related reading: The first 24 hours after your crypto is stolen · Inside the CoinDCX $44M hack