Binance Hack: How EIP-7702 Delegation Emptied a Hot Wallet

Originally published at Binance Hack: How EIP-7702 Delegation Emptied a Hot Wallet

On 29 October 2026, hot wallets belonging to Binance paid out to an attacker across several blockchains within roughly half an hour. Binance puts the total impact at about $6.3 billion; Chainalysis counts about $6.4 billion, which would make it the largest theft in crypto history. Most legs of the attack were ordinary signed transfers. The Ethereum leg was different: the attacker used EIP-7702 to make one of Binance's busiest Ethereum hot wallets, labelled Binance 14 on Etherscan, run the attacker's own contract code. Less than four minutes later, about 167,464 ETH and 63 tokens left that wallet in a single transaction.

No smart contract bug was exploited and no signature was forged. That is exactly why this incident matters to anyone who builds wallets, custody systems or contracts that interact with EOAs. This post walks through what happened on-chain, why EIP-7702 changes the blast radius of a signing compromise, and what to take away from it.

TL;DR

• Victim: Binance hot wallets on multiple chains; on Ethereum, Binance 14 (0x28C6c062...1d60) was delegated, while Binance 16 sent plain transfers.
• Total impact: about $6.3B according to Binance, about $6.4B according to Chainalysis. Around $3B has been frozen by stablecoin issuers and partners.
• Ethereum mechanism: one type-4 transaction carried 50 valid EIP-7702 authorizations, all signed by Binance 14, all pointing the wallet at an attacker-deployed sweeper contract.
• Root cause (per Binance's initial investigation): a compromised DevOps engineer's laptop gave the attacker access to a service container that could submit withdrawal transactions. Binance says it found no evidence of a private key leak, and co-CEO Richard Teng later said the delegation did not pass through the exchange's normal approval controls.
• Duration: the malicious delegation stayed active for nearly four hours, until Binance 14 cleared it at 00:10:35 UTC on 30 October.

A Quick Refresher on EIP-7702

EIP-7702 went live on Ethereum mainnet with the Pectra upgrade in May 2025. It adds a new transaction type (type 4, "set code") with an authorizationList. Each entry is a tuple of (chainId, address, nonce) signed by an EOA. When the transaction is processed, the EOA's code is set to a small delegation designator, 0xef0100 followed by the target address. From then on, any call to the EOA executes the target contract's code in the context of the EOA: its balance, its storage, its token holdings and every permission it holds elsewhere.

Three properties are important here:

1. Anyone can submit the authorization. The signer does not need to send the type-4 transaction itself. A third party can carry a signed tuple on-chain and pay the gas.
2. The authorization is bound to the account nonce. A tuple only applies if its nonce equals the authority's current nonce at processing time.
3. The authorization carries no amount and no recipient. It does not say "send X to Y". It says "run this code", which can mean "send everything to whoever asks".

In other words, signing a 7702 authorization is closer to handing over the account than to approving a payment.

What Happened on Ethereum

All times below are block timestamps in UTC. Transaction details were checked against an Ethereum RPC node and matched against independent write-ups listed in the Sources section.

Preparation: Tooling Deployed Hours Earlier

The attacker's operator account, 0x7c8601d4...5ca0, was reportedly funded through Tornado Cash. On-chain analyses by Tibane Labs and an IMD incident report show it deploying a first sweeper version early on 29 October and testing it on fresh EOAs it controlled. At about 16:00 UTC it deployed the sweeper used against Binance, 0x63e842b0...6fae, and ran a final test delegation and sweep on another of its own wallets. In other words, the tooling was rehearsed and ready hours before the attack.

According to Tibane Labs' decompilation, every function in the sweeper checks that the caller is the hard-coded operator address. Its main entry points are a sweep(to, tokens[]) function that sends all ETH and the full balance of each listed token, and an execute(target, value, data) function that makes an arbitrary call.

20:20:59: Fifty Authorizations in One Transaction

At block 26,300,753, the operator sent type-4 transaction 0xad99264d...298b to Binance 14. Its authorization list contains 50 tuples, all delegating to the sweeper 0x63e842b0...6fae, with consecutive nonces from 18,914,775 to 18,914,824. Independent analysts recovered the signer of every tuple and found that all 50 were signed by Binance 14's own key.

Why fifty? Binance 14 is an extremely busy withdrawal wallet that sends transactions almost every block, so its nonce never sits still. A single authorization would very likely be stale by the time it landed. By obtaining signatures for a whole window of upcoming nonces, the attacker made sure exactly one of them would match whatever nonce the wallet had when the transaction was included. The rest were simply skipped as invalid, which EIP-7702 allows without reverting the transaction.

Tibane Labs notes that Binance 14 itself used nonce 18,914,775 about three minutes before the delegation landed. Nobody signs an authorization for a nonce that is already spent, so the batch appears to have been produced live, on demand, rather than taken from an old leak.

20:24:23: One Call Sweeps the Wallet

At block 26,300,770, the operator called Binance 14 directly with transaction 0x53bd38b8...e2f3. Because Binance 14 was now delegated, the call ran the sweeper's sweep function (selector 0x8a179be4) as Binance 14. The recipient argument in the calldata is 0x5227f603...2f8c. In that single transaction, about 167,464 ETH and 63 tokens, including roughly 1.6 billion USDT according to CoinDesk, moved to the attacker.

Twenty-four seconds later, Binance 16 sent the same attacker address 28,005.6 ETH and several tokens through ordinary signed transfers, with no delegation involved. Together, the two wallets lost roughly 200,000 ETH.

The execute() Path: More Than a Balance

A delegated EOA does not only expose its own balance. It exposes every role, allowance and admin right that address holds. According to TRM Labs (via CoinDesk) and Tibane Labs, Binance 14 also had control over a separate Binance smart-contract wallet holding USDC, an EIP-1967 proxy. Through the sweeper's execute function, the attacker made Binance 14 instruct that contract to release 823 million USDC (780M and 43M in two calls) to the attacker. Circle later froze those funds.

Nearly Four Hours of Live Delegation

The delegation did not expire by itself. Binance's normal systems kept routing deposits and rebalancing flows into Binance 14, and the attacker swept them again at around 21:04 and 21:44 UTC, according to CoinDesk. Only at 00:10:35 UTC on 30 October (block 26,301,896) did Binance 14 send itself a type-4 transaction, 0xafbf94c9...7209, with a single authorization to the zero address. That clears the delegation designator, and the wallet's code returned to empty.

Clearing the code removes the attacker's program, but it does not rotate the key. Anyone who can still sign for the account at its current nonce could install a new delegation.

Root Cause: A Signing Compromise, Amplified by 7702

It is tempting to call this an "EIP-7702 exploit", but the chain data does not show a flaw in EIP-7702 itself. Binance's announcement states that the incident may involve a compromised DevOps engineer's laptop that let the attacker reach a service container and submit unauthorized withdrawal transactions, and that it found no evidence of a wallet private key leak. In a later video update, Teng said investigators had found additional points of breach and that the EIP-7702 delegation did not pass through Binance's normal approval controls.

That combination explains the on-chain picture. Hot wallets on many chains signed for the attacker within the same half hour, some with plain transfers and one with a batch of 7702 authorizations. The common factor is the signing layer. A service that is trusted to produce signatures will sign whatever reaches it in a shape it accepts.

What 7702 changed is the shape of what could be signed. A withdrawal policy that inspects recipients and amounts has nothing to inspect in an authorization tuple: there is no recipient and no amount, only a code address. If the signing pipeline treated a type-4 authorization as just another message, the controls built for transfers never had a chance to fire.

A Simplified Version of the Pattern

The snippet below is simplified and illustrative. It is not the attacker's bytecode; it shows why a delegated EOA is fully exposed once an attacker-controlled contract becomes its code.

// SIMPLIFIED, illustrative only
interface IERC20 {
    function balanceOf(address) external view returns (uint256);
    function transfer(address, uint256) external returns (bool);
}

contract Sweeper {
    address immutable operator; // stored in code, not in the EOA's storage

    constructor(address op) { operator = op; }

    // Runs with address(this) == the delegated EOA
    function sweep(address to, address[] calldata tokens) external {
        require(msg.sender == operator, "not operator");
        for (uint256 i; i < tokens.length; i++) {
            if (tokens[i] == address(0)) {
                payable(to).transfer(address(this).balance);
            } else {
                IERC20 t = IERC20(tokens[i]);
                t.transfer(to, t.balanceOf(address(this)));
            }
        }
    }

    // Anything the EOA is allowed to do elsewhere, the operator can now do
    function execute(address target, uint256 value, bytes calldata data) external {
        require(msg.sender == operator, "not operator");
        (bool ok, ) = target.call{value: value}(data);
        require(ok, "call failed");
    }
}

The key line is the comment on sweep: once delegated, address(this) is the victim wallet, so balanceOf(address(this)) and msg.sender checks in downstream contracts all see the victim.

Lessons for Builders and Auditors

For Custody and Signing Infrastructure

• Treat 7702 authorizations as a separate, highest-risk signing class. They should never share a code path with withdrawals. If a hot wallet has no business delegating, the signer should refuse type-4 authorizations outright.
• Allowlist delegation targets. If delegation is needed, only sign tuples whose address is a known, audited implementation, and require multi-party approval for that list.
• Watch for nonce windows. A request to sign many authorizations for consecutive future nonces is a strong anomaly signal on its own.
• Monitor code on hot wallets. An alert on eth_getCode(hotWallet) != 0x would have flagged this within one block instead of nearly four hours later.
• Stop routing funds into a wallet you are investigating. Automated deposit and rebalancing flows kept feeding Binance 14 while it was compromised.

For Smart Contract Developers

• Do not assume an EOA is "just a key". After Pectra, any EOA can carry code. Checks such as tx.origin == msg.sender or extcodesize == 0 no longer prove a caller is a simple wallet.
• Minimise privileges held by hot EOAs. Binance 14's control over a separate USDC wallet turned one compromise into a second, $823M loss. Admin roles and large allowances belong to cold, multi-signature accounts, not to withdrawal wallets.
• Review delegation targets like any other contract. If your product asks users to sign 7702 authorizations, the delegate contract is now part of your attack surface and deserves a full audit.

We covered related signing and approval failures in our analyses of the Argent-style wallet recovery replay and the Avalanche Safe stale approval exploit. Our smart contract security checklist includes items on privileged roles and caller assumptions that apply directly here.

Response and Current Status

Binance suspended withdrawals, revoked the affected address authorization, engaged law enforcement, and says it will cover all losses from its SAFU fund and company funds. Teng said Binance has reserved more than $6.34 billion and aims to reopen withdrawals by Sunday, 1 November, with a full proof-of-reserves report targeted for Monday, 2 November. Tether, Circle and other issuers froze a large share of the stolen stablecoins. Chainalysis and TRM Labs attribute the theft to the North Korea-linked group TraderTraitor; Binance has not published a final post-mortem yet, so details of the initial access may still change.

Key Addresses and Transactions

Sources

• Binance: Security Incident Update (2026-10-30): initial findings, impact estimate, response
• CoinDesk: How one Ethereum permission let an attacker drain $2.5 billion from Binance: timeline, nonce window, amounts
• CoinDesk: Binance discovers multiple breach points: Teng's update on approval controls
• Decrypt: Binance sets aside $6.34B to cover hack losses: reimbursement and attribution
• Chainalysis: Binance hack findings: total, freezes and attribution
• Tibane Labs: Binance hack on-chain analysis: signer recovery, sweeper functions, multi-chain timeline
• Maborak: Binance 14's EIP-7702 revocation, checked on-chain: revocation transaction
• EIP-7702 specification

Closing Thoughts

The Binance theft is a reminder that the most powerful thing a key can sign is no longer a transfer. Since Pectra, one signature can replace an account's behaviour entirely, and every system that signs on behalf of an EOA needs controls that understand that. If you are building custody flows, smart accounts or contracts that rely on caller assumptions, talk to our team or check our audit pricing to get a review before an attacker does it for you.