$6.3 Billion Vanished — The Signing-Delegation Paradox in the Binance Hack

TL;DR — At 20:05 UTC on October 29, 2026, funds began leaving Binance's hot wallets. In about 20 minutes, roughly $6.3 billion was gone across 11 chains. It is the largest crypto theft on record. Binance said it found no evidence of a private-key leak. The attacker didn't steal the keys. They fed their own transactions into the system that signs with those keys. On Ethereum, an EIP-7702 delegation turned a hot wallet into a "sweeper" for 3 hours and 49 minutes.

1. What happened — the officially confirmed scope

Binance's official notice confirms the following.

• It started with a compromised DevOps engineer's laptop. Through it, the attacker reached an internal service container.
• From that container, the attacker submitted unauthorized withdrawal transactions.
• There is no evidence that any wallet private key leaked.
• Losses are about $6.3 billion. About $3 billion has been frozen.
• Binance will cover all losses from the SAFU fund and company funds.

Binance later said it had found "additional breach points" beyond the laptop. Co-CEO Richard Teng described the EIP-7702 delegation this way: it "did not pass through our normal approval controls."

Not yet public — How the laptop was first infected is still unknown. So are the additional breach points, and the authority the container held over the signing system.

2. A 20-minute timeline

3. The keys were safe — the signing-delegation paradox at exchange scale

A phone's Secure Enclave never lets a wallet key out. But what if malware asks it to sign a transaction of its choosing? The secure element signs it anyway. The key stays safe while the funds are drained — the signing-delegation paradox.

The Binance incident is that paradox at exchange scale. Side by side:

Blockaid's CEO called it "key misuse, not key theft." The wallets on the other 10 chains all use different key types and signing schemes. Yet within about 30 minutes, every one of them sent funds via validly signed ordinary transactions. Binance's second Ethereum hot wallet also sent $174 million in nine ordinary transactions, with no delegation involved. Phishing can explain Ethereum alone. So TRM and Elliptic both conclude the attacker could issue commands directly to the hot-wallet signing infrastructure.

Key insight — "No private key was leaked" does not mean "safe." The security boundary does not stop at where the key lives. It must cover every path that can request a signature.

4. The EIP-7702 model — delegation designators and the nonce rule

EIP-7702 lets an EOA hand its code over to a smart contract. It does so through an authorization the EOA signs.

• An authorization is a (chain_id, address, nonce, y_parity, r, s) tuple. It is submitted inside the authorization_list of a type-4 transaction.
• Once applied, a delegation designator 0xef0100 || address is written into the EOA's code slot.
• Any call to the EOA then runs address's code. The code uses the EOA's own balance and storage.
• The delegation persists until it is replaced by a new authorization or cleared with address = 0x0.
• The submitter and the signer can differ. In other words, anyone holding the signature can submit it.

To follow this incident, you need one part of the processing rule: the nonce check.

# EIP-7702 authorization processing (simplified from the spec)
for auth in tx.authorization_list:
    authority = ecrecover(auth)
    if auth.nonce != get_nonce(authority):
        continue                      # a failed authorization is skipped silently (the tx continues)
    set_code(authority, b"\xef\x01\x00" + auth.address)
    increment_nonce(authority)        # nonce +1 each time one is applied

Two properties matter.

1. A failed authorization does not revert the transaction. So you can include many authorizations with different nonces. Only one needs to match at execution time.
2. Each applied authorization bumps the nonce by one. So the order of the authorizations changes the outcome (§5.2).

5. Anatomy of the attack — what the chain shows

What the public reports leave out is still in the on-chain record. Follow the attacker's wallet and Binance 14 block by block, and the whole operation comes into view.

5.1 Thirty-six hours of preparation

The attacker EOA sent 23 transactions in total, nonces 0 through 22.

The funds came from three Tornado Cash 0.1 ETH pool withdrawals: the first, second, and third. Two hours before the attack, a separate gas wallet sent 1.08 ETH. Its first deposit also came from the Tornado 0.1 ETH pool. The sweeper's bytecode hard-codes authorizedCaller() to the attacker EOA.

Pattern — small Tornado top-ups → testing → rehearsal → batch execution of pre-signed authorizations. TRM sees the same sequence in the Bybit and KelpDAO incidents.

5.2 Fifty authorizations, in descending order

The delegation transaction carries 50 authorizations. Every one targets the sweeper. Their nonces run consecutively from 18914775 to 18914824.

