The Binance Hot Wallet Drain: How One EIP-7702 Delegation Can Empty a Wallet

On Thursday afternoon, billions of dollars in crypto left Binance hot wallets on several chains in under an hour. The interesting part for developers isn't the size. It's the mechanism: on Ethereum, one of Binance's main hot wallets had its account code set through EIP-7702, the Ethereum feature that lets an ordinary wallet run smart-contract code. Once that delegation was in place, a contract the attacker deployed could move the wallet's funds.

I've already written about rotating API keys after a breach and scoping AI agent permissions. This is the same lesson with much higher stakes: a signing permission is only as safe as the narrowest thing it can authorize.

All times are Central (CDT) on October 29, 2026.

• 3:20:59 PM CDT: an address that Decrypt and several on-chain analysts say was funded through Tornado Cash sent an EIP-7702 transaction to the Binance hot wallet that Etherscan labels "Binance 14" (0x28c6...1d60). I checked this one on-chain myself: the transaction (0xad99...298b, block 26,300,753) carries 50 authorizations, every one recovers to Binance 14's own address, and all 50 point at the same contract (0x63e8...6fae).
• 3:24 PM CDT: per Decrypt, the first drain transaction sent 167,464 ETH plus 63 token transfers, including 1.615 billion USDT, to a brand-new address.
• Not just one wallet: according to Blockaid, within 12 minutes of that first drain, 10 more Binance hot wallets on four chains sent funds to the same attacker address. Binance 14 is the only one taken over with EIP-7702. Per 808bits' analysis, the others signed plain outgoing payments, which points at the system that signs for Binance's wallets rather than one stolen key.
• Binance's own numbers: in a security incident update on Thursday night, Binance put the estimated total impact at about $6.3 billion, with about $3 billion frozen on-chain so far with help from blockchain partners. Earlier outside tallies were lower because they counted fewer chains: Decrypt counted at least $5.57 billion across Ethereum, Bitcoin and Tron, and CoinDesk, citing Arkham, reported more than $5.7 billion.
• Freezes: Tether CEO Paolo Ardoino said Tether "froze more than 1.567B USDT", and Circle CEO Jeremy Allaire said Circle had frozen "more than 800M USDC". CNBC reports that Ripple said it was freezing affected RLUSD. Binance's roughly $3 billion figure is its own total across all of them.
• What Binance says happened: its "initial investigation suggests that the security incident may involve a compromised DevOps engineer's laptop, which allowed an attacker to gain access to a service container and submit unauthorized withdrawal transactions." It says it has "found no evidence of any wallet private key leak" and will publish a detailed technical post-mortem.
• What Binance is doing: it says it will cover all losses from its SAFU fund and company funds, that user funds are safe, and that it has suspended deposits and withdrawals, revoked the affected address authorization and brought in law enforcement. CNBC reports co-founder Yi He expects withdrawals to begin resuming within 48 hours.
• The delegation is gone now: an eth_getCode read I ran on Binance 14 at about 12:30 AM CDT Friday returned empty code, so the attacker's contract no longer runs there. Per 808bits' on-chain timeline, Binance cleared it at 7:10 PM CDT Thursday with an authorization pointing at the zero address, almost four hours after it was set.
• Who: per the BBC, TRM Labs and Chainalysis have linked the attack to TraderTraitor, a North Korean hacking unit. Binance hasn't named anyone.
• Still unanswered: how a compromised path for submitting withdrawals ended up getting Binance 14's key to sign EIP-7702 authorizations. That's the question the post-mortem needs to answer.

The BBC and CNBC both describe it as the biggest crypto hack on record. The previous record, per both, was the roughly $1.5 billion Bybit hack in 2025.

EIP-7702 ("Set Code for EOAs") is a finalized Ethereum standard. Its stated goals are batching, sponsored transactions, and what it calls privilege de-escalation: letting a wallet hand narrow permissions to sub-keys. Here's how it works, straight from the spec:

1. A new transaction type (0x04, the "set code transaction") carries an authorization_list. Each entry is [chain_id, address, nonce, y_parity, r, s].
2. Each entry is signed by the wallet being changed. The protocol recovers the signer, called the authority, from a signature over keccak(0x05 || rlp([chain_id, address, nonce])). The nonce must match the authority's current nonce, and chain_id must be the current chain or 0, which means any chain.
3. Anyone can submit it. The outer transaction is signed and paid for by whoever sends it. That's the sponsorship feature, and it's why an outside address could deliver Binance-signed authorizations.
4. It writes a delegation indicator into the wallet's code: 0xef0100 followed by the delegate's address. From then on, calls to the wallet run the delegate contract's code in the wallet's own context, with the wallet's balance.
5. It persists. The EIP's own summary says it "permanently sets the code for an EOA." The delegation stays until another signed authorization replaces it, or one pointing at the zero address clears it. It is not rolled back even if the rest of the transaction fails.

