On October 29, 2026, attackers took an estimated $6.3 billion from Binance hot wallets. TRM Labs traced transfers across ten blockchains and describes the incident as the largest crypto theft on record, roughly four times the $1.5 billion Bybit hack of February 2025.
Binance says it has found no evidence that a wallet private key leaked. Its preliminary findings, and TRM Labs' analysis, point instead to misuse of Binance's own withdrawal and signing systems. The exact compromise is still under investigation.
The public findings so far point toward weaknesses in transaction authorization. They do not establish a break in the underlying cryptographic algorithms, or settle whether private keys were exposed. Below is our review of the available reporting as of October 31, how the attack appears to have worked, and the controls we would examine for a wallet, exchange or DeFi treasury.
The Binance hack at a glance
These are the public findings reviewed on October 31, 2026, with their sources. Several remain preliminary, and each estimate reflects its source's reporting cutoff.
| Question | What's been reported |
|---|---|
| When did it happen? | October 29, 2026. TRM Labs places the first thefts around 20:05 UTC (TRM Labs) |
| How much was taken? | Binance estimates an impact of about $6.3 billion. TRM estimates $6.36 billion, valuing assets when they were taken |
| How much is frozen? | Binance reports approximately $3 billion frozen on-chain. Frozen assets have not necessarily been recovered |
| How did the attacker get in? | Binance initially suspected a compromised DevOps laptop and subsequently reported additional breach points. The full entry route and sequence remain under investigation |
| Were private keys stolen? | Binance says it has found no evidence of a private key leak |
| What happened on Ethereum? | A signed EIP-7702 authorization delegated a hot wallet to an attacker's sweeper contract, per TRM and Blockaid |
| Who is suspected? | TRM attributes it with high confidence to TraderTraitor, a North Korean group, and Chainalysis also points to that group. Binance has not named an attacker |
| What has Binance promised? | Full coverage; Binance says it has reserved over $6.34 billion in company funds. This is a company-reported figure |
| What was the previous record? | Bybit, about $1.5 billion, in February 2025 |
How the Binance hack happened
Binance has not yet published its detailed technical post-mortem. Based on its preliminary statement and TRM's reconstruction, the attacker appears to have made Binance's own systems sign the transfers, chain after chain.
Times are UTC and come from TRM Labs unless noted.
- Preparation, October 28 and 29. TRM traces preparations to at least 36 hours before the theft, including three small Tornado Cash withdrawals that funded the operator wallet. The attack code was tested on two wallets, rehearsed on a third, then installed on a Binance hot wallet about four hours later.
- Initial access. Binance first pointed to a potentially compromised DevOps engineer's laptop that gave access to a service container able to submit withdrawals. Its October 30 investigation update reports "additional points of breach," and co-CEO Richard Teng said the attacker "did not simply use one engineer's permissions" (Decrypt). Binance has not attributed responsibility to any individual.
- From about 20:05, XRP, Solana and Optimism. Five Binance XRP Ledger wallets sent 233.46 million XRP to one attacker address. Binance wallets on Solana and Optimism followed.
- 20:20, Bitcoin. A Binance hot wallet sent 18,270 BTC to one address, which split it into round pieces in the same block. CoinDesk's trace found the transfers looked like ordinary withdrawals and carried valid Binance signatures (CoinDesk).
- 20:20, Ethereum. TRM reports that one transaction carried 50 pre-signed EIP-7702 authorizations from the same Binance Ethereum hot wallet, covering consecutive nonce values. A valid authorization delegated that wallet to the attacker's sweeper contract. The signatures alone do not establish how the attacker obtained them.
- Around 20:22 to 20:24, Tron and Ethereum. A Tron hot wallet sent 612.7 million USDT and 46.4 million TRX. About three and a half minutes after the delegation, the Ethereum hot wallet's balance left: 167,464 ETH and 63 tokens, including 1.615 billion USDT.
- The hours after. The delegation stayed live, and the sweeper drained new Ethereum deposits several more times, the last at 23:56. A second wave hit Avalanche and Polygon at 23:05.
- Containment. Tether's first freeze came at 21:01. In a late October 29 update, Binance put total frozen assets at about $3 billion (CoinDesk). Binance revoked the delegation and paused withdrawals. The FBI told Reuters it is "aware of the incident and is engaged with relevant public and private partners." A person familiar with the situation told Reuters that Binance is also working with the US Secret Service.
EIP-7702 explains only the Ethereum part
The delegation accounts for one Ethereum hot wallet. Funds also left Binance wallets on XRP, Bitcoin, Solana, Tron and other chains in the same window, and the bitcoin moved with valid Binance signatures. Blockaid reports that eleven Binance hot wallet keys "signed transfers to an address created minutes earlier." That shows how broad the compromise was, though not yet how the signatures were obtained. The spread across ten chains in minutes is why TRM's assessment points to a compromise of Binance's hot wallet signing infrastructure rather than a bug on one chain.
On Ethereum, the 50 authorizations had a practical reason. Each one applies only if its nonce matches the wallet's current nonce at execution, and this busy wallet's nonce kept moving with every withdrawal. Signing a range raised the odds that one would match. Non-matching authorizations are skipped, though the sender still pays gas for every one included (EIP-7702 specification).
Why it looks like a signing failure, not a cryptography failure
The public evidence so far points to an authorization failure. The stolen bitcoin carried valid signatures, and the reported Ethereum drain used a protocol feature working as specified. Valid signatures alone do not establish whether keys were exposed or a legitimate signer was misused.
Some early coverage tied the hack to fears that AI could undermine cryptography. The public findings reviewed here do not establish that explanation. They point toward three areas of transaction authorization and operational security:
- Who could request a signature. The full route to the withdrawal service is still being investigated.
- What the signer would sign. An Ethereum hot wallet signed delegations to an attacker's contract.
- How fast the system reacted. Most of the theft happened within about 20 minutes, per TRM.
As a threat model, consider a vault with an intact lock and a compromised approval process. Strengthening the lock alone would not repair that process. This illustrates why authorization needs its own controls; it does not establish exactly how Binance was compromised.
Bybit's February 2025 loss involved a different approval failure. Bybit's forensic update describes compromised Safe{Wallet} infrastructure that deceived signers into approving a malicious transaction. The FBI attributed that theft to TraderTraitor, the group TRM suspects in the Binance incident.
Our post-quantum security work addresses threats to cryptographic algorithms. Post-quantum cryptography alone does not prevent a compromised system from requesting or approving a malicious transaction. Transaction authorization needs its own controls.
7 hot wallet security lessons from the Binance hack
If you run an exchange, a DeFi treasury or any hot wallet, these are the controls we'd review this week.
1. Enforce signing policy where the requester can't change it
Hardware security modules (HSMs) and multiparty computation (MPC) can protect key material, but key isolation alone does not establish whether a signing request is authorized. Allowlist transaction types, destinations and amounts in a policy layer the withdrawal service can't modify. Anything outside the list should need a separate human approval on a separate device.
2. Reject unexpected EIP-7702 authorizations
Configure signers to refuse unexpected EIP-7702 authorizations by default. The authorization signing preimage uses the 0x05 prefix; the outer set-code transaction is type 0x04. Enable delegation only for an explicitly approved wallet design.
Then watch for it. A delegated account's code begins with 0xef0100 followed by the contract address, so checking hot wallets with eth_getCode on every block flags it quickly. Treat that as detection, and pair it with the preventive controls above and a tested containment plan.
3. Restrict developer access to signing systems
Review every route by which a developer session could reach withdrawal infrastructure. Access from developer machines to anything near signing should be short-lived, approved per session and tied to hardware security keys. Signing services belong on an isolated network that everyday developer access can't reach.
4. Enforce outflow limits outside the withdrawal service
Most of this theft happened within about 20 minutes, per TRM. Per-transaction and aggregate outflow limits, plus automatic pauses on abnormal volume, should live in controls the withdrawal service can't change or bypass. A limit the attacker's foothold can edit isn't a limit.
5. Keep hot wallet balances small
One Ethereum hot wallet held 167,464 ETH and 1.615 billion USDT when it was drained. Size each hot wallet to short-term withdrawal demand, and refill from cold storage through a separately controlled process.
6. Know which assets can be frozen, and how fast
Tether's first freeze came 37 minutes after the main Ethereum sweep. As freezes spread, the attacker sold about 325 million USDT for ETH at a discount of more than 10%, per TRM. As of 00:30 UTC on October 30, TRM saw the attacker holding more than 420,000 ETH and 18,270 BTC, about $2.4 billion beyond any issuer's reach (TRM Labs). Exchanges and swap services can still block those funds if they pass through. Map which of your assets have issuer controls, and set up contacts at Tether, Circle and chain security councils before you need them.
7. Contain the signer and stop the drain together
The malicious delegation kept sweeping new Ethereum deposits for over three hours after the drain. Revoking it isn't enough while the attacker can still obtain new signatures, and revocation itself needs a signature from the wallet. Treat both as one emergency step: contain the compromised signing path and revoke through a trusted one. Then migrate remaining assets and redirect new deposits.
What Binance has said about customer funds
In its October 30 Security Incident Update #2, Binance says it has reserved more than $6.34 billion in company funds, including about $5 billion in the affected token assets, and is buying the remainder. It separately reports roughly $3 billion frozen on-chain. These are company statements; frozen funds are not necessarily recovered funds.
Binance says it has contained compromised infrastructure and revoked affected authorizations. It targets a phased withdrawal restart within approximately 34 hours of that statement, subject to security checks. Deposits and unaffected services remain operational, according to Binance. The 34-hour window is its stated estimate, not a confirmed reopening or a countdown from this article's update.
Binance plans to publish Proof of Reserves results by Monday, November 2, and further verified technical findings within about 48 hours of its statement. A detailed post-mortem is also planned. Those targets do not establish a final root cause. Check Binance's official channels for current service availability.
Binance hack FAQ
How much was stolen in the Binance hack?
Binance estimates about $6.3 billion. TRM Labs reports $6.36 billion across ten blockchains, while Chainalysis's October 30 report puts the value at approximately $6.4 billion. Elliptic's October 30 analysis reports $6.43 billion across 11 chains, including NEAR. These are distinct reported estimates with different coverage and valuation cutoffs, not one independently reconciled total. Binance reports roughly $3 billion frozen, which is not the same as recovered.
Were Binance's private keys stolen?
Binance says it has found no evidence of a private key leak. TRM's assessment points to a compromise of Binance's hot wallet signing infrastructure. Binance's post-mortem may clarify whether keys were exposed and how the unauthorized signatures were obtained.
What is EIP-7702?
EIP-7702 is an Ethereum feature, added in the May 2025 Pectra upgrade, that lets a regular wallet delegate its behavior to a smart contract through a signed authorization. It enables things like batched transactions. Abused, one signed authorization can hand an attacker control of a wallet.
Is this the biggest crypto hack in history?
By reported value, yes. At an estimated $6.3 billion, it is roughly four times the previous record, the $1.5 billion Bybit hack in February 2025.
What to test in your wallet security review
The public findings make a practical case for reviewing both key protection and transaction authorization. A security review should test whether an attacker can obtain a key and whether an attacker can make the legitimate system sign an unauthorized transaction. These are review priorities, not a claim that a particular control would certainly have prevented this incident.
Security engineering at VTS Labs
Test the paths an attacker could use.
VTS Labs designs, builds and reviews blockchain infrastructure and smart contracts. Our work spans contract permissions, application integrations, validator operations and production monitoring. Cybersecurity connects each of those layers: who can act, what they can authorize and how the system responds when access is compromised.
For a platform that holds crypto, we would structure the review around four practical questions:
- Signing and authorization. Can a compromised application, developer account or service obtain a signature for an unapproved transaction?
- Privilege and access. Are production access, administrative actions and signing permissions separated and limited?
- Loss containment. Do transaction limits and destination controls still hold if the withdrawal service is compromised?
- Detection and recovery. Who can halt signing, revoke permissions and restore service, and has that response been rehearsed?
Experience in production. On Krown Network, our work includes validator operations with controlled key management and slashing protection, documented recovery procedures, and ongoing monitoring and remediation across the network's infrastructure.
Our security capabilities also extend to post-quantum implementation, migration planning and cryptographic architecture. We help teams prepare for evolving cryptographic threats while addressing the operational controls their systems depend on today: restricted access, explicit signing permissions, transaction policies and tested recovery procedures.
A useful review turns these questions into documented findings, prioritized fixes and tests that demonstrate whether the controls hold.
Planning a launch or reviewing an existing wallet, exchange or digital asset platform? Book a technical call with our team to define the architecture, contract and operational review your system needs.
Editor's note: Published October 30 and updated October 31, 2026, to incorporate Binance's Security Incident Update #2, clarify the Ethereum authorizations and distinguish reported loss estimates. VTS Labs has not independently examined Binance's internal systems. The root cause remains under investigation; our discussion of signing-system misuse is an assessment of public reporting. We will revisit the analysis when further verified technical findings are available.
Sources
- Security Incident Update #2, October 30, 2026, Binance
- The largest theft in history: North Korea likely behind the $6.4 billion Binance hack, Elliptic (updated October 30, 08:00 UTC)
- Security Incident Update, Binance
- North Korea Steals USD 6.36 Billion From Binance in the Largest Hack in History, TRM Labs
- Binance loses over $6 billion in 'biggest crypto hack in history', CoinDesk
- Binance hacker splits $1.4 billion of bitcoin into 19 wallets that no one can freeze, CoinDesk
- Binance hack: How one wallet trick led to a $6.3 billion breach, crypto.news
- EIP-7702: Set Code for EOAs, Ethereum Improvement Proposals
- Bybit forensic update on the Safe Wallet incident, Bybit
- North Korea Responsible for the Bybit Hack, FBI
- October 30 investigation and service update, Binance
- Binance arranges $6.34 billion to cover losses, CoinDesk
- The $6.4 Billion Binance Hack: Tracing the North Korea Link, Chainalysis
- Binance Finds 'Additional Points of Breach' in $6.3B Hack, Decrypt
- Binance hack analysis, Blockaid
- FBI and US Secret Service working with Binance after $6.3 billion hack, source says, Reuters