A Binance hot wallet processes withdrawals nonstop. So its nonce keeps climbing. The attacker obtained authorizations for 50 consecutive nonces and bet that one would match. But the order of the authorizations reveals something more interesting.

• The authorizations were in descending nonce order (824 → 775).
• In the same block, at index 133, Binance sent its own transaction. Its nonce was 18914808.
• The attack transaction sat at index 138. So the only authorization that applied was 18914809. After the block, the nonce stood at 18914810.

Why pack them backwards? In ascending order, the nonce would become 810 once 809 applied. Then the next authorization, 810, would match and apply too. The chain would run all the way to 824, a 16-step jump in the nonce. Every withdrawal Binance had already signed (nonces 810–824) would become invalid. That would very likely trip operational alerts at once. In descending order, one authorization applies and every remaining one has a lower nonce. They all fail silently. It is, in effect, an ordering that minimizes the footprint.

The gas used, 1,258,562, fits this picture. Start with the 21,000 base cost and add 50 authorizations × 25,000. Subtract a 12,500 refund for the one applied to an existing account, and you land almost exactly there. The 49 failed authorizations still paid gas.

So when were these authorizations signed? Binance 14's nonce passed 18914775 at 20:17:47. That is exactly where the signed range starts. The wallet processes roughly 10 transactions a minute. So 50 nonces buy 4–5 minutes of headroom. The attacker most likely got the authorizations in real time, about three minutes before submitting them. That fits TRM's view: "access was time-limited, or signatures had to be requested through the system."

5.3 Three hours and 49 minutes — twelve attacker calls

• Sweeps moved about 172,624 ETH in total. Each one left exactly 1 ETH behind.
• callExecute exploited another privilege of Binance 14. The wallet was the executor of a separate smart account. That right passed to the attacker along with the delegation. The exposure did not stop at the wallet balance.
• The 2,962 ETH swept at 23:56 was a deposit that arrived 1 hour 40 minutes after withdrawals were halted (22:15). Binance's deposit-consolidation pipeline kept routing funds into a wallet the attacker controlled.

5.4 Revocation — Binance never lost its signing ability

The delegation was cleared at 00:10:35 on October 30 by this transaction. It was sent by Binance 14 itself, with the authorization pointing at 0x0.

• It is a self-sponsored authorization: the sender and the signer are the same account.
• The transaction nonce is 18914903 and the authorization nonce is 18914904. The sender's nonce is incremented before authorizations are processed. So the authorization must use nonce + 1.
• Binance sent 93 transactions from this wallet while it was delegated. The last one was at 00:07:11.
• Binance revoked the delegation with its own key. That means it never lost its signing ability. This is consistent with the official statement that no private key leaked.

6. The intrusion mechanism — reasoning backward from the evidence

Binance has not disclosed the path from laptop to signature. Still, the evidence narrows the possibilities a lot. Let's start from the typical structure of an exchange hot wallet. Then let's see which paths the evidence allows and which it rules out.

6.1 The typical exchange withdrawal pipeline

A large exchange's hot wallet is usually split into these layers.

Just like the Secure Enclave in a phone wallet, a signer never exports its key. Instead, it signs the requests it receives. So the attacker's target is not the key. It is some layer in front of the signer.

6.2 Constraints the evidence imposes

6.3 Comparing hypotheses

The simplest picture that satisfies all these constraints is H1 + H2. It goes like this.

1. Obtain cloud and cluster credentials from the DevOps endpoint.
2. Get into a withdrawal-related service container.
3. Use the signing-request rights that container already had.
4. On the other chains, submit requests in ordinary withdrawal format (H1).
5. On Ethereum, get an authorization digest signed that the policy engine cannot interpret (H2).

H4 fits the "DevOps" entry point well enough that it can't be ruled out. H3 fits the official wording least.

6.4 Initial access — TraderTraitor's known playbook

How the laptop was infected has not been disclosed. But the playbook of TraderTraitor, the group named as the likely culprit, is on the official record.

All three follow the same arc: developer or ops endpoint → stolen session credentials → lateral movement disguised as a legitimate user. A session token has already passed MFA. So stealing one neutralizes MFA. The way the Bybit attackers wiped their traces also resembles the "self-destruct mechanism" Binance mentioned. Did Binance's laptop go down the same road? That is a question for the post-mortem.

6.5 Why one authorization signature is more dangerous than thousands of withdrawals

Signing an EIP-7702 authorization means signing a different message than a transaction.

EIP-1559 transaction signature:  keccak256(0x02 || rlp([chain_id, nonce, ..., to, value, data, ...]))
EIP-7702 authorization signature: keccak256(0x05 || rlp([chain_id, address, nonce]))

