Binance 14 cleared its EIP-7702 delegation: what the chain proves, and what it does not

At block 26,301,896 the address labelled Binance 14 reset its code to empty with a type-4 transaction. The clear removes the sweeper contract; it does not prove the signing key is safe. A read-only probe for any delegated account.

By the Maborak engineering team · 2026-10-30 · 10 min read

At 00:10:35 UTC on 30 October 2026, the Ethereum account that block explorers label Binance 14 sent a type-4 transaction to itself. Its authorization list held one tuple: delegate to the zero address, nonce 18,914,904. In that block the account’s code changed from 0xef0100 followed by 0x63e8…6fae to 0x. The delegation that swept the wallet three hours and forty-six minutes earlier was gone.

Checked 30 October 2026 at 01:09 UTC, at Ethereum block 26,302,185. The code, transaction and nonce below were read from a public Ethereum node and are marked [reproduced]. Statements by Binance and its founders are marked [vendor]; figures from press reports are [reported]. The investigation is open.

Background

The 29 October post covered the transfers and the mechanism. At 20:20:59 UTC a type-4 transaction from 0x7c86…5ca0 installed an EIP-7702 delegation on Binance 14, pointing at 0x63e8…6fae. Four minutes later a call to the account moved 167,464 ETH and 63 tokens, including 1,615,409,498.97 USDT, to 0x5227…2f8c. The delegation transaction carried 50 authorizations with consecutive nonces; one matched the account’s live nonce. The earlier post has the transaction hashes, the token flow and the freeze timeline.

Binance’s public position changed during the evening. At 21:16 UTC it said it had “not confirmed any impact to user funds”. At 21:29 UTC the same post said “User funds are completely safe.” At 22:15 UTC it said withdrawals would resume once the security issue was resolved; co-founder Yi He said withdrawals were disabled until the environment was confirmed secure. At 23:22 UTC Binance put the “current verified total frozen” at $2.54bn. [vendor] CZ, who no longer runs the exchange, wrote that the incident “does look like a hack on Binance” and that he expected all user funds to be covered. [vendor] Binance has not published a technical post-mortem or said how the authorization was obtained.

The clear came after on-chain researchers had publicly flagged the still-active delegation for more than two hours. Shen Yu, a co-founder of Cobo, wrote that Binance 14 had not revoked it, and pointed at a pending 2,961 ETH transfer to the address. [reported] The revocation transaction is the first on-chain sign that the account was contained.

The clear does not by itself settle the earlier “hack or move” question. It shows the delegation was removed. The issuer freezes, CZ’s statement and the withdrawal pause are the public evidence for a theft; Binance has not published a report that names the cause.

Mechanics

The state before and after

eth_getCode returns the account’s code. A plain account returns 0x; an EIP-7702 delegation returns 23 bytes: 0xef0100 and the 20-byte delegate address. At block 26,301,895, one block before the revocation, Binance 14 returned the delegation. At block 26,301,896 it returned 0x. The revocation transaction is in that block. [reproduced]

The transaction is a type-4 (set-code) transaction. Its fields:

Field	Value
Block	26,301,896, 00:10:35 UTC
From / to	`0x28c6…1d60` / itself
Transaction nonce	18,914,903
Authorization nonce	18,914,904
Authorization delegate	`0x0000000000000000000000000000000000000000`
Status / gas used	success / 36,800

[reproduced]

The nonce difference follows from the order of operations. EIP-7702 processes the authorization list after the sender’s nonce is incremented. A self-sent type-4 transaction therefore signs its authorization at tx.nonce + 1. The authorization clears the code when its address field is zero; the account’s nonce then increments again.

Clearing does not delete the delegate contract at 0x63e8…6fae. The contract still exists; the account no longer points at it. Calls to Binance 14 now execute empty code, so the sweep function is no longer reachable through that account.

What the clear proves

The code can only be set or cleared by an authorization that recovers to the account’s key. EIP-7702 has no admin path and no other signer. The clear therefore proves that, at 00:10:35 UTC, someone could produce a valid signature for the account, or could make the signing system produce one. [inferred] It does not prove who that was. The transaction is consistent with the exchange cleaning up the account; the chain records the signature, not the operator.

It also does not prove the key is safe. An EIP-7702 authorization is a signature over keccak(0x05 || rlp([chain_id, address, nonce])). Anyone who can sign that message at the account’s current nonce can install a new delegation. Clearing the code removes the current pointer. It does not revoke the key, change the address, or stop a second authorization. [inferred], from the specification.

