On Thursday evening, 29 October, a Binance hot wallet on Tron sent 612.7 million USDT and 46.4 million TRX to an address the exchange didn't control.

It took less than two minutes. Ethereum followed. So did Bitcoin, Solana, Optimism, and five other chains. By the time Binance paused withdrawals that night, an attacker had moved roughly $6.36 billion out of Binance wallets on ten blockchains, most of it in about 20 minutes, according to TRM Labs.

Nothing in crypto's history comes close. The previous record belonged to Bybit for just over 20 months, and the FBI put that theft at $1.5 billion, a little under a quarter of this one.

"It's the biggest hack in history."

Aravind Srinivasan, head of the systematic OTC business at market maker GSR, quoted by RTÉ

The size of the number isn't what kept me reading, though. This line from Binance did: the exchange said it had "found no evidence of any wallet private key leak." Every one of those transfers was validly signed. Bitcoin, Ethereum and Tron did exactly what they were built to do.

So how do you lose $6.3 billion without losing a key?

How an exchange actually holds your coins

A blockchain accepts any transfer that carries a valid signature for the sending address. It has no way to tell whether that signature came from the rightful owner or from someone who has taken over the process that produces it. Hold on to that point; the whole story turns on it.

Large exchanges keep most customer assets in cold storage (offline, and slow to move on purpose) and a smaller float in hot wallets, which sign automatically so your withdrawal clears in seconds. "Smaller" is relative. Binance held about $144 billion in custody before the attack, so this loss works out to roughly 4% of it.

A hot-wallet signer is, by design, an obedient machine. A request comes in, passes a policy check, and gets signed. The key itself sits in a hardware security module (HSM) or a multi-party computation (MPC) setup and never leaves. That keeps the key safe from theft. Whether each incoming request deserves a signature is a separate problem, and a harder one.

Step one: a DevOps engineer's laptop

Binance's first explanation was that the incident "may involve a compromised DevOps engineer's laptop," which let the attacker reach an internal service container able to submit withdrawal transactions.

The story grew the next day. Co-CEO Richard Teng said investigators had found additional intrusion points, that the attacker used a self-destruct mechanism to erase tools and traces, and that Binance is now reviewing endpoints, cloud systems, key management and signing processes across the whole company. It still hasn't said how the laptop was compromised.

"It involved a more complex attack process."

Binance co-CEO Richard Teng, in a post on X reported by Forbes

If that sounds familiar, it should. The Bybit theft also started on a developer's machine: attackers got into Safe{Wallet}'s environment and replaced a JavaScript file so that Bybit's signers approved a transaction they couldn't see clearly. Attackers who target crypto firms have spent years luring crypto developers into fake job interviews whose "coding tests" install malware. Nobody has confirmed that's what happened at Binance. It's the obvious first place to look.

Step two: fifty signatures and one wallet

On Ethereum, the attacker used EIP-7702, a feature that went live with the Pectra upgrade on 7 May 2025. It lets an ordinary wallet (an externally owned account, or EOA) point to smart-contract code and run that code as if it were its own. Wallet teams wanted it for batched transactions and sponsored gas fees. Turning it on needs exactly one thing: a signature from the wallet's own key.

At 20:20:59 UTC, the attacker submitted a single transaction carrying 50 EIP-7702 authorizations, all signed by the hot wallet labeled Binance 14. Each authorization is tied to the account's nonce, a counter that goes up by one with every transaction. A busy exchange wallet's nonce moves constantly, so the attacker prepared 50 consecutive ones; whichever matched at the moment of submission would work. One did.

That authorization pointed Binance 14 at a sweeper contract that took orders only from the attacker. Three minutes and 24 seconds later, the wallet sent out 167,464 ETH and 63 tokens, including 1.615 billion USDT. The delegation stayed in place afterwards, so customer deposits that kept landing at the same address were swept six more times over the next three and a half hours.

Two details matter here. “Fifty sequential signatures” means sustained access to the signing path, well beyond one phished approval. And Teng has said the delegation bypassed Binance's usual approval process; the signer produced something its own policy layer never reviewed.

The technique itself wasn't new. A month after Pectra shipped, Wintermute found that more than 80% of EIP-7702 delegations pointed at copy-pasted sweeper contracts that drain wallets with leaked keys. A December 2025 arXiv paper on EIP-7702 phishing showed that one malicious authorization can hand an attacker persistent control of an account. The Binance attacker ran the same playbook at exchange scale, with Binance's own signer doing the signing.

Security researcher Taylor Monahan made the key point back in 2025, when those sweeper delegations first spread:

"It's not actually a 7702 issue."

Taylor Monahan, speaking to The Block about wallets drained through EIP-7702 (June 2025)

The feature only does what a valid signature tells it to. The weak point is whoever controls the sign