Binance $6.3B hack explained: how EIP-7702 delegation emptied a hot wallet, and how to guard your signer

On 29 October 2026 attackers took roughly $6.3 billion out of Binance's hot wallets in about four hours, across ten chains. The largest single drain used no stolen private key and no contract bug: a Binance Ethereum hot wallet had signed 50 EIP-7702 authorizations that pointed it at the attacker's sweeper contract, and one transaction at 20:20 UTC put them on chain (TRM Labs).

This article explains what Binance has confirmed, how EIP-7702 delegation works at the protocol level, why fifty signatures for consecutive nonces were enough to empty the wallet, and the checks a signing service and a monitoring job should run so a request like that is refused. It is written for engineers who run or build anything that signs transactions on behalf of a service, not only exchanges.

What has Binance said about how the hack happened?

Binance's incident update says its initial investigation suggests the incident may involve a compromised DevOps engineer's laptop, which the attacker used to reach a service container and submit unauthorised withdrawal transactions. It found no evidence that wallet private keys leaked, revoked the affected address authorization and suspended withdrawals.

A day later Binance said it had "uncovered additional points of breach" (Binance on X). Co-CEO Richard Teng wrote that the attacker "did not simply use one engineer's permissions" and that this was not a one-click action (Teng on X). CoinDesk reports that the attackers used EIP-7702 to take control of a hot wallet "without going through Binance's normal approval procedures", used a self-destruct mechanism to erase evidence, and that Binance is reviewing transaction signing, key management, cloud systems and employee devices. A full post-mortem has been promised but not yet published.

So the honest summary is: entry through an engineer's machine, then something inside Binance's withdrawal and signing path produced signatures the attacker wanted. TRM's assessment is that a compromise of the hot-wallet signing infrastructure is the most likely explanation, because phishing would explain the Ethereum activity but not the nine other chains drained the same evening (TRM Labs).

What is EIP-7702, and what does a delegation authorization let someone do?

EIP-7702, shipped in Ethereum's Pectra upgrade in May 2025, lets an ordinary externally owned account (EOA) point its code at a smart contract. Once set, any call to the EOA runs that contract's code in the EOA's context: its balance, its storage, its token holdings (EIP-7702).

The permission is a signed tuple [chain_id, address, nonce]. The account signs keccak(0x05 || rlp([chain_id, address, nonce])), and the tuple travels in the authorization_list of a new transaction type, 0x04. The important detail for this incident is that anyone can submit a signed tuple and pay its gas; the account that signed it does not have to send anything.

When a type-4 transaction is processed, each tuple is checked and applied on its own:

1. The chain ID must be 0 or the current chain. A chain ID of 0 makes the authorization valid on every EVM chain that implements the EIP.
2. The signer is recovered with ecrecover, and its code must be empty or already a delegation.
3. The tuple's nonce must equal the signer's current account nonce; if not, the tuple is skipped and processing moves to the next one.
4. The signer's code is set to 0xef0100 || address, and its nonce goes up by one. An address of zero clears the delegation instead.

The specification is blunt about the consequence: the delegated code has unrestricted access to the account, and "there is no safe way to provide this interface" for asking users to sign arbitrary authorizations (EIP-7702). An authorization carries no amount and no recipient. It hands over the whole account.

How 50 pre-signed authorizations emptied the Ethereum hot wallet

A busy exchange hot wallet sends withdrawals all day, so its nonce moves constantly. An attacker cannot know which nonce the wallet will be on when their transaction lands. The fix was to get signatures for fifty consecutive nonces, 18,914,775 to 18,914,824, all delegating to the same sweeper contract (TRM Labs, Tibane Labs via PandaSecurity). Whichever nonce the wallet had reached at 20:20:59 UTC matched one tuple; the others were simply skipped.

About three and a half minutes later the operator called the sweeper, which checks that only the hard-coded operator address can call it, and moved 167,464 ETH and 63 tokens including 1.615 billion USDT to an attacker address. The delegation stayed in place for nearly four hours, so the attacker swept new deposits as Binance's own automation topped the wallet up, at 20:41, 20:59, 21:04, 21:44, 22:39 and 23:56 UTC (TRM Labs). The wallet cleared it at 00:10:35 UTC on 30 October by sending a type-4 transaction delegating to the zero address (PandaSecurity).

The sweeper also had a general execute(target, value, data) function. Because the drained wallet was the executor for a separate Binance smart account, the attacker could make it instruct that account to release 823 million USDC (TRM Labs, PandaSecurity). Delegation turns every permission the EOA holds elsewhere into the attacker's permission too.

Which chains lost the most?

EIP-7702 explains the biggest single drain, not the whole night. Between 20:05 and 23:05 UTC, Binance wallets on the XRP Ledger, Bitcoin, Tron, Solana, Optimism, Avalanche and Polygon also sent their balances to attacker addresses with ordinary signed transfers, and a second Ethereum hot wallet sent 28,006 ETH the same way (TRM Labs). That spread is why TRM points at the signing infrastructure rather than one tricked approver.

How a hot-wallet signer should refuse delegation requests

If a hot wallet has no reason to delegate, the signer should never produce a type-4 authorization for it. If it does need delegation, the target should come from a short allowlist that changes only through a separate, multi-party approval, and a request for many authorizations covering a run of future nonces should be treated as an attack, because no legitimate flow needs one.

Here is that policy as a small, dependency-free check to run in the signer before any key material is touched. The example at the bottom replays the shape of the 29 October request.

