Security · Incident Response · Web3
Binance Hack: $6.36bn Lost to a Delegation, Not a Key
Binance says no private key leaked. That is the confession: 50 EIP-7702 signatures turned its hot wallet into the attacker's contract.
Binance paused withdrawals on Wednesday night, told its customers their funds were completely safe, and the number attached to the hole kept climbing — three billion, then five, then about USD 6.36bn, the largest crypto theft on record. Then came the line meant to settle everyone down: "So far, we have found no evidence of any wallet private key leak."
That is the confession, not the comfort. No key had to leak. The hot wallet that bled for nearly four hours is the same wallet that later signed its own cleanup, with the same key Binance held the entire time. What the attacker took was not a secret. It was permission — fifty signatures handing the wallet's own code to a contract they controlled.
If you ship software for a living, the expensive part of this story is not the six billion. It is two things sitting underneath it, and both are decisions on your desk this quarter.
The USD 2.4bn with nobody to call
Money came back. Roughly USD 2.7bn of it, by TRM Labs' count, and it came back for one reason: private companies pressed freeze buttons on assets everybody describes as decentralised. Part of that we watched on-chain. Tether's USDT contract emitted eight AddedBlackList events between 21:01:35 and 21:18:59 UTC — the first 37 minutes after the main sweep — and all eight addresses still return true from isBlackListed(). Circle, Ripple and World Liberty Financial moved on their own tokens, per TRM's tracing.
The receiving wallet, 14 hours after the sweep: $2.11bn in 33 tokens, one hop from Binance. It is still there because issuers froze it, not because the ledger stopped anyone.
The roughly USD 2.4bn that TRM puts in ETH and BTC has no such button. Nobody issues ether. Nobody can blacklist a bitcoin address. That part is gone in the ordinary sense of the word.
Now take the crypto out, because this is what transfers to a payments integration, a logistics API or an AI vendor. Some of your dependencies can reverse a loss for you and some cannot, and the difference has nothing to do with how much you trust them. A card processor claws back a fraudulent charge. A stablecoin issuer freezes a balance. A custodian insures one. An L1 chain, an object store or an inference API cannot un-ring any bell at all. Which of yours sits on which side of that line is a due-diligence line item, and almost nobody writes it down before the day it matters.
What we verified, and what Binance is telling us about Binance
These are not claims of equal strength, and a post that blurs them is worse than no post.
We read the following off the Ethereum chain ourselves on 30 October 2026, over a public archive node: the delegation transaction and its fifty authorizations, their fifty consecutive nonces, the hot wallet's code afterwards, the main sweep of 1,615,409,498.97 USDT, a further 3,917,639.77 USDT that moved three minutes after Tether froze the destination, Tether's eight blacklist events, and the revocation transaction with its timestamp. Three of TRM's balances match balanceOf to the dollar.
Taken on trust, because an interested party reported it about its own work or its own books: the USD 6.36bn total and the USD 2.7bn recovered, both from TRM's tracing across ten chains, of which we checked only the Ethereum USDT leg. The attribution to North Korea's TraderTraitor — TRM at "high confidence", Chainalysis at "likely", no government confirmation yet, both vendors commercially interested in attributing first. The compromised DevOps laptop and the service container, which is co-CEO Richard Teng's account with no post-mortem behind it. "Rest assured that user funds are completely safe", plus the SAFU promise: Binance on Binance's solvency. And "only 1 of 50 was a hit", which Etherscan attributes to Blockaid — we confirmed fifty authorizations went in and one delegation came out, not which were individually valid.
The mechanism below is the verified half. The dollar figures are the reported half.
No private key was stolen. Fifty signatures were.
At 20:20:59 UTC on 29 October, one transaction landed in block 26300753. Type 4: an EIP-7702 transaction, allowed since Pectra. Its authorizationList held exactly fifty entries, every one pointing at the same contract, 0x63e842b0…9c6fae, over fifty consecutive nonces, 18,914,775 through 18,914,824.
One transaction, fifty authorizations, one destination. The money moved three minutes and twenty-four seconds later.
An EIP-7702 authorization is valid for exactly one nonce, and on a hot wallet processing a constant stream of withdrawals the nonce advances while you are still submitting. Fifty consecutive nonces is not fifty attempts, then — it is a window wide enough that one was certain to be live on arrival. A race-condition trick, not cryptography.
What landed changed the wallet itself. eth_getCode on Binance 14 returned 0xef010063e842b054bd624a465454d533c33f573e9c6fae: the delegation indicator EIP-7702 defines, 0xef0100 followed by an address. For as long as that stood, calls to Binance's hot wallet executed the attacker's code.
That is not a transfer. A transfer is a thing that happened. This is a standing grant that persists until somebody explicitly revokes it — which is why the sweeper kept draining deposits as they arrived, including 3.9m USDT into a wallet Tether had blacklisted three minutes earlier. The withdrawal that pushed 1.6bn USDT out was a boring type-2 transaction from an operator address. It worked because of what the wallet had become.
None of this was undocumented.
The spec's own Security Considerations: changing a delegation is "a security-critical operation that should not be done lightly". Written down long before the wallet was emptied.
Three hours and forty-six minutes
Binance removed the delegation at 00:10:35 UTC on 30 October, in block 26301896, with a type-4 transaction sent from the hot wallet itself carrying a single authorization pointing at the null address.
The fix, sent by the wallet to itself. Binance held the key the whole time. It took three hours and forty-nine minutes to use it.
The wallet signed its own revocation: Binance had the key throughout. Teng's statement is true, and that is the problem. The delegation stood for 3h 49m 36s, of which 3h 46m 12s was after the money started moving. No publisher we reviewed has put that number in print.
Nothing in the stack treated "our own signer just granted standing authority to new code" as an event worth waking anyone for. Balance alerts fire when the balance moves, which is after the loss by definition. The authorization change was the real alarm, it was public, and it sat on-chain for three minutes and twenty-four seconds before the first dollar left.
Your version of this has no blockchain in it. An API key behind an internal service, a CI runner with a deploy token, an OAuth app somebody installed in 2023, an agent with a tool it is allowed to call — we keep finding the same shape when we take AI-built systems to production, and we wrote up the credential half of it in AI agents and exposed credentials. Teams protect the secret and watch the balance. Nobody watches the scope.
What to decide this week
- Change the question in your security review. Not "can this secret leak?" but "what can the service holding this secret be made to sign, and who gets paged when it signs something new?" The first question has an answer you can document. The second has an owner, or it does not.
- Alarm on privilege change, not only on volume. A new IAM role binding, a new OAuth grant, a new webhook destination, a new delegation — these are rare events, so alerting on them is cheap and the pages are real. Volume anomaly detection would have caught this three minutes and twenty-four seconds too late. We argued the same thing from the opposite end in account takeover and cargo theft.
- Write down which dependencies can reverse a loss. One column, two values. In the production readiness reviews we run, the "can reverse" column is always shorter than the team expected.
Key takeaways
- Binance's "no evidence of any wallet private key leak" is consistent with the chain and is not reassuring: the theft needed authorization, not a key, and the wallet signed its own revocation 3h 49m later.
- One EIP-7702 type-4 transaction carried 50 authorizations across 50 consecutive nonces (18,914,775–18,914,824), all pointing at one sweeper, setting the hot wallet's code to
0xef0100plus the attacker's address. - A delegation is a standing grant, not a transfer: the sweeper kept draining new deposits for hours, including 3.9m USDT sent three minutes after Tether blacklisted the destination.
- The gap was detection. The delegation stood 3h 46m after the first sweep while monitoring watched balances instead of authorization changes.
- About USD 2.7bn came back because Tether, Circle, Ripple and World Liberty Financial chose to freeze it (TRM's figures); the roughly USD 2.4bn in ETH and BTC had nobody to call.