To a signer, both are just 32-byte hashes. A policy engine usually checks decoded transactions: recipient, amount, calldata. An authorization digest has no recipient and no amount. If the signing API accepts raw hashes, an authorization signature looks to the policy engine like nothing at all. That is why H2 fits the official wording ("did not pass through approval controls") so well.

And the authority each signature hands over is in a different league.

Key insight — A withdrawal signature is a signature over an amount. A delegation signature is a signature over the account itself. If signing policy only looks at amounts, the most dangerous signature gets the least scrutiny.

7. The freeze race — 37 minutes and 200 million USDT

• From the first sweep (20:24) to Tether's freeze (21:01) took 37 minutes. About 644 million USDT got out in that window.
• The 21:44 sweep sent 200.4 million USDT to an address that was already frozen. The USDT contract checks the blacklist only for the sender. It doesn't block the recipient. So those funds were locked the moment they arrived.
• The attacker didn't switch receiving addresses until 22:39, an hour and 38 minutes after the freeze.

Automation failure on both sides — Binance kept sending deposits into a compromised wallet. The attacker kept sending funds to a frozen address. Both were running automation that never checked the other side's state.

Native assets like BTC, XRP, SOL, and NEAR cannot be frozen. None have been. By Elliptic's count, the attacker still holds about $3.33 billion. A freeze blocks disposal. It is not recovery.

8. Market side effects — a 38% premium and MEV

The attacker rushed to swap USDT for ETH before the freezes. That opened a wide gap between DEX and CEX prices. Elliptic found the attacker chose speed over price, accepting losses of 12–26% versus market.

The Uniswap v3 WETH/USDT 0.05% pool shows the story block by block. Before the hack, the price was about 2,320 USDT. It began rising at 20:36 and hit 2,917 at 20:49. The peak was 3,328.6 at 21:09:11. By 21:36 it was back to normal. That matches, to the minute, HOW TO ONCHAIN's report of "a 38% premium over market at 21:09."

According to the same analysis, most of that spread went to MEV bots. Of the $44.9 million in WETH arbitrage PnL, most went to 78 bots. ETH priority tips that night reached 10,251 ETH. That is about 2,200 times the 4.6 ETH of the same window the day before. The attacker's haste became profit for the bots that bought block space.

9. Attribution — what is and isn't established

TRM Labs points to North Korea's TraderTraitor with "high confidence." Chainalysis and Elliptic reached the same conclusion through their own analyses. The FBI, however, said only that it is "aware of the incident and engaged with partners." It has not formally attributed it.

10. Comparison with Bybit (2025)

In both cases, "who signs" was not the problem. What broke was "who decides what gets signed."

11. Defensive design — treating signing infrastructure as a security boundary

Monitoring for delegation is simpler than it sounds. Just watch for an EOA that should have no code suddenly carrying a delegation designator.

// EIP-7702 delegation monitor for treasury EOAs (concept code)
const DELEGATION_PREFIX = "0xef0100"; // EIP-7702 delegation designator prefix
const POLL_INTERVAL_MS = 12_000;      // check once per Ethereum block (~12 s)
 
async function watchDelegation(eoa: `0x${string}`, alert: (target: string) => void) {
  for (;;) {
    const code = await client.getCode({ address: eoa });
    if (code?.startsWith(DELEGATION_PREFIX)) {
      alert(`0x${code.slice(DELEGATION_PREFIX.length)}`); // delegation target address
    }
    await new Promise((r) => setTimeout(r, POLL_INTERVAL_MS));
  }
}

In production, there is a faster way than polling. Recover the signers of authorizationList entries in each new block's type-4 transactions and match them against your addresses. That flags an authorization the moment it lands in a block.

Practical recommendation — "Who can request a signature" matters more than "where the key lives." The signing policy engine is as important a security boundary as the key-custody hardware. Signatures that change the nature of the account, like EIP-7702, belong in a different tier from ordinary withdrawals.

12. What's established and what remains

What's established is clear. The attacker went through a DevOps engineer's laptop into an internal service container. From there, they submitted unauthorized withdrawals. Binance did not lose its private keys. On Ethereum, EIP-7702 authorizations spanning 50 nonces delegated Binance 14 to a sweeper. Binance revoked the delegation with its own key 3 hours and 49 minutes later.

