Binance and the cost of a single point of trust

On Thursday, October 29, starting at 20:05 UTC, attackers took an estimated $6.3 billion from Binance's hot wallets. It is believed to be the largest crypto theft on record. The story is still moving. Below are the facts so far, how the attack worked on Ethereum, and lessons for anyone who holds funds onchain.

1. What happened

Binance puts the estimated total impact at about $6.3 billion (Binance). Al Jazeera reports Binance warned the figure "may continue to increase" (Al Jazeera). Analytics firms put it between $6.0 billion and $6.43 billion, across 9 to 11 blockchains. TRM Labs says most of it left in about 20 minutes (BleepingComputer, Elliptic, Decrypt). That is about four times the $1.5 billion Bybit hack of February 2025.

Binance's initial investigation suggested a compromised DevOps engineer's laptop may have given the attacker access to a service container that submits withdrawal transactions. Binance says it has found no evidence of a wallet private key leak. On Friday it said it had found "additional points of breach", without saying what they are. Co-CEO Richard Teng said the attacker "did not simply use one engineer's permissions, and this was not a single 'one-click' action" (Decrypt, BleepingComputer).

Binance's response so far:

• Withdrawals are suspended. Deposits work normally. Binance said at 08:47 UTC Friday that it remained on track to resume withdrawals in about 45 hours. That points to around 05:45 UTC on Sunday, November 1. It is an estimate, not a confirmed time. Later on Friday, Teng said the withdrawal service is being rebuilt and will reopen only once it "passes rigorous testing". He said it was still on track within about 40 hours, and that a full proof of reserves report would follow by Monday (BBC, Decrypt, Crypto Times live).
• Binance says about $3 billion is frozen. Independent tallies put it at $2.7 billion to $2.84 billion. Most is USDT and USDC frozen by their issuers. It also includes 8,426 ETH and 74.6 million ARB moved by the Arbitrum Security Council. Between $2.4 billion and $3.3 billion sits in assets no issuer can freeze, such as ETH and BTC (BleepingComputer, Elliptic).
• Binance will cover losses from its SAFU emergency fund and company funds. It has set aside more than $6.34 billion, $5 billion of it already held in the stolen tokens, and is buying the rest (Cointelegraph).

On attribution: TRM and Chainalysis say with high confidence that North Korea's TraderTraitor unit did it (BleepingComputer, Chainalysis). Elliptic calls a North Korean link likely but flags caveats. Binance has not named an attacker, and no government has confirmed attribution.

2. The technical part: EIP-7702 delegation

Elliptic counts $3.80 billion taken on Ethereum. Almost all of it came from one hot wallet, which Etherscan labels Binance 14, hijacked through a feature called EIP-7702. Everything else, on Ethereum and other chains, left through ordinary transfers.

Wallets, contracts and transactions

A normal Ethereum wallet is an address controlled by one private key. Most wallets work this way, including the hot wallets an exchange keeps online to pay out withdrawals. A normal wallet has no code. It does exactly what its key signs, one transaction at a time.

Every Ethereum transaction has a From field and a To field. From is the account that signed it and pays its fee. To is its destination. In this post, "a transaction sent to the wallet" means one whose To field is the wallet's address. It is not a withdrawal from the wallet. It does not have to carry money either. It can carry 0 ETH and only data, which names a function to run and its inputs. Anyone can send one, signed with their own key and paid for with their own fee.

If the To address is a plain wallet, nothing runs. The transaction can only deliver the ETH it carries, and its data is ignored. To move funds out of a plain wallet, you need a transaction from the wallet, signed by the wallet's key.

A contract is an address that holds code. If the To address is a contract, Ethereum runs the contract's code with that data. Developers call this "calling" the contract. To send USDT, for example, your wallet sends a transaction to the USDT token contract, with data asking it to run its transfer function. Code that is already running can call other contracts the same way, inside the same transaction.

What EIP-7702 changes

