publishHow can a wallet send billions to an attacker if its private key has not been shown to have leaked?
That is the uncomfortable question behind Binance's October 29 breach. A private key does not have to leave its protected environment for an attacker to cause damage. If someone can misuse the system that asks for signatures, the resulting transaction may be cryptographically valid and commercially disastrous.
This is the important distinction for anyone building payment infrastructure, a cloud signing service or an agent that can request consequential actions. Protecting a secret and controlling how that secret is used are separate engineering problems.
The complete Binance attack chain is still under investigation. This investigation was prepared from the public evidence available on October 31, 2026 and refreshed against Binance's November 1 recovery update before release. It explains what that evidence supports, what changed in the latest updates and how to read the technical claims without turning a plausible explanation into a proved root cause.
What the November 1 recovery update changed
Binance reported roughly $6.3 billion in affected token assets after unauthorized hot-wallet withdrawals. A hot wallet is an internet-connected operational wallet used to process transfers. On October 31, the FBI publicly attributed the theft to North Korea's TraderTraitor activity. That is a change from earlier reporting that described attribution only as an analytics firm's assessment.
The company initially discussed a possibly compromised engineer's laptop, then said it had found additional compromise points. In its incident update, Binance said it had found no evidence of wallet private-key compromise. This wording is narrower than proving that no key was ever exposed. The company had not published a complete technical reconstruction in the sources reviewed here.
Binance's November 1 Recovery Update #4 changed the recovery picture again. The company said it had replenished approximately 95% of affected assets, up from 90%, and planned to resume the first withdrawal phase between 06:00 and 09:00 UTC on November 1. The announced phase covers selected assets on 15 networks, with more combinations to follow after stability and security checks. It still expects complete cryptographic proofs on November 3 UTC. These are company-reported progress, plans and targets. They are not our independent audit or proof that a particular withdrawal completed.
Read the company incident update, the October 31 replenishment update, Recovery Update #4 and the October 31 FBI alert. A new event can change a live incident report faster than an article's headline changes.
Four different things that headlines call recovery
The most useful way to follow this story is to keep four receipts separate.
| Receipt | What it establishes | What it does not establish |
|---|---|---|
| Stolen assets traced | Investigators have associated transfers or addresses with the theft | The money has been returned |
| Assets frozen | Some assets cannot currently be moved through the relevant mechanism | Legal recovery is complete |
| Replacement assets purchased | The company reports obtaining assets to cover a shortfall | The attacker surrendered the stolen assets |
| Withdrawals restored and verified | The service can again complete the relevant customer withdrawal | Every technical weakness has been removed |
A proof-of-reserves snapshot is another piece of evidence, with its own scope and timestamp. It is not interchangeable with an incident postmortem, a complete financial audit or a successful withdrawal receipt. Read what each proof actually covers.
This distinction is practical. A dashboard can show a healthy balance while a withdrawal pipeline is still paused. A frozen token can remain unavailable to both the attacker and the victim. Neither situation is accurately described by a single green "recovered" label.
The Ethereum mechanism, without the mystique
TRM Labs reported that an Ethereum wallet was redirected using EIP-7702, while wallets on other chains made ordinary signed transfers. TRM interpreted the cross-chain pattern as evidence pointing toward access to hot-wallet signing infrastructure. That is its technical assessment, not a complete Binance-confirmed root cause.
EIP-7702 allows an externally owned Ethereum account to designate code for its behavior through a signed authorization. In ordinary language, an account can authorize another piece of code to act as its implementation. The authorization is an additional security-sensitive object to inspect, not merely another human-readable payment description.
The Ethereum specification describes the authorization and delegation rules. It does not say that every 7702 authorization is malicious, nor does the presence of 7702 explain how an attacker first obtained signing authority.
TRM's investigation describes a batch of authorizations and subsequent sweeps. The important architectural observation is that a signature can authorize behavior extending beyond the immediate transfer a reviewer expected to approve. An approval screen that describes only an amount and recipient may omit the authority being granted.
Other affected chains matter to the explanation. A mechanism specific to Ethereum cannot, by itself, explain ordinary signed transactions on Bitcoin, Solana and other networks. A good incident hypothesis must account for that broader evidence rather than treating the most unusual transaction type as the entire breach.
Why keeping the key secret is only one layer
Imagine a legitimate signing service whose private key remains inside protected hardware. The service accepts requests from an application. If the application has too much authority, an attacker who controls it may be able to request a harmful signature without ever exporting the key.
That is a general architectural example, not an assertion about Binance's unpublished implementation. It explains why "no evidence of a leaked key" and "unauthorized signed transactions" are not contradictory statements.
The blockchain can verify that a signature meets its rules. It cannot independently know whether a company's employee intended the action, whether the request crossed the company's approval threshold, or whether a downstream effect exceeded the allowed business purpose.
For cloud engineers, the lesson is to review the request path to signing, as well as the storage of signing material. The boundary should answer: which authenticated service can request which operation, against which destination, within which scope, and with which independent approval?
An AI agent raises the same authority question. A fluent explanation from a model is not authorization. An agent's proposed operation should remain a proposal until the execution system has enforced the allowed action and scope. The reporting reviewed here does not establish that AI caused or enabled Binance's breach.
What the different loss totals tell us
TRM reported about $6.36 billion across ten chains, valuing transfers at the time of theft in its dated analysis. Elliptic reported about $6.43 billion across eleven chains in its October 31 update. Binance's headline estimate was about $6.3 billion.
Do not average those figures into a supposedly more precise number. Different coverage, valuations and update times can produce different totals. The sources need to be reconciled before their numbers can be combined.
Likewise, an analyst's earlier frozen-funds count and a later company statement are not necessarily competing measurements of the same moment. Preserve the timestamp and definition. Elliptic's report explains its chain coverage and frozen-funds methodology; TRM's report describes its transfer valuation. Those details matter more than adding decimal places to a headline.
A useful next step for an engineering team
Choose one existing high-impact operation in a system you are authorized to review, such as a payout request or a credential rotation. Trace its actual request-to-effect path in your documentation and existing logs. Identify where authenticated identity, operation scope, destination, approval and final read-back are enforced.
Then ask a bounded question: if the calling application were compromised, which independent control would still reject an unauthorized request? If the answer is only "the key is encrypted" or "the model was told to be careful," the question has not been answered. Record the missing control for an authorized engineering review. Do not test production transfers or alter live permissions to follow this article.
For document retrieval, the same separation appears in our executed Qdrant permission tutorial: the closest result is not necessarily an authorized result. The mechanisms differ, but both systems need an enforceable boundary outside a convincing explanation.
What remains unresolved
The reviewed sources do not establish the complete initial-access chain, the precise set of failed approval controls or that all frozen assets have been returned. Binance's November 1 statement scheduled a phased withdrawal restart and said availability would vary by network and asset. That announcement is not an independent receipt that a specific withdrawal completed. A promised postmortem should be checked against the eventual technical evidence, not treated as already available.
There is a separate October story about attacks on AI developer platforms. Wiz's October 30 investigation reports stolen credentials and downstream model-access abuse. That is relevant to cloud teams, but it is a different investigation. We found no basis in these sources for joining it to Binance's attack chain.
Sources and method: This is a reported engineering investigation prepared on October 31, 2026 and refreshed on November 1 with Recovery Update #4, using the dated company updates, FBI alert, Ethereum specification, TRM analysis, Elliptic analysis and the separately identified Wiz report. AI assisted the research and writing. We did not inspect Binance's private infrastructure, execute transactions, independently attribute the attacker or audit company reserves. The article's architectural examples are explanations, not a claimed reconstruction or tested mitigation.