The open questions are just as clear. How was the laptop infected? What were the additional breach points? Through what path did the signing requests bypass the policy engine? Was the signing system an HSM or MPC? Is the culprit really TraderTraitor? Binance's post-mortem needs to answer these. Above all, it should show which hypothesis in §6 was right.

13. Conclusion

Binance didn't lose its keys. It lost the authority to decide what gets signed.

• The keys didn't leak, but the funds were stolen. The signing-delegation paradox happened at exchange scale.
• The security boundary must extend from the key to every signing-request path. The whole chain — laptop → container → signing system — belongs in the threat model.
• A withdrawal signature is a signature over an amount; a delegation signature is a signature over the account. If signing policy only looks at amounts, the most dangerous signature gets the least scrutiny.
• Response speed sets the size of the loss. Tether took 37 minutes to freeze. Revocation took 3 hours 49 minutes. Deposits kept flowing in after withdrawals were halted.

So was EIP-7702 the cause? The other 10 chains were drained without it. On Ethereum, though, a single delegation signature handed over the entire wallet. That included every deposit still to come. That is why the same intrusion grew into a 3-hour-49-minute account takeover.

In the end, the question isn't "is EIP-7702 dangerous?" It is "does our signing system know how much a signature weighs?" A signature that moves an amount and one that hands over an account look like the same 32-byte hash. But they can never sit in the same tier. Security extends to knowing what you're signing.

Appendix — Verifying it hands-on

Every on-chain claim in this piece can be reproduced with public RPC alone. All you need is one Ethereum node that serves archive queries.

• When the delegation was set and cleared — Call eth_getCode on Binance 14 across block numbers. A binary search finds two blocks: block 26300753, where the code became 0xef010063e8…, and block 26301896, where it returned to 0x.
• The 50 authorizations and their order — Read the nonces from the delegation transaction's authorizationList. They descend from 18914824 to 18914775.
• Every attacker transaction — Recursively locate only the blocks where the attacker EOA's eth_getTransactionCount changes. You can rebuild nonces 0–22 without an indexer.
• Freeze times — eth_call USDT's getBlackListStatus(address) and USDC's isBlacklisted(address) across blocks. That reveals the blacklisting block.
• The Uniswap peak — Read sqrtPriceX96 from the pool's slot0() and convert it to a price. You'll see 3,328.6 at 21:09:11.

Sources

Section numbers in parentheses show where each source is used.

Official statements

• Binance — Security Incident Update (2026-10-30) (§1, §12)

On-chain analysis reports

• TRM Labs — North Korea Steals USD 6.36 Billion From Binance in the Largest Hack in History (§2, §3, §5, §6, §9)
• Elliptic — The largest theft in history: DPRK behind the $6.4 billion Binance hack (§2, §3, §7, §8, §9)
• Chainalysis — The $6.4 Billion Binance Exploit: Tracing the North Korea Link (§9)
• HOW TO ONCHAIN — Behind the Binance hack: arbitrage and MEV (Korean) (§8)

Coverage

• Cointelegraph — Live updates: Binance hack (§1, §3, §6 — Richard Teng and Blockaid CEO remarks)
• CryptoSlate — Binance uncovers more breach points in $6 billion hack (§1, §6)
• CNN — North Korea suspected to be behind biggest-ever heist (§9 — FBI statement)
• BleepingComputer — Binance links $6.3 billion crypto theft to compromised DevOps laptop (§1)

TraderTraitor's past playbook

• CISA — AA22-108A: TraderTraitor: North Korean State-Sponsored APT Targets Blockchain Companies (§6.4)
• FBI — Identification of North Korean Cyber Actors, Tracked as TraderTraitor, Responsible for Theft of $308 Million USD from Bitcoin.DMM.com (§6.4)
• Cointelegraph — Safe Wallet releases Bybit hack post-mortem (§6.4, §10)

Standards

• EIP-7702: Set Code for EOAs (§4, §6.5)

On-chain evidence (queried directly)

• Delegation transaction — 0xad99264d…051298b (§5.2)
• Revocation transaction — 0xafbf94c9… (§5.4)
• Binance 14 — 0x28C6…1d60 (§5)
• Attacker EOA — 0x7c86…5ca0 (§5.1, §5.3)
• Sweeper contract — 0x63e8…6fAe (§5.1)
• Frozen receiving address — 0x5227…2f8c (§7)
• Uniswap v3 WETH/USDT 0.05% pool — 0x11b8…97F6 (§8)

Related post

• Can Storing Your Wallet Keys on a Phone Ever Be Perfectly Secure? — the signing-delegation paradox (§3, §6.1)