Binance Hack: $6.3 Billion Gone, No Key Stolen. Is Your Money Safe?

The Binance hack on 29 October 2026 took about $6.3 to $6.4 billion from hot wallets on up to 11 blockchains, the largest crypto theft on record. Binance has found no evidence of a private key leak: a compromised DevOps engineer's laptop led to a service container that got Binance's own systems to sign withdrawals. Binance says it will cover every loss.

Is your money safe? Binance says yes, and has put aside over $6.34 billion of its own money to cover the gap. That's a promise, not yet a proof: as of 30 October 2026, withdrawals are still paused and no updated proof of reserves has been published. What to do while you wait.

All figures here are preliminary and current as of Binance's update at 14:34 UTC on 30 October.

Here's what most coverage skips. The vault wasn't cracked, and nobody seems to have walked off with the keys. The attacker got inside the machinery that uses the keys and had it approve the withdrawals itself.

Put simply, the signer is the vault. Anyone who can tell it what to sign doesn't need the key.

Bybit's $1.46 billion loss in February 2025 followed a similar path, starting with a compromised developer machine. And of everything taken, only coins with a company behind them could be frozen: 44% of the total. The rest is out of reach for now.

What happened in the Binance hack?

On the evening of 29 October, Binance hot wallets on chain after chain began sending funds to attacker addresses. Within about half an hour, Elliptic says, wallets had been drained on Bitcoin, Ethereum, Tron, Solana, the XRP Ledger, Arbitrum, Avalanche, Base, Optimism and NEAR. It is by far the biggest of this month's cyber attacks.

The timeline, hour by hour

Times are UTC, on 29 October unless marked, from Elliptic, Chainalysis, Hackread and Cointelegraph.

• 28 to 29 Oct: the attacker's wallet is funded with three 0.1 ETH withdrawals from Tornado Cash. TRM Labs says preparation began at least 36 hours earlier.
• 15:59: a "sweeper" contract is deployed and tested on another wallet, about four hours before use.
• 20:05: five Binance XRP Ledger wallets send 233 million XRP to one attacker address.
• 20:20: a single Ethereum transaction carries 50 signed EIP-7702 authorisations for the hot wallet known as "Binance 14".
• About 20:23: Binance 14 is emptied: 167,464 ETH plus 63 other tokens, 1.6 billion USDT among them. At 20:24, $2.53 billion leaves in one transaction.
• About 21:01: Tether freezes the attacker's main Ethereum wallet (1.18 billion USDT). Circle freezes 823 million USDC three minutes later.
• After 23:00: a second wave hits Avalanche and Polygon. At 23:56, the fourth and last sweep of new deposits leaves Binance 14.
• 30 Oct, 02:25: Binance blames a compromised DevOps engineer's laptop and says it has no evidence of a private key leak.
• 30 Oct, 08:37: Binance reports "additional points of breach" and targets 45 hours for withdrawals.
• 30 Oct, 14:34: Binance's Richard Teng says withdrawals should return within about 40 hours, by Sunday 1 November, with a full proof of reserves by Monday 2 November.

How much was stolen in the Binance hack?

About $6.3 to $6.4 billion, depending on who is counting and at what prices.

That's roughly four times the Bybit theft. Elliptic calls it "almost certainly the single largest known theft of any kind", not only in crypto. For scale, CoinDesk, citing DefiLlama, puts Binance's pre-hack holdings at about $144 billion, so the loss is around 4% of what it held.

How did Binance get hacked?

The next three sections are technical. If you only want to know about your funds, skip to is my money safe.

From an engineer's laptop to withdrawal transactions

Binance's first account was that a compromised DevOps engineer's laptop "may have allowed an attacker to gain access to a service container and submit unauthorized withdrawal transactions".

It later said it had "uncovered additional points of breach" in "a complex attack", without saying what they were. Teng added that the attacker "did not simply use one engineer's permissions", that this was not a single "one-click" action, and that Binance hasn't blamed any individual.

