Binance says it has found no evidence of any wallet private key leak. TRM Labs counts about $6.36bn leaving Binance wallets on ten blockchains on 29 October 2026. Both can be true. Reconciling them takes one distinction, and it isn’t a cryptographic one.
Nobody has published evidence that a key was taken out of Binance. What the attacker held was the ability to put a request in front of the thing that holds the keys and have it honoured. TRM Labs labels that reading its own assessment, and says Binance “has yet to publish a root cause”. Key custody wasn’t the boundary.
Two things about the numbers. I read every source here on 31 October 2026 and named it in the sentence that uses it; anything outside quotation marks is a division you can redo. And the loss is contested — Binance says about $6.3bn, TRM Labs $6.36bn, Chainalysis about $6.4bn, Elliptic $6.43bn. Every division below uses TRM’s, the only total with a per-chain breakdown.
Update, 2 November 2026
Four things have moved since this went up on 31 October. I read these sources on 2 November 2026.
The FBI has named the attacker. Its alert of 31 October, reported by BleepingComputer, says “the Democratic People’s Republic of Korea (North Korea) was responsible for the theft” of “more than $6 billion USD in virtual assets from cryptocurrency exchange Binance, on or about October 29, 2026”, and names the group TraderTraitor. TRM Labs and Chainalysis had reached that attribution first; this is the first time a government has said it. The FBI says it has seen TraderTraitor “converting stolen assets primarily into Ethereum (ETH)” and expects the proceeds to be “further laundered through decentralized finance (DeFi) platforms”.
The Proof of Reserves slipped. Binance published a snapshot taken at midnight UTC on 31 October showing coverage at or above 100% for the named tokens. The full cryptographic proof, the one that lets a user check that their own balance sits in the liabilities, is now expected on 3 November rather than the 2 November promised below. The snapshot also predates the withdrawals.
Replacement stands at 90%, per CoinDesk, not the 78.9% derived below, and Binance says the rest is less liquid tokens it is still buying. Withdrawals resumed on 1 November: CNBC reports $4.65bn out against $1.01bn in between 06:00 and 15:30 UTC, which Binance puts at 2.1% of $171bn in total assets on its 28 October figures.
Nothing so far contradicts the argument below. Richard Teng has since said investigators “found additional breach points” beyond an initially suspected compromised employee laptop. No source has reported a private key taken out of Binance.
What does “no evidence of any wallet private key leak” actually mean?
Binance’s sentence says only that nobody has found the key copied out of where it lives. Compromise, in the standard governing key management, is wider. NIST SP 800-57 Part 1 Revision 5 defines it at section 2.1, printed page 8: “Compromise – The unauthorized disclosure, modification, substitution or use of sensitive key information …”. Four nouns, and the fourth is use. Section 5.5, 41 printed pages on at page 49, says what failure looks like: “Key compromise occurs when the protective mechanisms for the key fail (e.g., the confidentiality, integrity, or association of the key to its owner fail; see Section 6) and the key can no longer be trusted to provide the required security.” Association of a key to its owner is what fails when somebody else can ask it to sign.
Exchange key hardware draws the same line. PKCS #11 version 3.0 lets a key be marked so that, per section 4.9, “certain attributes of the private key cannot be revealed in plaintext outside the token”. Nothing says who may ask the token to sign. A key that can never be read signs all day. Table 26 carries the default worth checking: CKA_ALWAYS_AUTHENTICATE means “the user has to supply the PIN for each use (sign or decrypt) with the key”, and in the same row, “Default is CK_FALSE.” Out of the box a compliant signer authenticates a session once and grants every signature after it.
A finding that has not been made is a statement about where an investigation has looked. Binance’s is two days old and run by the party under investigation.
Key rotation wouldn’t have prevented any of this.
How the attacker got Binance’s own signer to sign
By asking it, with a signature the signer itself had produced. On Ethereum the attacker used EIP-7702 to make a Binance hot wallet run attacker-deployed code, then called it to sweep the wallet out. That delegation needs a valid signature from the wallet’s own key. TRM Labs reports one transaction at 20:20 UTC carrying 50 authorisations. The whole balance left three minutes and 24 seconds later. Chainalysis says the attacker “used an operational wallet funded through Tornado Cash to submit valid signed authorizations” — and nothing about where they came from.
Richard Teng, one of Binance’s two chief executives, gave the only line that names a control rather than a cause. Elliptic quotes him saying the delegation “did not pass through our normal approval controls”. Read that twice. Controls existed and weren’t consulted, which is a different failure from controls that said yes, and different again from controls that never covered delegation. Three readings, three fixes, and Binance has named none.
Binance’s own account and the on-chain reading are not the same claim, and the rest of this paragraph is my reasoning, not anybody’s finding. Binance says a compromised DevOps engineer’s laptop let an attacker reach a service container that could submit unauthorised withdrawal transactions, and abusing a withdrawal service produces ordinary transfers. An EIP-7702 authorisation is a different capability, a signature over chain id, address and nonce with nothing in it about a withdrawal. The two accounts reconcile only if that container could reach a signing path, which is TRM Labs’ assessment too, and Binance hasn’t published the step between.
(Elliptic dates the sweeper’s rehearsal on another wallet to “around four hours before it was used against Binance”. Hold on to that. It decides what a time-lock is worth.)
EIP-7702 explains at most 60% of the theft; $2.57bn moved with no delegation
Of TRM Labs’ $6.36bn, $3.79bn left on Ethereum, where the delegation lived, and the rest on nine chains that never saw one: $6,360,000,000 − $3,790,000,000 = $2,570,000,000, and $2.57bn / $6.36bn = 40.4%. TRM says those nine chains’ wallets “sent funds to the attacker through ordinary signed transfers”, so the delegation accounts for at most the other 59.6%, and not all of that: CoinDesk’s transfer list has 28,005.6 ETH leaving Binance 16, and Elliptic has that wallet signing its own transfers rather than carrying a delegation. The Ethereum figure holds from a second direction. Elliptic says “Two-thirds of the Ethereum losses, $2.53 billion, left in a single transaction at 20:24 UTC”, so its implied Ethereum total is $2.53bn × 3 / 2 = $3.795bn against TRM’s $3.79bn — two firms, separate counts, same number to three figures.
Delegation is the novel part and the smaller half. On nine chains the attacker needed no new Ethereum feature at all. Four of those nine — Arbitrum, Optimism, Base and Polygon — have shipped EIP-7702 support and were not attacked through it. The specification behaved as written: the code a delegation points at has “unrestricted access to the account”.
One thing I could not check. An authorisation signed with chain ID zero is valid on every EVM chain at once: step 1 of the specification’s behaviour list reads “Verify the chain ID is 0 or the ID of the current chain”. Whether these carried zero decides whether one signing request covered several chains or several did. The answer is in the authorization_list of that transaction in any explorer, and I didn’t open one.
Two exchanges, five weeks, and no stolen keys
Bitget’s chief executive said the same thing about her own exchange five weeks earlier. Gracy Chen, quoted in Hypernative’s write-up of that theft: “Private key compromise has been ruled out.” Chen’s own account is a compromised backend system inside Bitget’s wallet infrastructure, which fed spoofed withdrawal requests into an authorisation process that honoured them. Bitget revised its loss from $351.6m to $387.5m on 25 September, and Hypernative’s own count came to about $386.5m, within $1m of it.
Chainalysis and TRM Labs both attribute the Binance theft to TraderTraitor, a North Korean group, and Chainalysis says the stolen funds commingled on-chain with the Bitget proceeds. Elliptic goes only as far as DPRK-linked actors being likely, “although the attribution is not yet certain”. None of that changes the mechanism, which is why attribution comes last here.
The shape is older than both exchanges. A joint statement by Japan’s National Police Agency, the FBI and the US Defense Department Cyber Crime Center, published 24 December 2024 about DMM Bitcoin, says the actors are assessed to have used stolen access to tamper with a legitimate transaction request made by a DMM employee; 4,502.9 BTC left. That translation of the NPA’s Japanese is mine, because the English provisional translation omits the passage. The access ran on session-cookie information abused at Ginco, which the statement calls an enterprise crypto-wallet software company. A second factor authenticates a login, not a request.
Read the confused deputy problem, then read the incident again
Confused deputy is the name for this mechanism, and it sits in a document your team already has open. AWS’s IAM User Guide calls it a security issue “where an entity that doesn’t have permission to perform an action can coerce a more-privileged entity to perform the action”. OWASP’s Top 10 for Agentic Applications, dated 9 December 2025 on OWASP’s own resource page, files the pattern under ASI03, Identity and Privilege Abuse. Halborn reached the same reading from the chain data, under the heading “The lesson: the key was never the target”. Noticing it isn’t our move; naming the pattern and deriving a control from it is.
Our library holds half of this already: a read-only database role bounds the class of statement a caller can make, and has no opinion about the path a loss travels on. The claim here is worse. Binance’s withdrawal path held real authority, correctly scoped, used as granted — on TRM Labs’ reading, nothing in the permission model had grounds to object. That is the relationship the post-install script has with an integrity hash, “an input to the code that runs next, not a check on it”. And it extends the secret in the Spark config one level up, from credential copies to callers that can reach the signer.
You probably don’t run an exchange. You run something that signs or moves on request: a payments service that can issue a payout, a CI pipeline that can deploy, an agent with a tool. Same shape, different nouns. None of it is cryptography, which is why it belongs in software development and not a key-management review.
Which withdrawal authorisation controls are worth paying for
Cheap controls bound the loss and expensive ones prevent it. Start with a count. Call it the reachable-caller count: the number of distinct principals that can put a request in front of your signer and have it honoured. Ferrystone is this site’s invented payments ledger, and it stands in because I have no exchange of my own to count — its count is four: a withdrawal service, a sweep job, a deploy pipeline and a support tool, all chosen rather than measured. Our rule is that the signer refuses any principal not on that list, because a boundary holds where the system enforces it and not where a review does. EthSystems writes the corollary into the threat model of its MPC custody pattern: “a compromised or misconfigured policy engine can release signatures that violate the intended rules”.
A cap is derived from a tolerance, not picked, and the figures here are chosen. Decide the most you’ll move on the automated path before a person is in the loop. An hour of normal flow is where I’d start: read your p99 hourly outflow off the last ninety days, then set the budget above it at $100m an hour. An hourly budget doesn’t bound a burst, which is where the obvious version goes wrong: TRM Labs says most of the $6.36bn left in roughly 20 minutes from 20:05 UTC, an upper bound of $6,360,000,000 / 20 = $318m a minute. Enforce it as a rolling rate instead. $100,000,000 / 60 = $1.67m a minute, so a 20-minute window admits 20 × $1.67m = $33.3m, and $6,360,000,000 / $33,300,000 = 191: the cap holds the loss to about 1/191 of what left. Derate four-fold to $25m an hour and the ratio scales, 191 × 4 = 764. Double the window to 40 minutes and $100m admits $66.7m, about 1/95 of the loss. Nothing in that range flips it. A cap doesn’t need to be tight. It needs to exist.
The obvious reading of the window is wrong a second way: an EIP-7702 delegation is persistent state, not a one-shot transaction. Three minutes and 24 seconds is TRM Labs’ gap between the delegation and the first sweep, so 204 seconds looks like the number a timer has to beat. But Halborn dates Binance’s clearing of the delegation to 00:10:35 on 30 October, “three hours and fifty minutes after it was installed”, with six further sweeps in between. From 20:24 to 00:10 is 226 minutes, so 226 × 60 / 204 is about 66 times the interval the timer was chasing.
And here is the one I’d refuse to sell. A time-lock bought on its own is theatre. Gnosis Guild’s Zodiac Delay Modifier queues a transaction for a cooldown, and its README gives the cost in five words: “Transactions are executed in order.” Head-of-line blocking, and the delay helps only if somebody who can halt it is awake. Remember the rehearsal four hours earlier. The rota is the control, and the rota costs money.
What Binance’s incident report will have to explain (speculation)
Binance has promised a post-mortem and, per Cryptobriefing’s report of its second incident update, a Proof of Reserves by Monday 2 November. Nobody here has run a hot-wallet withdrawal service, so everything below is a guess resting on facts above.
Speculation: the post-mortem will describe a path that reached the signer with credentials some service held legitimately, rather than key material taken out of it, because Teng has already said the delegation didn’t pass through Binance’s normal approval controls. The 50 authorisations will be the hardest paragraph. An EIP-7702 authorisation nonce is the account’s own transaction nonce, which moves with every withdrawal, so somebody who could sign at will would sign once, at the moment of use. Halborn publishes the range as descending, “from 18,914,824 to 18,914,775”, or 49 nonces of headroom. My reading is a signing path reached briefly and expected to be lost, and TRM Labs reads it the same way.
The safest guess is that the Proof of Reserves shows balances and nothing about the request path. Binance’s second incident update says it has set aside “more than $6.34 billion in company funds”, of which “approximately $5 billion is already held in the same cryptocurrencies affected by the breach”. So $6.34bn − $5bn = $1.34bn is unmatched, and $5bn / $6.34bn = 78.9%, which is where Binance’s own “approximately 80% of the replacement assets” comes from. My guess is that the $1.34bn is still being bought, and purchases that size move the market they buy in.
What would make this wrong, plainly. If the post-mortem says key material was extracted from the signer and used outside it, the reading above collapses into an ordinary custody failure. One falsifier has already resolved: I’d have reconsidered the arithmetic if the delegation had been revoked within minutes, and Halborn’s timestamp puts it at three hours and fifty minutes.