// A pre-signing check for a hot-wallet signer. Run it on every request before the key is touched.const ALLOWED_DELEGATES = new Set([]); // empty: this wallet never delegates export function reviewSigningRequest(req) {  const problems = [];  if (req.kind === "eip7702-authorization") {    for (const auth of req.authorizations) {      if (!ALLOWED_DELEGATES.has(auth.address.toLowerCase())) {        problems.push(`delegation to ${auth.address} is not on the allowlist`);      }      if (auth.chainId === 0n) problems.push("chain_id 0 makes the authorization valid on every chain");    }    if (req.authorizations.length > 1) {      const nonces = req.authorizations.map((a) => a.nonce).sort((a, b) => (a < b ? -1 : 1));      const consecutive = nonces.every((n, i) => i === 0 || n === nonces[i - 1] + 1n);      if (consecutive) problems.push(`${nonces.length} authorizations for consecutive nonces ${nonces[0]}..${nonces.at(-1)}`);    }  }  return { allow: problems.length === 0, problems };} // The shape of the request seen on 29 October: 50 authorizations, one delegate, nonces in a row.const batch = Array.from({ length: 50 }, (_, i) => ({  chainId: 1n,  address: "0x63e842b054bd624a465454d533c33f573e9c6fae",  nonce: 18_914_775n + BigInt(i),}));const verdict = reviewSigningRequest({ kind: "eip7702-authorization", authorizations: batch });console.log(verdict.allow ? "SIGN" : "REFUSE");console.log(verdict.problems.slice(0, 1).concat(verdict.problems.slice(-1)).join("\n"));

$ node signing-policy.mjsREFUSEdelegation to 0x63e842b054bd624a465454d533c33f573e9c6fae is not on the allowlist50 authorizations for consecutive nonces 18914775..18914824

Put the check where the attacker cannot route around it: inside the signing service or HSM policy layer, not in the withdrawal service that calls it. In this incident the withdrawal path itself was the compromised component, and CoinDesk reports the attackers bypassed the normal approval procedures (CoinDesk).

How to detect an EIP-7702 delegation on your own wallets

A delegated EOA has 23 bytes of code: 0xef0100 followed by the delegate's address. A plain EOA returns 0x from eth_getCode. Polling your hot wallets for that change, every block or every few seconds, turns a four-hour sweep window into an alert within a block or two, and the remedy is the same one Binance used: send a delegation to the zero address and pause the automation that refills the wallet.

// Usage: RPC_URL=https://your-node node check-delegation.mjs 0xHotWallet [0xAnother ...]const RPC_URL = process.env.RPC_URL;if (!RPC_URL) throw new Error("Set RPC_URL to an Ethereum JSON-RPC endpoint"); // EIP-7702 delegation indicator: 0xef0100 followed by the 20-byte delegate address.export function parseDelegation(code) {  const hex = code.toLowerCase();  if (hex === "0x") return { state: "plain EOA" };  if (hex.startsWith("0xef0100") && hex.length === 2 + 2 * 23) {    return { state: "DELEGATED", to: "0x" + hex.slice(8) };  }  return { state: "contract code" };} async function getCode(address) {  const res = await fetch(RPC_URL, {    method: "POST",    headers: { "content-type": "application/json" },    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method: "eth_getCode", params: [address, "latest"] }),  });  const { result, error } = await res.json();  if (error) throw new Error(`${address}: ${error.message}`);  return result;} let alarm = false;for (const address of process.argv.slice(2)) {  const verdict = parseDelegation(await getCode(address));  if (verdict.state !== "plain EOA") alarm = true;  console.log(address, verdict.state, verdict.to ?? "");}process.exit(alarm ? 1 : 0);

$ RPC_URL=http://127.0.0.1:8545 node check-delegation.mjs 0x1111111111111111111111111111111111111111 0x22222222222222222222222222222222222222220x1111111111111111111111111111111111111111 plain EOA 0x2222222222222222222222222222222222222222 DELEGATED 0x63e842b054bd624a465454d533c33f573e9c6fae$ echo $?1

Contract authors have a related job. EIP-7702 means an EOA can now have code, so checks like tx.origin == msg.sender or extcodesize(caller) == 0 no longer prove the caller is a simple key-holding wallet; the specification lists this break explicitly (EIP-7702). Any privilege granted to an EOA, such as being the executor of another account, is now reachable by whatever code that EOA delegates to.

How this compares with the Bybit hack

The pattern repeats: an engineer's workstation is the way in, and the thing that fails is a signing step that trusted its caller. Hardware wallets, multi-party approval and cold storage all assume the request reaching them is honest. Both incidents show that the request is the attack surface.

The one thing to remember: in a post-Pectra world, an EIP-7702 authorization is a full transfer of control, so treat a request to sign one as you would a request to export the key, and refuse it unless a separate, human-approved policy says otherwise.

Sources and further reading

• Binance: Security incident update and update on additional breach points
• TRM Labs: North Korea steals $6.36 billion from Binance, timeline, per-chain amounts and freezes
• Ethereum: EIP-7702: Set code for EOAs
• PandaSecurity: How EIP-7702 delegation emptied a hot wallet, citing Tibane Labs' on-chain analysis
• CoinDesk: Binance uncovers wider breach
• Chainalysis: Binance exploit, latest findings and Elliptic: Binance, the largest hack in history
• The Hacker News: Binance suffers security breach; The Block: first report of the outflows
• Aikido: How a developer laptop can put $6.3B in play
• Discussion: Hacker News thread