The Binance hack is very likely the largest theft of any kind on record, and as far as anyone can tell, no private key was stolen to pull it off. Starting at 20:05 UTC on October 29, 2026, Binance hot wallets on at least ten blockchains sent out most of about $6.3 billion by Binance’s estimate within half an hour, and every transfer carried a valid Binance signature. If your organization runs anything that signs on request, whether it releases payments, publishes code or deploys to production, study this one closely, because the cryptography held and the path to the signer did not.
The moment we keep coming back to happened at 20:20:59 UTC. Binance 14, one of the exchange’s Ethereum hot wallets, signed a single transaction carrying 50 EIP-7702 authorizations, and three minutes and 24 seconds later it swept about $2.5 billion in ETH and tokens to the attacker. Binance says it has found no evidence of a private key leak. The wallet signed the permission that emptied it.
What happened in the Binance hack
The preparation started a day early, and the theft took about half an hour.
- October 28: three small Tornado Cash withdrawals fund a new operator wallet, at least 36 hours before the theft, per TRM Labs.
- October 29, 15:59 UTC: after rehearsals on its own wallets, the attacker deploys the sweeper contract, according to Elliptic.
- 20:05 to 20:09 UTC: five Binance XRP Ledger wallets send 233.46 million XRP to one address, and wallets on Solana and Optimism follow.
- 20:20 UTC: the Bitcoin hot wallet sends 18,270 BTC, and within two minutes a Tron wallet sends 612.7 million USDT.
- 20:20:59 and 20:24:23 UTC: the EIP-7702 delegation on Binance 14, then the $2.5 billion sweep.
- 21:01 and 21:04 UTC: Tether freezes 971.1 million USDT and Circle freezes 823 million USDC in the main receiving wallet, TRM reports. The still-delegated wallet is swept again several times, the last at 23:56 UTC.
- October 30, 00:10 UTC: Binance 14 revokes the delegation, nearly four hours after granting it.
- October 30: Binance publishes a Security Incident Update with withdrawals suspended, reported by The Hacker News, and co-CEO Richard Teng later sets Sunday as the target for reopening them.
How one EIP-7702 delegation emptied Binance 14
EIP-7702, live on Ethereum since the Pectra upgrade in May 2025, lets an ordinary account run contract code by signing an authorization tied to its nonce. The delegation stays in place until the account replaces it. CoinDesk’s reconstruction makes the uncomfortable point plainly. The authorization names the code the account will run, not a recipient or an amount, so a control that checks destinations and values has nothing to read. The code was an unverified sweeper that only the attacker’s operator wallet could call, built to move every listed token and the ETH at once.
The 50 authorizations are the detail we would show any team that runs a signing service. Binance 14 kept processing customer withdrawals, so its nonce kept moving, and the attacker covered a range of consecutive nonces so that one would land. Someone holding the key would sign once, at the live nonce. Fifty signatures prepared in advance look instead like an attacker who could ask a signing system for signatures but could not see the wallet’s state. TRM reads it the same way, suggesting the access may have been limited in time or routed through a request system.
Ethereum is just where it shows best. Wallets on different chains, with different key types and signing schemes, all produced valid signatures within about half an hour. TRM’s most likely explanation is an attacker who could make Binance’s hot wallet signing system sign whatever it chose. Elliptic says the attacker got Binance’s own systems to sign on its behalf, and that the infrastructure and people around the wallets were compromised, “not the cryptography”.
A DevOps laptop, a service container, and what Binance has not said
That raises the question of how the attacker got close enough to ask. Binance’s initial account, in the update quoted by The Hacker News, is that the incident may involve a compromised DevOps engineer’s laptop, which gave the attacker access to a service container that could submit withdrawal transactions. Teng has since stressed that the attacker “did not simply use one engineer’s permissions”, and Binance later said its investigation had uncovered additional points of breach that it has not described. In a video summarized by CoinDesk, Teng said EIP-7702 let the attacker take a hot wallet without Binance’s normal approval procedures.
Nobody has said how the laptop was compromised. Fake job offers and poisoned coding tests fit North Korea’s record, and Elliptic’s Tom Robinson notes that “it only takes one compromised laptop”. For this incident that is still an analogy, so we would not build a control plan around one delivery method.
TraderTraitor and the North Korea crypto hack playbook
The staging is what investigators recognized first. TRM attributes the theft to TraderTraitor, North Korea’s elite hacking unit, with high confidence. It points to the pattern seen at Bybit and KelpDAO, with small Tornado Cash withdrawals, staging well before the theft, signatures obtained in advance and one fast burst. Chainalysis reaches the same conclusion, citing stolen Binance funds commingling with proceeds of last month’s Bitget exploit.
Elliptic is more careful. It calls a North Korean link likely but not yet certain, because the overlap is small and laundering networks serve many clients. No government has confirmed attribution, and the FBI says only that it is aware of the incident. For Bybit, the FBI named TraderTraitor five days after the theft. The laundering ran at machine pace too, which Asset Reality’s chief executive called “agentic money laundering”, and our look at offensive agentic AI explains why that speed will become normal.
The biggest crypto hack on record, and the 44% that was frozen
No crypto theft has come close. By Elliptic’s count the theft reached $6.43 billion across 11 blockchains, more than four times Bybit, the previous record.
The freezes are the other half of the story, and they worked because most of the loot was stablecoins with an issuer who could act. Elliptic counts $2.84 billion frozen, 44% of the theft, with nothing frozen on Bitcoin, the XRP Ledger or Solana, and Robinson does not expect the frozen share to rise much further.
| Period | Value |
|---|---|
| Stolen | $6.43B |
| Frozen | $2.84B |
| Not frozen | $3.28B |
Binance says it will cover every loss from its SAFU fund and company money, and it has set aside more than $6.34 billion to do it. Fundstrat’s Sean Farrell sees no meaningful solvency risk for the exchange. Few other exchanges or custodians could absorb a loss on this scale.
The weak point is the path to the signer
Go back to that 20:20:59 signature. Binance’s signing system did what signing systems exist to do, which is produce a valid signature for a request that arrived through an authorized path. Controls built around the key, however strong, assume the request is honest. Once an attacker sits in a container that is allowed to ask, those controls sign for the attacker.
This is not only a crypto problem. We see the same shape in code-signing pipelines, payment release systems and cloud deployment roles, where a workload identity can ask a signer for almost anything and that identity is reachable from an engineer’s laptop. OKX founder Star Xu said the next day that a compromised wallet management system “should not be able to bypass these fundamental security restrictions”. The checks that would have mattered here belong inside the signer. One is a policy that refuses an EIP-7702 authorization on a treasury wallet unless one is expected. Another refuses any request for dozens of authorizations across a nonce range, which TRM calls an indicator of compromise. A third gives each chain and wallet tier its own signing path, so one foothold cannot reach ten blockchains.
There was also a window to catch it. The delegation sat on-chain for three minutes and 24 seconds before the sweep, and the wallet stayed delegated for nearly four hours. An alert on contract code appearing at an address that should have none, with a revocation already tested, is what TRM recommends, and it would have fired on the first block. If you have never inventoried which workload identities can reach your signers, our guide to non-human identity management is the place to start, and mapping those paths is the kind of review our security engineering team runs.
What to ask your team this week
- Which systems sign or release value on request (payments, code signing, deploy keys, wallets), and which identities are allowed to ask them?
- Can any of those identities be reached from an engineer’s laptop, and what would an attacker on that laptop need to submit a request?
- Does the signer enforce its own policy on destinations, amounts and request patterns, or does it trust the caller to have checked?
- Would a request shaped like the one Binance 14 signed, 50 authorizations across consecutive nonces, be refused or flagged before anything was signed?
- How fast can we revoke a delegation, token or role the signer has issued, and when did we last rehearse it?
Bottom line
Binance lost about $6.3 billion without, by its own account so far, losing a key. Put the policy check inside the signer, alert on anything that changes what a treasury account or signing role can do, and treat every laptop that can reach the signing path as a way in.