So the confirmed picture is short: a laptop, a container, and withdrawals that Binance's systems accepted. The detail waits on the promised post-mortem.

Why "no private key was stolen" matters more than it sounds

When a key is stolen, you rotate it. Here, the keys may never have left Binance: Binance says it has found no evidence of a key leak, and Elliptic says Binance's own systems appear to have signed the transactions.

TRM Labs notes that valid signatures came from wallets on different chains, with different key types, within about 30 minutes. In its view, that points to "a compromise of Binance's hot wallet signing infrastructure", not an Ethereum flaw. Blockaid calls it "key misuse".

What is EIP-7702, and how was it used against Binance 14?

EIP-7702, "Set Code for EOAs", has been live on Ethereum since the Pectra upgrade on 7 May 2025. It lets an ordinary wallet sign an authorisation that points it at a smart contract. Anyone can submit that signed authorisation on chain, and from then on, calls to the wallet run the contract's code.

That power is the risk. The specification warns that delegated code "has unrestricted access to the account and must always be closely audited by the wallet". A delegation stays in place even if the transaction that set it fails, and is only cleared when the wallet signs a new authorisation. One signed with chain ID 0 is valid on every chain.

According to Elliptic and Decrypt, the 20:20 transaction held 50 authorisations, all signed with Binance 14's key, each with a different nonce so one would match. Binance 14 was delegated to the attacker's sweeper contract, and because the delegation persisted, new deposits were swept out four times that night.

Teng's most telling line: the EIP-7702 delegation "did not pass through our normal approval controls". One signing path sat outside the guard rails.

Is this the same as the Bybit hack?

Closely, in method. Elliptic makes the comparison itself. Bybit's February 2025 loss traced back to a compromised developer machine at Safe{Wallet}, its wallet supplier, and Bybit's signers then approved a manipulated transaction. At Binance, the attacker appears to have got Binance's systems to sign directly. Both times, a developer's computer was the way in, and the theft went out with valid signatures.

What differs so far is attribution. The FBI named North Korea for Bybit within five days; there's no equivalent statement for Binance yet, as Elliptic points out.

Who hacked Binance? Was it North Korea?

Probably, say the analytics firms, but no government has confirmed it.

• TRM Labs attributes it to TraderTraitor, a North Korean group, with "high confidence".
• Chainalysis attributes it to TraderTraitor. Its CEO, Jonathan Levin, said it was "likely done by DPRK group TraderTraitor due to links to previous hack".
• The link: after passing through THORChain, some Binance funds were mixed at one address with proceeds of the September 2026 Bitget theft, as traced by ZachXBT and the analytics firms.
• Elliptic thinks North Korea-linked actors are likely responsible, but adds a caveat: "The overlap is small."

Why could only 44% of the stolen crypto be frozen?

Because only some tokens have someone holding a freeze button. Stablecoin issuers can block their tokens at an address. Nobody can do that for native coins like bitcoin, or for ether on Ethereum itself. Freezing also isn't recovery: frozen funds are blocked, not yet returned.

What could be frozen, and what couldn't

Elliptic counts $2.84 billion frozen: 44% of the theft, 94% of it stablecoins. Binance says about $3 billion. On the Bitcoin, Solana, NEAR and XRP Ledger networks, nothing was frozen.

The attacker seemed to expect the freezes. Before the freezes, about $786 million of stablecoins was swapped into ETH and TRX, one batch at an implied loss of 12% to 26%, by Elliptic's estimate.

Elliptic estimates about $3.28 billion now sits beyond reach in around 72 addresses, including 519,104 ETH and 18,270 BTC.

Is my money safe on Binance?

What Binance has promised, and what isn't verified yet

The honest answer: Binance says it has the money to cover this, and has said so publicly and repeatedly. What hasn't happened yet is the independent check.

"Binance will cover all losses," the exchange said. Teng put it more bluntly: "Bottom line - your money is safe, and we're covering every loss."

