Binance's $6.4B Hack: Hijacked Signers on Ten Chains and a 3h49m EIP-7702 Delegation

TL;DR

From 20:05 UTC on October 29, 2026, an attacker moved about $6.4 billion out of Binance hot wallets on at least ten blockchains, the largest crypto theft on record. The FBI attributed it to North Korea's TraderTraitor on October 31. Binance's preliminary account is a compromised DevOps engineer's laptop that reached a service container and submitted unauthorized withdrawals, with no evidence of a private key leak. On Ethereum, one transaction carried 50 EIP-7702 authorizations signed by hot wallet Binance 14, one per nonce. One matched, and the wallet became the attacker's sweeper. On-chain, that delegation stayed live from 20:20:59 to 00:10:35 UTC, and Etherscan shows more than $1 billion in stablecoins moving through it after the first sweep. About $2.7 to $3 billion is frozen, and Binance has replenished 90% from its own funds. Under EIP-7702 a delegation persists until the wallet signs a new one, so a hot wallet's exposure runs from the delegation to the revocation, however long that takes.

What Happened at Binance on October 29?

The drain ran across chains for about half an hour, then came back. TRM Labs' reconstruction starts it on the XRP Ledger at 20:05 UTC, with Binance wallets on Solana, Optimism, Bitcoin and Tron following within about 17 minutes and a second wave on Avalanche and Polygon around 23:05. The Bitcoin leg went straight into a peel chain: 18,270 BTC split into round 1,000 BTC and 100 BTC pieces inside the same block.

Binance's first explanation came the next day. In its October 30 security incident update, the exchange said the incident "may involve a compromised DevOps engineer's laptop, which allowed an attacker to gain access to a service container and submit unauthorized withdrawal transactions," and that it had "found no evidence of any wallet private key leak." It suspended withdrawals and "revoked the affected address authorisation."

That picture got bigger the same day. Update #2 dated the compromise to around 20:05 UTC, put the loss at approximately $6.3 billion, and said that "our subsequent investigation has uncovered additional points of breach." Co-CEO Richard Teng added in a video, as reported by Elliptic, that the attack "was not carried out by one person," that the attacker's tooling self-destructed as it ran, and that the EIP-7702 delegation "did not pass through our normal approval controls."

Binance has not published a root cause. What follows is on-chain reconstruction.

How Did 50 Presigned Authorizations Hand Over Binance 14?

EIP-7702, shipped in Ethereum's Pectra upgrade, lets an ordinary externally owned account (EOA) point its code at a smart contract. The account signs an authorization tuple of chain id, contract address and nonce. Once a transaction carries it, the spec writes a "delegation indicator" (0xef0100 followed by the contract address) into the account's code, and every call to the account runs the contract. The delegation persists until the account signs a new authorization. Pointing it at the zero address clears it.

Nonces are the obstacle. An authorization only applies if its nonce equals the account's current nonce at execution, and an exchange hot wallet burns through nonces with every customer withdrawal. TraderTraitor solved that with volume. The delegation transaction, sent at 20:20:59 UTC by an outside address (0x7C86...5CA0, which also sent every later sweep call; Blockscout shows it funded by three withdrawals from Tornado Cash's 0.1 ETH pool on October 28 and 29), carried 50 authorizations from Binance 14, all pointing at the same sweeper contract (Etherscan labels it Binance Hot Wallet Exploiter 24). They run in descending order from nonce 18,914,824 to 18,914,775. By the time the transaction landed, Binance 14's own withdrawals had already used nonces up to 18,914,808 (per Blockscout, the last one earlier in the same block), so its next nonce was 18,914,809. The first 15 tuples were above that and failed. The 16th matched, the spec then bumps the nonce, and the remaining 34 were behind it: one valid, 49 invalid. TRM adds that the signatures were produced in advance, as a batch, by the hot wallet's own signing path.

