What happened
On October 29, 2026, an attacker drained approximately $6.3 billion from Binance hot wallets across ten blockchains, most of it in about 20 minutes. TRM Labs has attributed the attack, with high confidence, to TraderTraitor, North Korea's elite hacking unit — the same group behind the $1.5 billion Bybit hack in February 2025.
The attack was coordinated across chains. By TRM Labs' count: about $3.79 billion on Ethereum (200,630 ETH, 1.875 billion USDT, 823 million USDC, 88.5 million RLUSD and 185 other tokens), 18,270 BTC (about $1.47 billion), 612.7 million USDT and 46.4 million TRX on Tron, 233.46 million XRP, 970,500 SOL, 74.6 million ARB on Arbitrum, and smaller amounts on Optimism, Base, Avalanche and Polygon.
On most chains, the attacker simply signed transactions from Binance's own wallets. But on Ethereum, they used something new — and the mechanism reveals a structural exposure that extends far beyond exchanges.
The EIP-7702 mechanism
The Ethereum Pectra upgrade introduced EIP-7702, which allows an ordinary wallet (an EOA — Externally Owned Account) to delegate its execution to a smart contract. The delegation stays in place until the wallet signs a new one. If you have a valid signature from the wallet's private key, you can make that wallet behave as a smart contract — executing arbitrary code, not just sending transfers.
The attacker used this against Binance 14, one of Binance's main Ethereum hot wallets. Here's the sequence:
Preparation. The attacker funded an operating address through three Tornado Cash withdrawals, deployed a sweeper contract, and tested it twice on throwaway wallets.
The 50-nonce technique. The attacker obtained 50 EIP-7702 authorization signatures from Binance 14's key, each covering a different transaction nonce — consecutive values from 18,914,775 to 18,914,824. Because Binance 14 was actively processing withdrawals, its nonce was changing constantly. By submitting 50 authorizations in one transaction, the attacker ensured that one would match the wallet's live nonce at the moment of execution.
Delegation. At 20:20:59 UTC, one authorization matched nonce 18,914,809. Binance 14's account code was replaced with a pointer to the attacker's sweeper contract. The wallet's balances didn't change — but any call to the address now executed the attacker's code.
The sweep. The sweeper contract had a single function: sweep(to, tokens[]). It was hardcoded to accept calls only from the attacker's address. At 20:24:23, the first sweep moved 167,464 ETH and 63 different tokens — approximately $2.5 billion.
Cascading access. Because Binance 14 was listed as an operator on Hot Wallet 34 (an ERC-1967 proxy smart wallet), the delegated code could also call execute on that wallet. The attacker used this to move an additional 823 million USDC.
Persistence. The delegation remained active after the sweep. Later incoming funds — deposits routed to Binance 14 by the exchange's systems — were swept in further rounds at 21:04 and 21:44 UTC. By 01:54 UTC the delegation had been revoked.
Tether, Circle, Ripple, World Liberty Financial and the Arbitrum Security Council froze approximately $2.7 billion (TRM Labs' count as of 00:30 UTC on October 30; Binance puts the frozen total at about $3 billion). The attacker still holds roughly $2.4 billion, including over 420,000 ETH and 18,270 BTC.
This isn't a code bug. This is a floor problem.
The code worked exactly as designed. EIP-7702 functioned as specified. The sweeper contract was simple and correct. Every smart contract in the chain did what it was supposed to do.
The exposure was structural: how few signatures did it take to move the money — and could one compromised system produce them?
TRM Labs' assessment: the most likely explanation is that the attacker gained the ability to make Binance's hot wallet signing system sign transactions of its choosing across chains. Binance's preliminary investigation found no evidence that a private key leaked, and points to a possibly compromised DevOps engineer's laptop that gave access to a service container used for withdrawals. One access point to the signing infrastructure was enough to sign on several chains at once.
Binance 14 is an EOA. On-chain, one signature authorizes anything it does, so its floor is 1 by construction — whatever policy engine or MPC scheme sits behind that key off-chain. Off-chain controls are a question of independence, and independence can only lower a floor, never raise it: if one compromised system can produce the signature, the controls behind it don't add a second one.
This is the same question the floor asks about DeFi protocols: how few signatures could change the rules under your position?
For Binance's Ethereum hot wallet, the answer was 1. One access point to the signing system was enough to move $6.3 billion across ten chains.
What EIP-7702 changed
Before the Pectra upgrade, a compromised EOA key could send transfers. The attacker could move funds, but only through standard transactions — one transfer at a time, to addresses of their choosing.
After Pectra, a compromised key can do something fundamentally different: replace the wallet's execution logic. The EOA becomes a smart contract. The attacker doesn't just move money — they install code that moves all money, automatically, including funds that arrive after the initial attack.
This is why the Binance hack continued for over an hour after the first sweep. The delegation persisted. New deposits kept flowing into Binance 14 from Binance's own routing systems. The sweeper contract drained them on arrival.
EIP-7702 didn't create the vulnerability — the compromised signing infrastructure did. But EIP-7702 amplified the impact catastrophically. It turned a key compromise into a code replacement — and the replacement stays until the wallet's key signs it away.
In floor terms: EIP-7702 doesn't change the floor of a single-key EOA — that was always 1. It changes what a floor of 1 can do. Before Pectra, one signature could move funds. After Pectra, one signature can install arbitrary code. The attack surface expanded from "unauthorized transfer" to "unauthorized code deployment."
The floor question for every crypto custody setup
The floor was designed to measure DeFi protocol dependencies: who controls the upgrade authority, the oracle, the governance mechanism — and how few signatures could change the code under your position?
The Binance hack shows that the same question applies to custody infrastructure:
How few signatures can move your hot wallets — and can one compromised system produce all of them?
If one signing system, one infrastructure access point, one engineer's laptop can produce the signature, your floor is 1. And after EIP-7702, a floor of 1 on Ethereum doesn't only mean someone can send your funds somewhere. It means someone can replace the code your wallet runs.
Consider two custody setups:
Setup A: The hot wallet is a single-key EOA, signed by one infrastructure. One compromised access point can sign transactions across chains. Floor = 1.
Setup B: The hot wallet is an on-chain 3-of-5 multisig whose signers run on separate infrastructure, separate networks, separate signing interfaces, separate geographic locations. The chain shows three signatures; the separation keeps them from collapsing into one. No single compromised point can produce a valid transaction. Floor = 3.
The Binance hack exploited Setup A. Setup B would have required compromising three separate systems — a fundamentally harder attack.
But Setup B is only as strong as its separation. In February 2025 the same group took over $1.5 billion from Bybit's Ethereum cold wallet — a Safe multisig that needed several signers to approve any transaction. A compromised Safe{Wallet} developer machine let the attackers inject malicious JavaScript into the signing interface Bybit's signers used. It masked what they were approving, and they signed. Several signatures, one compromised interface: the multisig behaved like a floor of 1. That is what "independence can only lower a floor" means in practice — separate keys don't help if every signer reads the transaction through the same screen.
What this means for DeFi positions
If you hold positions in DeFi protocols, the Binance hack reinforces something the floor has been measuring from the start:
The fewest signatures that can change the rules under your money is the number that matters. Not the audit status. Start from what the chain shows — the upgrade authority, the multisig threshold, the governance quorum — and lower it wherever those signers turn out to share an owner or a system.
EIP-7702 adds a new dimension to this measurement. Any DeFi protocol that uses EOA wallets for administrative functions — oracle updates, parameter changes, emergency pauses — now has a wider attack surface than it did before Pectra. A compromised admin key doesn't just allow a parameter change. It allows arbitrary code execution under that address.
For protocols on Ethereum: the floor calculation now needs to account for the EIP-7702 delegation surface. An admin EOA with a floor of 1 is not just a key risk — it's a code replacement risk.
On Solana, none of this is new. An upgradeable program's code can be replaced by a single signature from its upgrade authority — EIP-7702 gives Ethereum EOAs what a Solana upgrade authority has always been. In our Q3 2026 census, 49% of the 100 most-invoked Solana programs were upgradeable by a single keypair rather than an on-chain multisig: a floor of 1 at the program itself, before oracles or governance are even counted. (A single keypair on-chain may sit behind MPC custody off-chain; the chain can't tell the difference.)
The dashboard vs. the feed
One detail makes this hack structurally different from previous exchange breaches: the delegation persisted. Funds routed to Binance 14 after the first sweep were swept again at 21:04 and 21:44 UTC, because the EIP-7702 authorization remained active.
Be precise about what the floor could and couldn't have done here. Measured the day before, Binance 14 would have read floor 1 — as does every exchange hot wallet that is an EOA. The number wouldn't have predicted this attack: the failure was in off-chain signing infrastructure, which no on-chain measurement can see. And once the outflows began, Binance didn't lack data; the later sweeps were an incident-response problem.
Where continuous measurement matters is downstream, for the people whose money sits on top of someone else's keys. If you hold a position in a protocol whose admin, oracle-updater or pauser key is an EOA, a delegation on that key changes what can happen to your position. It is visible on-chain the moment it lands — an address that had no code suddenly has some — and it is the kind of event a position holder needs to hear about within minutes, not at the next quarterly review.
This is why the floor needs to be a feed, not a dashboard. A dashboard that shows "floor = 1" is a description. A feed that alerts "the admin key under your position was just delegated to unknown code" is an intervention point.
The audit verified that the code worked. The floor tells you who controls it. And after EIP-7702, "who controls it" can change in a single transaction — without anyone's permission.
Sources
- TRM Labs — North Korea steals USD 6.36 billion from Binance
- crypto.news — Binance hack: the EIP-7702 wallet attack
- drk.vc — Binance 14 EIP-7702 drain
- BleepingComputer — Lazarus hacked Bybit via a breached Safe{Wallet} developer machine