That distinction matters because the public accounts of the cause differ. Blockaid’s preliminary assessment is that the attacker compromised Binance’s transaction-signing infrastructure and did not extract a private key. Arkham’s CEO said there was not enough information to confirm stolen keys versus compromised infrastructure. Binance has not said which. [reported] If only a signing service was tricked and that path is now closed, clearing the delegation may hold. [inferred] If a copy of the key is still available, the next authorization can re-arm the account.

What the numbers mean

Public figures for the incident range from about $2.5bn to $5.9bn. They are not the same measurement. Some count assets that left wallets, some count assets held at addresses linked to the incident, and some count assets frozen. Binance’s only confirmed figure is the frozen total: $2.54bn, which it says may rise. Tether said it froze more than $1.567bn in USDT and Circle more than $800m in USDC; other issuers also froze funds. [vendor] Frozen is not recovered, and native ETH cannot be frozen at all.

Impact

For Binance users, the exchange says user funds are safe and that it will cover the losses. CZ wrote “Loss might be a bit higher than that, but will cover”; Reuters reported Yi He saying “Binance will cover all hacking losses.” [vendor] [reported] Withdrawals were still limited at the check. Binance’s deposit and withdrawal status page listed partial withdrawal suspensions for ETH, USDT, USDC, XRP and SOL, while BTC, BNB and TRX were normal. [vendor] The page changes; check it directly.

For teams running hot wallets, the useful lesson is narrower than the headline. An EOA with 0xef0100 code is executing a contract chosen by whoever signed the authorization. The code can be installed without a visible outgoing transfer, and it persists across deposits. The clear cost 36,800 gas. It is a containment step, not a key rotation. The account’s nonce was 18,915,140 at the check; it had sent transactions after the clear. A cleared code is not a retired account.

For the other wallets named in the incident, the check is per address. Hot Wallet 34 (0xee7a…4055) returned 209 bytes of contract code at the same blocks, so it is a contract, not a delegated EOA; Hot Wallet 16 (0xa180…d947) returned 0x. [reproduced] Neither result says those wallets are safe; it says EIP-7702 delegation is not the state they are in.

Probe

The probe is read-only. It needs Python 3 and a JSON-RPC endpoint that keeps recent state; https://eth.drpc.org served the state at blocks 26,301,895 and 26,301,896 when this was written. Some public endpoints prune or refuse historical state, so a 403 or “historical state not available” is an endpoint limitation, not a chain result.

probe.py:

import json, sys, urllib.request

RPC = "https://eth.drpc.org"
REVOCATION = "0xafbf94c92a8d749988411669fa14d4f8866d9b4420b4ebd299f28e958dac7209"
BEFORE, AFTER = 26_301_895, 26_301_896

def rpc(method, params):
    body = json.dumps({"jsonrpc": "2.0", "id": 1, "method": method, "params": params}).encode()
    req = urllib.request.Request(RPC, body, {"Content-Type": "application/json", "User-Agent": "probe"})
    with urllib.request.urlopen(req, timeout=30) as response:
        payload = json.load(response)
    if "error" in payload:
        raise RuntimeError(payload["error"])
    return payload["result"]

def describe(address, block):
    code = rpc("eth_getCode", [address, block])
    if code == "0x":
        return "empty"
    if code.startswith("0xef0100"):
        return "delegated to 0x" + code[8:48]
    return f"contract, {(len(code) - 2) // 2} bytes"

account = sys.argv[1]
tx = rpc("eth_getTransactionByHash", [REVOCATION])
receipt = rpc("eth_getTransactionReceipt", [REVOCATION])
auth = tx["authorizationList"][0]
latest = int(rpc("eth_blockNumber", []), 16)

print(f"account {account}")
print(f"block {BEFORE}: {describe(account, hex(BEFORE))}")
print(f"block {AFTER}: {describe(account, hex(AFTER))}")
print(f"block {latest}: {describe(account, hex(latest))}")
print(f"revocation tx type={int(tx['type'], 16)} status={receipt['status']} gas={int(receipt['gasUsed'], 16)}")
print(f"tx nonce={int(tx['nonce'], 16)} auth nonce={int(auth['nonce'], 16)} delegate={auth['address']}")
print(f"tx from={tx['from']} to={tx['to']}")

Run it against the account:

python3 probe.py 0x28c6c06298d514db089934071355e5743bf21d60

Output at the check: [reproduced]

