EIP-7702 and hot wallets: what the $6.3B Binance hack teaches about signing infrastructure

On October 29, 2026, about $6.3 billion left Binance hot wallets on ten chains in roughly half an hour. On Ethereum, the biggest part, the attacker did not need a single raw transfer signed by Binance: one EIP-7702 authorization turned an exchange hot wallet into an account that obeyed the attacker's contract. If you run any service that signs Ethereum transactions from an EOA, this post covers what happened on-chain, why 7702 authorizations need their own controls, and a checklist for your signer.

Figures and timeline below come from the TRM Labs analysis and the Chainalysis update as of October 30–31, 2026. Binance has not published a root cause yet.

EIP-7702 in two minutes

EIP-7702 shipped with the Pectra upgrade on May 7, 2025. It adds transaction type 0x04 (SET_CODE_TX_TYPE) with an authorization_list:

authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
msg = keccak(0x05 || rlp([chain_id, address, nonce]))

When a tuple is valid, the protocol writes a delegation indicator 0xef0100 || address into the code of the signing EOA (the authority) and increments its nonce. From then on, calls to the EOA execute the code at address in the EOA's context. Key properties from the spec:

• It persists. The delegation stays until another authorization replaces it; an authorization to the zero address clears it. It is not rolled back even if the transaction itself fails.
• Anyone can submit it. The authorization is signed by the EOA, but the type-4 transaction carrying it can be sent by any account. The EOA does not need to send anything itself.
• The nonce must match exactly. Step 6 of the spec: "Verify the nonce of authority is equal to nonce." A tuple with a stale nonce is skipped, not rejected.
• chain_id = 0 means every chain. "When universal deployment is preferred, simply set chain ID to 0."
• The delegate has full control. "The code specified by an authorization has unrestricted access to the account."

The spec is blunt about wallets: "Applications must not expect that they can suggest the user sign an authorization", and "There is no safe way to provide this interface".

What happened on Ethereum

According to TRM:

1. Staging. About 36 hours before the theft the operator wallet was funded with small Tornado Cash withdrawals. The attack code was tested on two wallets, then rehearsed on a third.
2. Fifty authorizations. The attacker held 50 pre-signed 7702 authorizations for the same hot wallet, covering 50 consecutive nonces. A busy exchange hot wallet sends transactions constantly, so its nonce moves; with 50 candidates, one would still match when the attack transaction landed. "One matched."
3. Delegation to a sweeper. The authorization pointed the hot wallet to a contract that "accepts instructions only from the operator". About three and a half minutes later the first sweep took 167,464 ETH and 63 tokens, including 1.615 billion USDT.
4. Re-sweeps. Because the delegation persisted, new deposits arriving at the hot wallet were swept again, six more times over the next few hours.
5. Smart account executor. The same hot wallet was the executor of a Binance smart account, which let the attacker also pull 823 million USDC.

On the other nine chains (Bitcoin, Tron, XRP Ledger, Solana, Arbitrum, Optimism, Base, Avalanche, Polygon) the wallets simply signed ordinary transfers to attacker addresses. TRM's reading: wallets with "different chains, key types and signing schemes" all signed for the attacker within about half an hour, which "points to a compromise of Binance's hot wallet signing infrastructure", and the batch of 50 signatures suggests access "may have been limited in time, or that signatures had to be requested through a system". Binance's initial statement mentioned a compromised DevOps engineer's laptop and "no evidence of any wallet private key leak".

The key lesson for builders: the keys may never have left the HSM or signer. The signer was asked to sign, and it signed.

Why a 7702 authorization is not "just another signature"

A signing service usually reasons about transactions: destination, value, calldata, limits per period. A 7702 authorization is different:

• it has no value and no destination to check against a limit;
• it is not a transaction, so a policy engine that only inspects transactions may not see it at all;
• one signature gives the delegate control over all current and future assets of the account, until revoked;
• it can be pre-signed for future nonces and kept for later, so a short window of access becomes a long-lived capability.

In other words, for a custodial EOA, signing a 7702 authorization is equivalent to handing over the key.

Checklist for anyone who signs from an EOA

In the signer:

• Refuse EIP-7702 authorizations by default. If your product does not use smart-account features, the signer should have no code path that produces the 0x05 || rlp([chain_id, address, nonce]) digest at all.
• If you do need delegation, allow-list the exact delegate address, never accept chain_id = 0, and require a separate approval path with human sign-off.
• Never sign an authorization for a nonce other than the account's current nonce. A request for a range of future nonces is an indicator of compromise, not an edge case.
• Treat any raw-digest signing endpoint ("sign these 32 bytes") as equivalent to key export. Sign only structured, decoded requests that your policy engine understands.
• Separate signing infrastructure by chain and wallet tier, so one compromised path does not reach every network.

In monitoring:

• Alert on any change of code at your EOAs. eth_getCode on a plain EOA returns 0x; a delegated one returns 23 bytes starting with 0xef0100.
• Watch for type-4 transactions that include your addresses as authorities, sent by anyone.
• Have a pre-signed or ready-to-sign authorization to the zero address for each hot wallet, so you can clear a delegation in one transaction during an incident.
• Keep hot wallet balances small and refill from cold storage on a schedule: a persistent delegation keeps sweeping every new deposit.

In incident response:

• Stablecoin issuers can freeze; native ETH and BTC cannot. In this case Tether, Circle, Ripple and others froze about $2.7 billion within hours, while more than 420,000 ETH and 18,270 BTC remained with the attacker, per TRM.
• Have issuer contacts and freeze request templates ready before you need them.

How to check an address today

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["0xYourHotWallet","latest"]}'

"result":"0x" means no code. A result like 0xef0100 followed by 20 bytes means the EOA is delegated to that address, and you should know exactly why.

Takeaways

• EIP-7702 made "sign one message, lose the account" possible for any EOA, including custodial hot wallets.
• Signers must understand authorizations as a separate, high-risk object, not as a transaction or a generic digest.
• Monitoring for code at your own EOAs is one RPC call; it is worth running on every block.

---

Disclosure: we build StarGate, a Telegram bot and web app that swaps Telegram Stars for GRAM, USDT, ETH and BTC; we are not affiliated with Binance. This post was drafted by an AI assistant from the EIP-7702 specification and the TRM Labs and Chainalysis reports linked above, and every quote was checked against those pages.