The range also hints at timing. Binance 14 used nonce 18,914,775 at 20:17:47, so if the range started at the wallet's nonce when the batch was made, the signatures are about three minutes older than the delegation. That is our inference; nothing on-chain records when they were signed.

Three minutes and 24 seconds later, the main sweep moved 167,464.25 ETH out of Binance 14, along with 63 tokens including 1.615 billion USDT, to the address Etherscan labels Binance Hot Wallet Exploiter 2. Elliptic counts that single transaction as $2.53 billion, two-thirds of the Ethereum loss.

Most of the theft went through plain signed transfers. TRM documents Binance wallets on the other chains sending "funds to the attacker through standard signed transfers," and a second Ethereum hot wallet sent 28,006 ETH and more the same way, with no delegation. Wallets on different chains and signing schemes all signed for the attacker in the first half hour, and again on Avalanche and Polygon around 23:05. TRM's assessment is that the attacker could make Binance's hot wallet signing system sign transactions of its choosing, and that the 50-signature batch "suggests the access may have been limited in time, or that signatures had to be requested through a system." Neither TRM nor Binance has said which component accepted the requests, or which control should have refused a request for 50 authorizations at once. On our reading, that time limit is also why Ethereum got a delegation: it keeps working after the signing access is gone, and it did for the next three hours.

The Attack, Step by Step

Times are UTC. Pre-attack steps are from TRM and Elliptic; Ethereum transaction times are from Etherscan.

Why Did the Delegation Keep Working?

Suspending withdrawals stops your own signer from sending anything new. A delegation already set on the wallet keeps working. After the main sweep, the operator called back into Binance 14 six more times and moved value each time. At 20:41:23 it pulled 780 million USDC from a Binance smart account that trusted Binance 14 as executor, and 43 million more at 20:59:47. At 21:04:23 it took 1,699.92 ETH and 3.9 million USDT. At 21:44:11, 369.83 ETH and 200.4 million USDT. Then 128.49 ETH at 22:39:35 and 2,961.91 ETH at 23:56:47. None needed a new signature. TRM's sweep times match ours.

Our tally of those six calls, from Etherscan and Blockscout, is 823 million USDC, about 204.3 million USDT and 5,160.15 ETH. The stablecoins are the part the attacker mostly did not keep. Circle froze the 823 million USDC in the receiving wallet at 21:04, and Tether had frozen that wallet's USDT at 21:01, so the later USDT sweeps landed where they could no longer be spent. TRM counts 1.175 billion USDT now frozen there. The sweeper still sent 204.3 million USDT into it after the freeze, while the ETH, with no issuer behind it, stayed spendable.

The revocation is a single type-4 transaction from Binance 14 to itself at 00:10:35 UTC on October 30, delegating to the null address. That is 3 hours, 49 minutes and 36 seconds after the delegation landed, and 13 minutes and 48 seconds after the last sweep. Outside parties moved first. TRM's reconstruction reports that Ripple froze RLUSD inside the compromised Binance hot wallet and World Liberty Financial froze USD1 inside it at 22:26, so new deposits of those tokens could not be swept.

Binance has not said why the revocation took that long or whether it tried earlier. Whether its signer was itself the compromised path, and so could not be trusted to sign a revocation sooner, is the open question for its post-mortem.

How Much Was Really Taken, and How Much Is Frozen?

We use $6.4 billion. TRM's and Elliptic's per-transfer totals both round there, and they agree within $10 million on Ethereum ($3.79 billion against $3.80 billion). Elliptic excludes a further $169 million that left after withdrawals were suspended, which it reads as Binance moving its own funds. BleepingComputer's first report carried Arkham's lower $5.78 billion, which measured attacker-held balances at that moment.

