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.
0x28C6c062...1d60) was delegated, while Binance 16 sent plain transfers.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:
nonce equals the authority’s current nonce at processing time.In other words, signing a 7702 authorization is closer to handing over the account than to approving a payment.
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.
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.
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.
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.
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.
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.
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.
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.
address is a known, audited implementation, and require multi-party approval for that list.eth_getCode(hotWallet) != 0x would have flagged this within one block instead of nearly four hours later.tx.origin == msg.sender or extcodesize == 0 no longer prove a caller is a simple wallet.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.
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.
| Item | Value |
|---|---|
| Binance 14 (victim, delegated) | 0x28C6c06298d514Db089934071355E5743bf21d60 |
| Attacker operator | 0x7c8601d4645b93cea45f71e118a729332e6b5ca0 |
| Sweeper contract | 0x63e842b054bd624a465454d533c33f573e9c6fae |
| Attacker receiving address | 0x5227f603c1ee34ce3c06efe6477003bdfccb2f8c |
| Delegation tx (block 26,300,753) | 0xad99264d5532ae0dd04b2004eebda05f25657e70dacb764f7ac8d4ccd051298b |
| First sweep tx (block 26,300,770) | 0x53bd38b816c23e74134786c29a8c18d792777998a3b9326047b583100e88e2f3 |
| Revocation tx (block 26,301,896) | 0xafbf94c92a8d749988411669fa14d4f8866d9b4420b4ebd299f28e958dac7209 |
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.
How a never-cleared transient hash and a caller-chosen call target let an attacker forge a zkLink Nova batch root and drain about $780K on Ethereum.
How a UTC day rollover booked a scheduled principal payment as received, reopened draw capacity and let an attacker drain 1.013M USDC on Avalanche.
How unlimited approvals to an address that was empty on Avalanche let anyone deploy a sweeper there and pull $7.45M from a 2-of-7 Safe multisig.
A MoveVM script-caching flaw let one account credit itself unbacked WETH, USDC and AUSD on Initia, and three bridge reserves paid out about $2.7M in real assets.