account 0x28c6c06298d514db089934071355e5743bf21d60
block 26301895: delegated to 0x63e842b054bd624a465454d533c33f573e9c6fae
block 26301896: empty
block 26302185: empty
revocation tx type=4 status=0x1 gas=36800
tx nonce=18914903 auth nonce=18914904 delegate=0x0000000000000000000000000000000000000000
tx from=0x28c6c06298d514db089934071355e5743bf21d60 to=0x28c6c06298d514db089934071355e5743bf21d60

The change of input is the block: 26,301,895 returns a delegation, 26,301,896 returns empty. Running the same script against Hot Wallet 34 returns contract, 209 bytes, and against Hot Wallet 16 returns empty; the classifier is not treating every labelled address as a delegated EOA. [reproduced]

What the probe proves: the account’s code was delegated before the revocation block and empty at and after it, and the revocation tuple names the zero address at the expected nonce. What it does not prove: who signed the original authorization, whether the key is still available to an attacker, whether other accounts are delegated, or whether any funds will be recovered.

Mitigation

There is no protocol patch to apply. EIP-7702 is final and did what it specifies. The fix belongs to the signing system and the account lifecycle.

Stop the signing path. Remove the affected account from the signer, HSM or MPC policy. Reject authorization payloads (0x05 domain) unless the destination is on an allowlist and the request has a second approval. A policy that reviews only outgoing transfers does not see a type-4 authorization.
Clear the delegation. Send a type-4 transaction from the account with one authorization tuple: chain_id, address = 0x0, nonce = current account nonce, and a valid signature. If the account is still sending transactions, read the nonce immediately before signing; a mismatch makes the tuple invalid. The transaction can be sent by any account; the signature must come from the delegated account.
Replace the account, not just the code. For a plain EOA, the address is tied to the key. A new key means a new address. Move remaining funds, update deposit addresses, withdrawal allowlists and any internal ledger mapping. If an MPC system supports share rotation without changing the address, rotate the shares and verify the public key and address afterwards; do not assume the share change moved the address.
Keep the compensating controls. Poll eth_getCode for every hot wallet and alert on any 0xef0100 value. Put withdrawal limits and delays in front of large transfers. Stablecoin issuer freezes are a last resort: they depend on the issuer, cover only that issuer’s token, and do not touch ETH.

The order matters. Clearing without stopping the signing path leaves the same authorization channel open. Replacing the account without clearing the old one leaves a delegated address that can still receive deposits. Do both, then verify.

Verification

Re-run the probe at the latest block. A cleared account returns 0x; a delegated one returns 0xef0100 plus an address. Check the revocation transaction receipt for status 0x1 and the authorization tuple for delegate=0x0. Check that the account nonce advanced past the authorization nonce.

Those checks prove the code is cleared at that block. They do not prove the account is safe. The stronger check is a sequence:

the revocation transaction is mined and its receipt succeeds;
eth_getCode returns 0x at that block and at a later block, with no new 0xef0100 in between;
the signing path no longer accepts authorizations for the account, or the account has been replaced by a new address and the old one is retired;
remaining funds have moved, and deposit addresses and allowlists point at the new account.

A version string is not proof that a service is running the fixed code; a single eth_getCode is not proof that an account is no longer exposed. The state can change in the next block.

For Binance users, the exchange’s own status page and verified accounts are the sources to check. Treat messages that offer to release withdrawals as scams; Binance’s statements contain no such offer.

Sources

EIP-7702: Set Code for EOAs, status Final. The authorization format and the zero-address clear are in the specification.
Revocation transaction, block 26,301,896, 30 October 2026 00:10:35 UTC.
Delegation transaction and sweep transaction, 29 October 2026.
Binance on X: initial statement, 21:16 UTC, edited statement, 21:29 UTC, withdrawal pause, 22:33 UTC, frozen total, 23:22 UTC.
Yi He on X: withdrawals disabled, 22:22 UTC. CZ on X: incident statement, 21:15 UTC, loss coverage, 22:23 UTC.
Binance deposit and withdrawal status, checked 30 October 2026 at 01:05 UTC.
Reuters, Binance says $2.54 billion in assets frozen as it probes security incident, 29 October 2026. [reported]
Cointelegraph, Binance hack may involve private key ‘misuse,’ not theft: Blockaid CEO, 30 October 2026. [reported]
PANews, Shen Yu: Binance 14 hot wallet still has not revoked EIP-7702 delegation, 30 October 2026. [reported]
Maborak, Binance’s $3.3B wallet transfers: what the chain shows, 29 October 2026.

Topics: security, blockchain

Back to all articles