An on-chain reconstruction of the 29 October 2026 Binance incident, built from raw Ethereum node data. Every claim below links to a transaction hash you can verify yourself.
Between 20:20 and 21:44 UTC on 29 October 2026, an attacker who held the private key for Binance's hot wallet 0x28C6c06298d514Db089934071355E5743bf21d60 ("Binance 14") did not drain it the ordinary way. Instead they used EIP-7702, the Pectra upgrade feature that lets a normal account borrow a contract's code, to install attacker-written code onto the Binance 14 account itself. Three and a half minutes later they called one function on it, sweep(to, tokens[65]), and 167,464 ETH plus 63 tokens including 1.615 billion USDT left in a single transaction. A second Binance hot wallet was emptied of 28,005 ETH by a plain transfer at the same time. The attacker rehearsed the exact technique six hours earlier on three test accounts.
Resolved — backdoor revoked at 00:10:35 UTC, 30 October 2026 (block 26301896). For roughly 3 hours 46 minutes after the first sweep, Binance 14 ran the attacker's code and fresh deposits kept being swept — at least four times (20:24, 21:04, 21:44 UTC, and a ~2,962 ETH sweep at ~23:55 UTC caught live on the HaskDetect tracker). Binance then regained operational control of the wallet and sent a single EIP-7702 transaction (0xafbf94c9…dac7209) delegating the account to the zero address, which cleared the code. eth_getCode on Binance 14 now returns 0x — a normal account again. New deposits there are no longer at risk. The stolen funds that already left are a separate matter: the ~195,460 ETH remains parked and the liquid tokens are gone; recovery now rests on the frozen stablecoins and exchange/bridge flags.
Open → revoked, caught end to end on the live tracker. The exact block the backdoor closed is recorded above.
Attacker signer makes its first ever transaction: deploys a contract (0x19bee294…). Gas came in via an internal transfer, consistent with a Tornado Cash withdrawal.
Rehearsal 1 and 2. Two attacker-controlled accounts are 7702-delegated to 0x19bee294… and then swept with the same 0x8a179be4 function later used on Binance.
Attacker deploys the production payload, 0x63e842b0…. Derived from the signer's address and nonce; this is not an inference from labels.
Rehearsal 3. Account 0x43AEdb9B… is delegated to 0x63e842b0…, swept, then a withdraw call is tested. Full dress rehearsal of the real attack.
Signer receives 1.08 ETH for gas from 0xe4F9070e…
The set-code transaction. Type-4 tx 0xad99264d5532ae0dd04b2004eebda05f25657e70dacb764f7ac8d4ccd051298b carries 50 EIP-7702 authorizations, all for Binance 14, signed with 50 consecutive nonces (18,914,775 through 18,914,824). See "Why fifty" below.
The sweep. Tx 0x53bd38b816c23e74134786c29a8c18d792777998a3b9326047b583100e88e2f3: attacker calls Binance 14, now running attacker code, with sweep(0x5227f603…, [ETH, USDT, …63 more]). 167,464 ETH and 1,615,409,499 USDT move in one call.
Second Binance hot wallet 0xDFd5293D… sends 28,005 ETH to the loot address by ordinary transfer. Two keys, not one.
Loot sends 0.5 ETH test dust, then 500M USDT to 0x9749292D… and 200M USDT to 0x0Ddf0480…. Both are now Tether-blacklisted with zero balance; the funds moved one hop further before the freeze.
Loot moves 195,460 ETH (about $447M) to fresh address 0x8532FA14…, where it still sits untouched.
Attacker sweeps Binance 14 again: 1,700 ETH and 370 ETH of fresh deposits. Proof the backdoor keeps paying.
Loot scatters tokens: 88.5M RLUSD, 217M ENA plus 29,934 wBETH, 7M UNI, 7.7T PEPE, each to a different fresh address.
Binance 14 still delegated to attacker code. Scammers are address-poisoning the loot wallet with fake "USDT" tokens from look-alike addresses, hoping the thief mis-pastes one.
Since Pectra, an ordinary key-based account can sign an "authorization" that says: run this contract's code as if it were mine. Wallets use it for batching and sponsored gas. The authorization is just a signature over (chainId, contractAddress, nonce). Whoever holds the account's private key can sign one. Once set, the account keeps that code until another authorization replaces it.
Draining a hot wallet the ordinary way means hundreds of transactions, one per token, each racing against Binance's own systems which were still sending from Binance 14 every few seconds. Installing code turns the account into a contract the attacker controls: one call, every asset, and the account keeps obeying afterwards. It also sidesteps per-token monitoring that watches for the hot wallet sending, because the sender of the sweep is the attacker's address, not Binance 14.
An authorization is only valid if its nonce equals the account's nonce at the moment the transaction executes. Binance 14 sends a transaction roughly every ten seconds, so the attacker could not know which nonce it would be on when their transaction was mined. They signed fifty in a row and submitted them all; the one that matched took effect, the rest were discarded. This is the signature of someone who studied the target's traffic pattern and understood 7702's validation rules precisely. It also means the attacker signed with the Binance 14 private key fifty times. There is no reading of this data in which the key was not in their hands.
What this is not. Not a smart-contract exploit, not a bridge bug, not a phishing of a user. The chain shows a hot-wallet private key being used by someone other than its owner, on two wallets. How the key left Binance's infrastructure is not visible on-chain and is not claimed here.
Anyone can check whether an account has been hijacked this way with one call, eth_getCode. A normal key-based account returns 0x (empty). Binance 14 returns:
0xef010063e842b054bd624a465454d533c33f573e9c6fae
It reads in two parts. ef0100 is the fixed three-byte flag EIP-7702 writes onto a delegated account; seeing it at all means the account is now executing another contract's code. The 20 bytes after it, 63e842b0…9c6fae, are the address of that contract: here, the attacker's own payload, deployed by the attacker six hours before the attack. So the single line of code on the victim account names its attacker. As long as that line is present, the account is still under attacker control, and resetting it needs the account's own key, which the attacker also holds.
| Asset | Amount | Status | Where |
|---|---|---|---|
| USDT | 1,175,464,711 | Frozen (Tether blacklist) | 0x5227f603… (loot) |
| USDT | 700,000,000 | Moved one hop before freeze; both hops now blacklisted | via 0x9749292D… and 0x0Ddf0480… |
| ETH | 195,460 | Parked, unspent | 0x8532FA14ACAf483729C449b8458aedDb900543D4 |
| ETH | ~2,076 | Remaining at loot | 0x5227f603… |
| RLUSD | 88,541,065 | Freezable by issuer | 0x5C23023C… |
| ENA / wBETH | 217M / 29,934 | Liquid | 0x7f9DC988… |
| UNI | 7,018,792 | Liquid | 0x42CDF00c… |
| PEPE | 7.77T | Liquid | 0x600d6F00… |
USDC figures are not in this report because the USDC leg left from the second hot wallet and other chains (Arbitrum, Avalanche), which this reconstruction does not yet cover. Circle has publicly confirmed a freeze. The BTC on Arkham's entity page is likewise out of scope for this Ethereum-only pass.
HaskDetect scores behaviour, not labels. Reading only public chain data, these signals were available before the sweep landed:
Signals 04 and 05 are new to the post-Pectra world and are not in most exchange monitoring stacks yet. They should be.
Every address and hash above is public. For the 7702 authorization list: fetch transaction 0xad99264d…51298b from any Ethereum node, read its authorizationList, and recover each signer from keccak(0x05 || rlp([chainId, address, nonce])). For the attacker's contract: compute the CREATE address of 0x7c8601d4… at nonce 5. For the current backdoor: eth_getCode on Binance 14 and look for the 0xef0100 prefix.