Frozen figures diverge the same way. TRM counted about $2.7 billion as of 00:30 UTC on October 30: Tether about 1.77 billion USDT, Circle about 825 million USDC, smaller freezes by Ripple and World Liberty Financial, and Arbitrum's Security Council forcing 8,426 ETH and 74.6 million ARB out of the attacker's wallet at 00:08. Tether's share is the main receiving wallet (971.1 million frozen at 21:01, 1.175 billion once later sweeps landed in it) plus freezes on other attacker wallets on Ethereum, Tron, Avalanche and Polygon. Elliptic has verified $2.85 billion, 44% of the theft. Binance says about $3 billion.

Replenishment is a separate number again. Binance's Recovery Update #3 says it has covered 90% of the impacted amount from SAFU, part of its Futures insurance fund and its corporate treasury. That money comes from Binance; none of it is recovered from the attacker.

Who Did It, and How Is the Money Moving?

The FBI's October 31 notice names North Korea and the activity it calls TraderTraitor. It says the actors are converting stolen assets primarily into ETH and asks THORNode operators, RPC node operators, instant exchanges and DeFi services to block transactions with or derived from the addresses it lists. TRM and Elliptic had both named TraderTraitor first.

TRM says staging began at least 36 hours before the theft and matches Bybit and KelpDAO: Tornado Cash funding, then signatures obtained in advance and executed in one burst.

The laundering so far is a race against the freeze, paid for at a discount. TRM reports about 325 million USDT sold to market makers through UniswapX and similar contracts for about 122,300 ETH, an implied $2,650 per ETH while ETH traded near $2,300 to $2,350: more than 10% given up for speed. A second wallet borrowed about 19,760 ETH on Aave against 60 million USDT before Aave froze the markets. As of TRM's snapshot, the attacker held more than 420,000 ETH and 18,270 BTC, about $2.4 billion beyond any issuer's reach.

How the laptop was compromised is not public. The Hacker News summarizes the group's recent playbook, trojanized Terraform providers and recruitment lures, but nobody has tied either to this entry, and StepSecurity notes Binance has not identified the malware or infection method.

What Does "No Private Key Leaked" Actually Cover?

Binance's statement covers the key. It says nothing about the systems that ask the key for signatures, and the attack ran through those.

The industry has now watched this move three times. In February 2025, Elliptic notes, North Korean hackers compromised a developer's machine at Safe and manipulated the transaction Bybit's signers approved. In September 2026, Bitget's signer approved $387.5 million of forged withdrawal instructions without its keys ever leaving. In all three the cryptography held, and the attacker went after the machines and services upstream of the signer.

The custody stack (HSMs, MPC, cold storage, an audited smart account) can be in order while a service container submits withdrawals the signer cannot independently doubt. Which laptop can reach which container sits outside the scope of a code audit. EIP-7702 raises the stakes, because a signer that will sign an authorization is signing away the account's behavior until further notice, and Teng's own account is that the delegation skipped Binance's normal approval controls.

A contract review would not have flagged any of this. Our penetration testing works this attacker's path before an attacker does, starting where this incident started: compromised developer machines, deployment pipelines, cloud infrastructure and the social engineering that gets a person to run the first payload, followed through to whatever can ask a signer for a signature, including one for an EIP-7702 authorization nobody expected.

What Should Exchanges and Custodians Do Now?

1. Make the signer reject EIP-7702 authorizations by default. TRM recommends refusing them unless expected, and treating a request for many authorizations across a nonce range as an indicator of compromise. No legitimate withdrawal flow asks for fifty consecutive nonces.
2. Alert on code appearing at a hot wallet. A delegation shows up as code at an address that should have none, in the same block.
3. Pre-stage the revocation path. Keep a tested, pre-approved way to sign a delegation to the zero address that does not run through the withdrawal service layer. Binance's revocation was one transaction, signed at 00:10:35.
4. Treat "withdrawals paused" and "wallet contained" as two separate states. A withdrawal pause does not reach a standing delegation, and six operator calls went through Binance 14 after the main sweep. Check for delegations, executor roles and standing approvals before declaring an incident contained.
5. Audit what your hot wallets are trusted by. Binance 14 was executor of a smart account holding 823 million USDC, and that role went with it.
6. Segment signing by chain and wallet tier. One actor got valid signatures on ten chains within hours. Our key-compromise runbook covers the first hour.