EIP-7702 has been live since the Pectra upgrade in May 2025. It lets a normal wallet borrow the code of a contract. The owner signs a short message that says "run the code at contract X as my code." That message is called an authorization. It holds three things: the chain ID (which network it is valid on), the contract address, and a nonce (the wallet's transaction counter, explained below). It names no recipient and no amount.

Anyone can then put a signed authorization onchain inside a special transaction, called a "set code" transaction. Whoever sends it pays the fee. It does not have to be the wallet's owner. Ethereum then stores a pointer in the wallet: a marker that says "use contract X's code here." This is what "delegating" means.

From then on, the wallet behaves like a contract. A transaction from anyone, sent to the wallet's address with data, makes Ethereum run X's code. The code runs as the wallet, with the wallet's balance and under the wallet's address. When that code tells a token contract to move tokens, the token contract checks who is asking, and it sees the wallet itself. So it moves the wallet's tokens, as if the wallet's key had signed. The code can send the wallet's ETH out the same way. Any contract that has the wallet as its admin will also obey X's code. Moving funds out no longer needs the wallet's key. It needs only what X's code checks.

So the wallet is now only as safe as X's code. A legitimate smart wallet contract protects the account. It checks who sent the transaction, or verifies a signature from the owner, before it moves anything. The wallet's key still works as before, and the pointer stays until the owner changes it.

Three transactions show the difference:

Transaction	Signed by, and fee paid by	From	To	What happens
Normal withdrawal	The wallet's key	The wallet	The customer's address (for tokens, the token contract)	Funds leave the wallet. For a plain wallet, this is the only way out.
Stranger sends to a plain wallet	The stranger's own key	The stranger	The wallet	Any ETH it carries arrives. Nothing runs. Nothing leaves.
Attacker sends to the delegated wallet (20:24:23 UTC)	The attacker's own key	The attacker	Binance 14	It carries 0 ETH and data asking X to run its sweep function. X's code runs inside Binance 14 and sends its ETH and tokens to the attacker.

Why the exchange's checks had nothing to inspect

An exchange's withdrawal system is its internal pipeline between a customer's withdrawal request and the hot wallet's key. It receives the request and checks it. Typically, the destination address is checked against allowlists and sanctions lists. The amount is checked against limits. Fraud rules and velocity rules (how fast money is leaving) also apply. Some withdrawals need approval from a person, or from several. Only then does the system have the key sign a transfer.

An authorization does not look like a withdrawal. It holds only a chain ID, a contract address and a nonce. It has no destination and no amount, so those checks have nothing to inspect. The signature by itself also moves no money. Binance co-CEO Richard Teng said on Friday that the delegation "did not pass through our normal approval controls" (BBC). He did not say how it was signed.

The nonce, and why 50 signatures

Every Ethereum account has a nonce: a count of the transactions it has sent. It starts at 0 and goes up by one each time. An authorization includes a nonce. It only takes effect if that number equals the wallet's counter when the set code transaction runs. When it takes effect, the counter goes up by one. So each signed authorization can be used only once and cannot be replayed later. It also goes stale as soon as the wallet sends another transaction, because the counter has moved past it.

The attacker's target sent withdrawals constantly, so its counter kept moving. The attacker could not know its exact value at the moment their transaction would land. So they had 50 authorizations signed, for 50 consecutive nonces, and put all 50 into one set code transaction. The network skips any authorization whose number does not match the wallet's counter, and a match sets the pointer.

What the attacker did

Onchain analysis by Tibane Labs, Elliptic and the security vendor Blockaid lays out the sequence (Tibane Labs, Elliptic, Blockaid). Binance has not confirmed these details. Binance 14 is one of Binance's busiest Ethereum hot wallets. It sent withdrawals every block.

The attacker needed a valid signature from the wallet's key on an authorization pointing at their contract. Any Binance system with signing access to that key could produce one, without the key being stolen.

1. At 15:59 UTC, more than four hours before the delegation, the attacker deployed contract X, a "sweeper." This is code that sends everything in a wallet to the attacker, and can also make the wallet send instructions to other contracts. It checked only one thing: that the transaction came from the attacker's own address, which was written into its code (Tibane Labs). They rehearsed on wallets they controlled.
2. Binance 14's key signed the 50 authorizations shortly before 20:17:47 UTC, about three minutes before step 3. This happened offchain. The result was just signed data. Nothing changed onchain, and no code ran.
3. At 20:20 UTC, the attacker's own address submitted the set code transaction carrying the 50 authorizations, and paid its fee. Its To field was Binance 14. Ethereum wrote the pointer to the sweeper into Binance 14 first, before the rest of the transaction ran. Nothing was swept and no funds moved.
4. At 20:24:23 UTC, the attacker sent the sweep transaction in the table above. Etherscan shows it went from the attacker's own address to Binance 14, carried 0 ETH, and cost the attacker a fee of about 0.0004 ETH (Etherscan). Its data asked the sweeper to run its sweep function, with a list of token addresses and the attacker's collection address (Tibane Labs). Ethereum saw the pointer on Binance 14 and ran the sweeper's code as Binance 14. The code sent out 167,464 ETH, and told each of 63 token contracts to transfer the wallet's balance, all to that collection address. The 63 tokens included about 1.6 billion USDT (Tibane Labs, Blockaid). Nothing in that transaction was signed by Binance.
5. Binance 14 was also the admin of a separate Binance contract wallet holding USDC. From 20:41 UTC, through the borrowed code, the attacker made Binance 14 order that wallet to send out 823 million USDC, in two transfers.
6. The pointer stayed in place. New deposits sat in Binance 14 until the attacker sent another sweep transaction of the same kind, which ran the sweeper again. By Elliptic's count that happened four more times, the last at 23:56 UTC, without needing Binance's key again. The swept deposits included about 2,962 ETH sent in by Binance's own internal top-up transfers.

All 50 signatures check out as made by Binance 14's real key. The batch starts at nonce 18,914,775. Binance 14 used that same nonce itself, in one of its own transactions, at 20:17:47 UTC. Nobody signs for a nonce that is already used, so the batch was signed before 20:17:47, with its range starting right at the wallet's counter. Tibane Labs concludes it was made within about three minutes of going onchain, by a system that could sign on demand, rather than taken from an old backup.

How it gets undone

The original key keeps working, so the owner can still send transactions. The pointer stays until the owner signs a new authorization that replaces or clears it. Clearing it takes a new authorization, signed by the same wallet key, that points at the zero address (0x000...000). That tells Ethereum to remove the pointer. Moving funds and operations to a new wallet does not remove it, because the pointer stays on the old address. Until the pointer is cleared, the attacker can sweep out any funds that arrive there. Binance 14's clearing authorization went onchain at about 00:10 UTC on Friday.

The other chains

Hot wallets on the other chains, plus a second Ethereum hot wallet, were drained with ordinary transfers signed by Binance's own keys (Elliptic, CoinDesk). What all of these have in common is Binance's signing system. EIP-7702 was not broken. It let the attacker empty one wallet in a single transaction and keep control of it for hours.

One question is still open. Binance describes a service that submits withdrawals, but an authorization is a different kind of message. How that service came to sign one is not public. Binance has not named the "additional points of breach" or published a full account. We'll update this post when it does.

3. What we can learn about securing funds

Elliptic notes that in both Bybit and Binance, "it was the infrastructure and people around the wallets that were compromised, not the cryptography" (Elliptic). Two lessons follow.

1. Limit how fast money can leave, and enforce it away from the key. Every theft in this attack rested on a valid signature from Binance's own keys. Some transfers were signed directly. The Binance 14 sweeps ran through code that a valid Binance signature had authorized. A check that asks "is this signature valid?" passed every time. A limit on how much can leave in each hour does not care who signed. Here, TRM says most of the money left in about 20 minutes. One Ethereum transaction moved about $2.53 billion of the roughly $6.3 billion total (Elliptic). The hijacked wallet was then swept again for hours, the last time at 23:56 UTC.

A limit only helps if the attacker cannot get around it. A rule inside the signing service fails when the signing service is what was hijacked. The strongest place for a cap is the contract that holds the funds. There it binds everyone, including delegated code. A separate policy service, with its own keys and infrastructure, helps only if no valid signature can be produced without it. Its main job is then to refuse risky requests, such as a delegation, before anything is signed. Once a delegation is live, the delegated code moves funds with no new signature, so a pre-signing check never sees those moves. Blockaid lists "value caps per transaction and per window" among the policies its Cosigner product checks before signing (Blockaid).

Caps must fit real volume, and an exchange moves a lot. Even a generous cap turns minutes of loss into time to respond. A plain wallet cannot enforce a limit on itself. Its key can always sign transactions directly, or sign a new delegation. So keep large balances in contracts that enforce caps, where no single hot key can lift the cap or upgrade the contract without delay. Keep in plain wallets only what you could afford to lose in one window.

2. Check the security of the whole stack, continuously, as one system. Binance's initial finding describes a chain of failures: a DevOps engineer's laptop that may have given access to a service container, from which the attacker submitted withdrawal transactions. Onchain analysis by Elliptic and Tibane Labs suggests the attacker used that path to get Binance's own systems to sign (Elliptic, Tibane Labs). Hardening only the signer, or only the laptops, leaves the links in between. Binance itself says it is now running a security review across the whole company (BBC). In practice, keep checking:

• Developer and DevOps machines: what each one can reach.
• Build and service containers: what each one can submit, and to which signer.
• Signing and key management: what each signer will sign, and who can ask. A hot wallet signer should refuse any hash it did not build itself, and any EIP-7702 authorization except a pre-approved one that clears a delegation. Each co-signer should rebuild the transaction from its own record of the customer request, so a hijacked component cannot pass its input straight through.
• Wallet roles: Binance 14 was admin of another wallet, so one delegation also exposed 823 million USDC. Keep admin roles off hot wallets.
• Onchain state: alert the moment a hot wallet gains code. Binance 14 carried the attacker's pointer for almost four hours. Have a clearing transaction ready, and practice it. Treat pattern breaks as alarms too. In the same block, Binance 16's own withdrawals paid a 1 gwei priority fee (a gwei is a billionth of an ETH), and the attacker's paid 2.4 gwei. On Bitcoin the attacker used two-output transactions instead of the usual batches (Tibane Labs).

Soda Labs builds privacy infrastructure for onchain applications. Corrections and questions are welcome at sodalabs.xyz.