The security section of the EIP is blunt: "A poorly implemented delegate can allow a malicious actor to take near complete control over a signer's EOA." It also warns that changing an account's delegation "is a security-critical operation that should not be done lightly."

So EIP-7702 didn't skip Binance's signature. It needed one. As far as the chain shows, the problem is that a signature from Binance's key authorized the wallet to run someone else's code. In plain terms: one signature turned a wallet into a program, and whoever controlled that program controlled the wallet.

You don't need to run an exchange for this to apply. If your software holds a key that signs anything (blockchain transactions, JWTs, webhooks, cloud API requests, deploys), the same rules hold.

A signing service that only expects to sign withdrawals should refuse anything else. With EIP-7702, an authorization is a different message format (it starts with the 0x05 magic byte), and it grants far more than any single transfer. Allowlist message types at the signer, and reject the rest by default. Binance's preliminary finding makes this the lesson that matters most: it says an attacker got into a service container and submitted withdrawal transactions, with no sign the private key itself leaked. If that holds, the key stayed put and the system around it signed what it was handed.

A hot wallet that can sign "change what code this account runs" holds the most powerful permission there is. Split duties: the key that pays out withdrawals shouldn't be able to re-delegate the account, rotate its own controls, or approve unlimited token spending. If one key can do everything, one leak loses everything.

A 7702 delegation, an unlimited ERC-20 approval, a long-lived API token and a refresh token all have the same shape: one signature, then many actions later with no further checks. The 50 authorizations in this case covered 50 consecutive nonces, which looks like someone planning for the wallet's nonce to move. Anything signed ahead of time should be short-lived, scoped and revocable, and you should know how to revoke it before you need to.

Hardware security modules, multi-party computation and policy engines exist so the application never holds the raw key, and so a human or a second system has to approve unusual requests. Hot wallets need some automation. They don't need a signer that will sign whatever it's handed.

Most monitoring alerts on large outflows. By then it's too late. The setup transaction came about three minutes before the first drain transaction. Alert on:

• any change to your accounts' code (an EIP-7702 delegation shows up as 0xef0100... from eth_getCode);
• new or unlimited token approvals;
• transactions to your wallets from addresses you've never seen;
• new contracts deployed by addresses with mixer funding, if you track that.

The off-chain version is the same: alert on new OAuth grants, new API keys, new deploy keys and permission changes, not only on data leaving.

Tether and Circle could freeze tokens because their contracts have an admin freeze. Your own system needs an equivalent, and it needs to be fast. A delegation that stays live for hours keeps catching new deposits. Have a rehearsed way to pause withdrawals, revoke delegations and approvals, and rotate keys in minutes. My key rotation runbook covers the API-key side.

• Binance's root cause is preliminary. Its own words are "suggests" and "may involve", and the technical post-mortem isn't out. "Signed by Binance's key" describes what the chain shows. How a withdrawal path came to sign EIP-7702 authorizations hasn't been explained yet.
• Totals differ by source and by what each counts (one wallet, one chain, or every chain). Binance's $6.3 billion is its own estimate. I've attributed each figure and haven't averaged or rounded them together.
• Freeze figures come from Binance's and the issuers' own statements and may still change.
• The North Korea link comes from TRM Labs and Chainalysis, as reported by the BBC. No government agency has announced an attribution that I've seen.

EIP-7702 lets a wallet's owner sign a message that makes the wallet run someone else's code, and that setting persists. On October 29, Binance-signed authorizations delegated a major hot wallet to an attacker's contract that then swept it. Binance's early finding points to a compromised engineer laptop that reached a service able to submit withdrawals, not a leaked private key. For developers, the lessons hold whatever the root cause turns out to be: know everything your keys can sign, scope them tightly, keep them out of reach of your app code, and alert on new delegations and approvals before the money moves.

• EIP-7702: Set Code for EOAs (Ethereum Improvement Proposals) (read 5:20 PM CDT Oct 29, 2026)
• Decrypt, "Binance Drained of $5.5 Billion in Suspected Hack, Tether and Circle Freeze $1.8 Billion"
• CoinDesk, "Binance loses $5.7 billion in largest crypto hack to date" (updated 5:13 PM CDT)
• CNBC, "Biggest-ever crypto hack impacts $6.3 billion as Binance works to contain fallout"
• Cointelegraph, "Binance investigates potential multibillion-dollar hack"
• Binance on X, statement (last edited 4:29 PM CDT)
• Binance on X, withdrawals update (5:15 PM CDT)
• Changpeng Zhao on X (4:15 PM CDT)
• Paolo Ardoino (Tether) on X (4:25 PM CDT)
• Jeremy Allaire (Circle) on X (4:18 PM CDT)
• Binance, "Security Incident Update" (October 29, 2026)
• BBC, "Crypto giant Binance hit by 'largest hack in history'"
• Blockaid, "Binance $5.5B Hack" analysis
• 808bits, "Binance hot wallet signed 50 EIP-7702 delegations 3 minutes before the drain"
• Etherscan, EIP-7702 setup transaction
• Etherscan, Binance 14 hot wallet