What Could Monitoring Have Changed?

Two rules would have fired on Ethereum, each on an event cited above.

1. Code appears at a hot wallet. The trigger is one transaction at 20:20:59 carrying 50 authorizations for Binance 14, nonces 18,914,775 to 18,914,824, and it fires in the same block. It was the only alert before the Ethereum loss, and it left 3 minutes 24 seconds. A revocation authorization must carry the wallet's current nonce, so it cannot be signed days ahead; beating that window needs an automated signer you still trust. If the signer is the compromised component, as TRM assesses, that path was not there, and rule 1 would not have saved the $2.53 billion main sweep. Its value is starting the clock on rule 2.
2. An outside address moves funds through a hot wallet, again and again. At 20:41:23 the operator address pulled 780 million USDC through Binance 14, 17 minutes after the main sweep, and called it five more times up to 23:56:47. The first call means the wallet is attacker-controlled: revoke, and send the receiving address to the token issuers. A rising count over hours means no revocation yet.

Rule 2 only limits damage after the main sweep, and here the issuers had already covered most of it: the 823 million USDC and about 204.3 million USDT that moved after 20:24:23 ended up frozen in the receiving wallet. A revocation on rule 2 would have saved the 5,160.15 ETH, if Binance had a signing path it trusted by then. The other chains drained through ordinary signed transfers and would have tripped neither rule.

Frequently Asked Questions

How much was stolen in the Binance hack?

About $6.4 billion: TRM Labs counts $6.36 billion and Elliptic $6.43 billion, Binance about $6.3 billion. Roughly $2.7 to $3 billion is frozen, mostly USDT and USDC.

Were Binance's private keys stolen?

No, according to Binance, which says it found no evidence of a key leak and has not yet published a root cause. The on-chain evidence points to Binance's own signing infrastructure signing for the attacker, including 50 EIP-7702 authorizations for Binance 14.

What is an EIP-7702 delegation attack?

It is the abuse of a signed EIP-7702 authorization to point an ordinary wallet's code at an attacker's contract, which then runs on every call until the wallet signs a new authorization. Binance 14 stayed delegated for 3 hours and 49 minutes.

Has Binance covered the losses?

Not yet in full. Binance reported 90% of the stolen assets replenished from its own funds on October 31 and says it is buying the rest. Elliptic reports withdrawals began reopening on November 1, starting with Bitcoin.

Sources / References

• North Korea Responsible for $6 Billion+ Binance Attack, FBI
• North Korea Steals USD 6.36 Billion From Binance in the Largest Hack in History, TRM Labs
• The largest theft in history: North Korea behind the $6.4 billion Binance hack, Elliptic
• Security Incident Update (2026-10-30), Binance
• Security Incident Update #2 (2026-10-30), Binance
• Security Incident | Recovery Update #3: 90% of Stolen Assets Replenished; Proof of Reserves Snapshot Provided (2026-10-31), Binance
• Etherscan: EIP-7702 delegation of Binance 14, 50 authorizations
• Etherscan: main sweep of 167,464.25 ETH from Binance 14
• Etherscan: 780M USDC pulled through Binance 14 at 20:41:23 UTC
• Etherscan: 200.4M USDT swept from Binance 14 at 21:44:11 UTC
• Etherscan: last sweep, 2,961.91 ETH at 23:56:47 UTC
• Etherscan: Binance 14 delegation revoked to the null address
• EIP-7702: Set Code for EOAs, Ethereum Improvement Proposals
• Binance probes potential $5.8 billion crypto-theft hack, BleepingComputer
• FBI Links North Korea's TraderTraitor to Record $6.43 Billion Binance Crypto Heist, The Hacker News
• Binance's $6.3 Billion Hack: FBI Attribution and the Case for Developer Machine Security, StepSecurity