Back

03/11/2026

How One Signature Kept Draining Binance’s Hot Wallet: The EIP-7702 Delegation Behind the Breach

50 pre-signed EIP-7702 authorisations, one match, and a delegation that outlived the empty wallet. How it worked and what hot-wallet operators should monitor.

In our first article on the Binance breach, we looked at how the attack reportedly began: a compromised DevOps laptop, and attackers who reached the systems that approve sensitive actions. On-chain analysis by the security firm Blockaid has since shown how the final stage worked on Ethereum. It used EIP-7702, a feature added to Ethereum in May 2025, and it shows a risk that many hot-wallet operators have not yet planned for.

The short version: one signed authorisation turned Binance’s largest Ethereum hot wallet into an account the attacker could control. That control did not end when the wallet was empty, and it would not have ended with a key rotation either.

Key takeaways

  • The attacker packed 50 pre-signed EIP-7702 authorisations, covering 50 consecutive nonces, into one transaction; exactly one matched and handed the wallet’s execution to the attacker’s contract.
  • An EIP-7702 delegation stays in place until the account replaces or clears it. Deposits that arrived after the first sweep, more than $200 million at one point, were taken without any new signature.
  • Rotating the private key does not remove a delegation, because it belongs to the address. Only an explicit revocation clears it.
  • How the attacker obtained 50 valid signatures is still open. Binance says it has found no evidence of a private key leak.
  • Hot-wallet operators should monitor delegation state, refuse to sign authorisations they did not intend, and put explicit revocation into their incident-response runbooks.

A quick primer on EIP-7702

EIP-7702 lets an ordinary Ethereum account (an externally owned account, or EOA) delegate its execution to a smart contract. The account owner signs an authorisation that names a contract address, the chain and the account’s current nonce. Once a transaction carrying that authorisation is processed, calls to the account run the contract’s code, as if the account were a smart contract wallet. The feature exists for legitimate reasons, such as batching transactions and paying fees on a user’s behalf.

Three details from the specification matter for this incident:

  • Authorisations travel in a new transaction type, type 4 (0x04), which can carry a list of them. Anyone can submit the transaction; the authorisation only needs a valid signature from the account.
  • Each authorisation is valid only if its nonce equals the account’s current nonce. If it does not match, that one authorisation is skipped, and the transaction continues with the next one.
  • The delegation is persistent. It stays until the account signs a new authorisation that points somewhere else, or one that points to the zero address, which clears it.

How the Binance 14 wallet was taken over

A busy exchange hot wallet sends transactions constantly, so its nonce keeps moving. An attacker preparing a signed authorisation in advance cannot know which nonce will be current when the transaction lands. According to Blockaid’s analysis, the attacker solved this by signing a window instead of a single value.

Time (UTC, October 29)What happened
15:59The attacker deploys a “sweeper” contract. It is unverified, and only the attacker’s operator address may call it.
20:20:59A single type-4 transaction carries 50 EIP-7702 authorisations, all signed with the key of the Binance 14 hot wallet, for 50 consecutive nonces. Exactly one matches the wallet’s live nonce, and the wallet is now delegated to the sweeper.
20:24:23One call to the sweeper moves about 167,464 ETH, 1.615 billion USDT and dozens of other tokens out of the wallet, leaving 1 ETH for fees.
20:41Still delegated, the wallet is used to move about 823 million USDC from a separate smart account that Binance 14 controlled.
21:04 to 23:56The wallet is swept four more times as new funds arrive. At 21:44 alone, more than $200 million in fresh deposits is taken with no new signature.
00:10 (October 30)The delegation is revoked, according to Hypernative’s timeline.

The USDC step shows a second effect. A delegated account keeps every role it holds in other contracts: owner, executor, approved spender. Whoever controls its execution can use all of them.

Why an empty wallet was still dangerous

After a theft, the natural assumptions are that an empty wallet has nothing left to lose and that a new key ends the attacker’s access. With EIP-7702, both are wrong. The delegation is attached to the address, not to the balance or to a particular copy of the key. As long as it is in place, anything sent to the address can be swept by the delegated contract, and the attacker needs no further signature.

That is what happened here. Funds kept arriving at Binance 14 after the first sweep, and they were swept again. Rotating the key would not have helped: as Blockaid points out, clearing the delegation requires a new authorisation from the same account, pointing to the zero address. Until that revocation is processed, the address should be treated as controlled by the attacker.

Tip: In an incident, revoke first, then rotate keys and refill. Stop every automated process that sends funds to the affected address until you have confirmed the delegation is gone.

What is still unresolved

All 50 authorisations carried valid signatures from the Binance 14 key. There are two broad explanations, and the public evidence does not yet decide between them:

  • The key was leaked, and the attacker signed the authorisations directly.
  • The signing infrastructure was abused: the attacker got Binance’s own signing systems to sign payloads of the attacker’s choosing without ever extracting the key.

Binance has said it has found no evidence of a wallet private key leak, and its investigation is ongoing. Blockaid’s CEO told Cointelegraph that the activity looks like a compromise of signing infrastructure rather than a leaked key, but that is a preliminary outside assessment. Until Binance publishes its post-mortem, we treat the question as open.

What to do if you operate hot wallets

1. Monitor delegation state

A delegated account has code. Under EIP-7702, its code is the delegation indicator 0xef0100 followed by the 20-byte address of the contract it delegates to. An ordinary EOA has no code at all. You can check any address with a standard JSON-RPC call:

curl -s -X POST -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["0xYOUR_HOT_WALLET","latest"]}' \
  https://YOUR_RPC_ENDPOINT

A result of 0x means no delegation. A result starting with 0xef0100 means the address is delegated. Check this for every hot wallet on every block or at short intervals, and alert immediately on any change you did not plan.

2. Watch type-4 transactions that involve your addresses

The transaction that delegates your wallet does not have to come from your wallet. Anyone can submit it, as long as it carries a valid authorisation signed by your key. Monitor type-4 transactions whose authorisation list contains a signature from one of your addresses, not only transactions sent from them.

3. Keep an inventory of delegations

For each address you operate, record whether it should be delegated at all and, if so, to which audited contract. Any delegation outside that list is an incident. If you do not use EIP-7702, the expected state of every hot wallet is simple: no code.

4. Refuse unexpected authorisations at the signer

An EIP-7702 authorisation has its own signing format: the hash of the byte 0x05 followed by the encoded chain ID, contract address and nonce. Signing services and HSM policies can recognise this format. If you do not use delegations, block these payloads entirely; if you do, allow only known contract addresses. Also note that an authorisation with chain ID 0 is valid on every chain.

5. Put explicit revocation in your incident-response runbook

Write down how to revoke a delegation for each wallet: who signs the zero-address authorisation, from which system, and how you confirm it took effect (the address’s code is 0x again). Include stopping inbound transfers to the affected address, and practise the procedure before you need it.

Tip: The same idea applies outside crypto. Any grant that outlives the credential that created it, such as an OAuth refresh token, a delegated cloud role or a long-lived CI/CD token, needs its own explicit revocation step in incident response.

How LOGIQ can help

LOGIQ helps organisations review who and what can act with authority across their Linux servers, cloud accounts and pipelines, and build monitoring and incident-response steps that cover delegated access, not only passwords and keys. If you would like a second look at your own controls, read our first article on the breach above or get in touch through our website.

Sources