• Funds set aside: over $6.34 billion of company money, about $5 billion of it already in the same tokens, the rest bought on the market and over the counter.
• Withdrawals: still suspended as of 30 October 2026, with a target of "within 40 hours", by Sunday 1 November. Deposits were back to normal on 30 October.
• Proof of reserves: an initial update first, then a full report "by Monday" (2 November), plus a post-mortem.
• SAFU fund: Binance's 2018 emergency fund holds roughly $1 billion in bitcoin, per CoinDesk: a fraction of this loss. The payout rests on the $6.34 billion of company funds, not on SAFU alone.

Confirmed: the losses, the freezes and Binance's commitments. Not yet verified: that reserves fully match customer balances after the payout. For context, CoinDesk found Binance 14 was listed in Binance's 1 October proof of reserves, and estimates the ether taken at about 5.6% of Binance's ETH reserves.

What to do as a user

• There's no need to rush. Withdrawals are paused for everyone, so nobody is getting out ahead of you.
• Watch for two things: withdrawals reopening (targeted by Sunday 1 November) and the proof of reserves (promised by Monday 2 November).
• Ignore "refund" or "recovery" messages. Scammers follow every big hack.
• Only use the official app or site, typed in or bookmarked, never a link from a message.
• Turn on phishing-resistant sign-in. Our guide to passkey authentication explains why.

What engineering teams should change now

Any team running a signing service, hot wallet or privileged pipeline has the same shape of risk.

• Treat the signer, not the key, as the crown jewel. An attacker who can call your signer doesn't need the key.
• Route every path that produces a signature through one policy engine. Transfers, approvals, ownership calls and delegations such as EIP-7702 all count. No side doors, and the signer should only sign payloads it can decode, never a raw hash.
• Keep developer laptops away from production signing. No direct route to signing services or their containers; just-in-time, audited access only.
• Isolate privileged CI and deploy pipelines from signing. Laptops and build tools fall in mundane ways: see the ClickFix fake CAPTCHA attack and npm supply chain attacks.
• Set velocity caps and multi-chain anomaly alerts. Many chains and key types signing within minutes should trigger an automatic halt.
• Lock down EIP-7702 on hot wallets. If a wallet doesn't need delegation, its signer should refuse to sign authorisations at all, and never with chain ID 0, which a December 2025 arXiv study also warns against. Alert the moment any of your addresses gains code (the 0xef0100 delegation marker).
• Watch for rehearsals. A new contract touching your wallets hours before anything else happens deserves an alert.
• Put issuer and security council contacts in your incident runbook. Freezes landed within about an hour and stopped 44% of the theft from moving.
• Review wallet and signing integrations before launch. It's part of our Web3 integration and cybersecurity hardening work.

The lesson in one line: protect what your signer will sign, not just the key it signs with. Any route that skips your approval controls is your Binance 14.

Frequently asked questions

Not sure whether your signing or deploy path has a side door? This week, list every route that can produce a signature, including the ones added for convenience. If you'd like a second pair of eyes, book a free consultation and we'll tell you plainly what to fix first.

Sources

• Chainalysis, Binance exploit: latest findings and response (30 October 2026)
• Elliptic, Binance: the largest hack in history (last updated 30 October 2026, 13:10 UTC)
• Decrypt, What is EIP-7702, the Ethereum upgrade behind the $6.4B Binance hack
• Decrypt, Binance finds additional points of breach in $6.3B hack (30 October 2026)
• Hackread, Binance DevOps engineer's hacked laptop and the billion-dollar theft
• Help Net Security, Binance crypto hack (30 October 2026)
• CoinDesk, Binance hack drained wallets backing customer assets, reserve data shows (30 October 2026)
• CoinDesk, Potential multi-billion Binance hack hitting crypto markets (29 October 2026)
• Cointelegraph via TradingView, Live updates: Binance says $6.34B set aside to cover hack losses
• Ethereum Improvement Proposals, EIP-7702: Set Code for EOAs
• arXiv 2512.12174, study of EIP-7702 delegation abuse (December 2025)