Binance Hack Explained: How $6.3B Left Ten Blockchains

On the evening of 29 October, someone emptied Binance hot wallets on ten blockchains in 31 minutes. Binance puts the damage at about $6.3 billion, and the chains agree: priced at the moment the attack began, about $6.37 billion left. That makes it the largest crypto theft on record, roughly four times the $1.5 billion Bybit hack of February 2025.

The headline number is not the most interesting part. The interesting part is that every stolen transaction carries a valid signature from Binance's own wallets. Either the attacker got Binance's signing system to sign for them, which is what Binance's account suggests, or they held usable copies of the keys. The chains record a great deal about which, and most of it leans one way.

This is a reconstruction of the attack from public on-chain data, from the attacker's rehearsal that morning to the freezes that night. Every claim links to a public block explorer, so you can check it without trusting me. It is my reading of that data: the real sequence of events may differ, and Binance's technical post-mortem will be the authoritative account.

What happened, in one minute

• When: 29 October 2026, first theft at 20:04:52 UTC, the first wave over by 20:35:53. A second wave hit at 23:04, and the last Ethereum sweep came at 23:56.
• Where: XRP Ledger, Solana, Base, Optimism, Bitcoin, Tron, Ethereum, Arbitrum, Avalanche and Polygon.
• How much: about $6.37 billion at the 20:00 UTC price, across more than 180 tokens. That matches Binance's own estimate of about $6.3 billion.
• How: two patterns. Some thefts are built exactly like Binance's normal withdrawals; others are custom-built, including 50 EIP-7702 authorizations that turned Binance's main Ethereum hot wallet into a contract the attacker controlled for 3 hours 50 minutes.
• Frozen: about $2.83 billion, verified on-chain, by Tether, Circle, Ripple, Paxos, World Liberty, Binance itself and Arbitrum. Bitcoin, ETH, XRP and SOL cannot be frozen, and that is where most of the rest sits.

What Binance has said

Binance's initial statement says a compromised laptop belonging to a DevOps engineer gave the attacker access to a service container, which then submitted unauthorized withdrawal transactions. Binance says it found no evidence that wallet private keys leaked, estimates the impact at about $6.3 billion with about $3 billion frozen, has suspended deposits and withdrawals while it reviews security, has revoked the affected address authorizations, and will cover all losses from its SAFU fund and company funds. It also says it will publish an updated Proof of Reserves once remediation is complete.

The on-chain evidence fits that account well, with some details that the post-mortem needs to explain. More on that below.

How a big exchange moves money

To understand the attack you need a rough picture of how an exchange sends crypto out.

A withdrawal is not one step. It is a pipeline: a customer request, risk checks and approval, a transaction builder for each blockchain, and finally a signing service that holds the private keys and signs transactions for trusted internal systems. The keys never leave the signer. That is the point of the design: even if an attacker gets into the company, they cannot copy the keys out.

The catch is in the word "trusted". The signer signs what trusted callers ask it to sign. If an attacker controls one of those callers, they do not need the keys. They just need to ask.

One reading, consistent with Binance's statement and with how the transactions were built on each chain. Not confirmed.

DevOps laptop

compromised

↓→

Service container

inside the trusted network

↓→

Pattern A

Withdrawal pipeline

approval, then transaction builder. XRP Ledger, Bitcoin, five EVM chains

Pattern B

Direct signing request

custom-built transaction or payload. Solana, Tron, Ethereum EIP-7702

↓→

Signing service

keys never leave

↓→

Hot wallets

ten chains

Binance says the attacker reached a service container inside that trusted network. If that is right, the chains show two ways the access was used. The diagram above is that reading; further down I set out the alternative.

The timeline (UTC, 29 to 30 October)

29 to 30 October 2026, UTC. Each dot is one transaction or action; hover for details.

TheftFreeze or interventionBinance's response

XRP Ledger

Solana

Base

Optimism

Bitcoin

Tron

Ethereum

Arbitrum

Avalanche

Polygon

20:0020:3021:0021:3022:0022:3023:0023:3000:0000:30

Shaded: the first wave, 20:04:52 to 20:35:53 (31 minutes)

Two things stand out. The attack was rehearsed the same day on the attacker's own wallets. And the Ethereum hot wallet stayed under the attacker's control for almost four hours, long enough for new deposits to arrive and be swept out again.

Two patterns in the transactions

Pattern A: built like Binance's normal withdrawals

On the XRP Ledger, the thefts used the hot wallets' own sequence numbers, slotted in between genuine customer withdrawals, with the usual expiry settings. About 10.5 minutes later, Binance's own system retried four of them, exactly as it would retry a normal withdrawal.

On Bitcoin, the 18,270.2 BTC left in eleven transactions built on Binance's own sweep template (version 1, locktime 0, change back to the hot wallet). On Base, Optimism, Arbitrum, Avalanche and Polygon, the thefts are ordinary transfers signed by the hot wallets themselves.

Pattern B: custom-built transactions, same keys

On Solana, the five thefts are plain transfers. Of the 616 transactions that wallet signed that evening, they are the only ones without the durable nonce, compute-budget settings and batching that every normal Binance withdrawal uses.

On Tron, it is the same key but a 65-second expiry and a 100 TRX fee limit, against 114 to 118 seconds and 30 TRX on the 360 routine transactions that hour.

On Ethereum, the signer produced 50 EIP-7702 authorizations. No withdrawal ever needs that kind of message. More on why that matters next.

A fingerprint across chains

One detail ties the chains together. On seven chains, the attacker's transactions consistently paid about two to 2.7 times the fee of the same wallets' routine transactions:

The attacker's fee setting divided by the same wallets' routine transactions; the gold line is 1×, routine. Fee for the XRP Ledger, fee rate for Bitcoin, priority fee for the EVM chains, fee limit for Tron. Solana used no compute-budget fee at all, so it cannot be compared.

XRP Ledger6,000 vs 3,000 drops

Bitcoin10.05 vs 5.0 sat/vB

Base0.288 vs 0.12 gwei

Optimism0.2402 vs ~0.100 gwei

Arbitrum2.42 vs 1.001 gwei

Polygon1,080 vs 450 gwei

Avalanche8 vs 3 gwei

Tron100 vs 30 TRX limit

2.00×

2.01×

2.40×

2.40×

2.42×

2.40×

2.67×

3.33×

0×1×2×3×

That consistency points to one tool, or one "urgent" setting, driving every chain at once.

The Ethereum takeover, explained

What EIP-7702 is

Since Ethereum's Pectra upgrade in May 2025, an ordinary wallet can sign an EIP-7702 authorization: a message that says "from now on, run this smart contract's code when someone calls me." It is useful. It lets a normal wallet batch transactions or have someone else pay its gas. It is also dangerous, because whoever writes that code controls the wallet for as long as the delegation stands.

The rehearsal

The attacker's own Ethereum wallet has sent exactly 23 transactions. At 02:28 it deployed a first sweeper. Between 13:51 and 14:24 it delegated two of its own wallets to it and ran test sweeps. At 15:59 it deployed the final contract, with one function that empties a list of tokens and another that makes the wallet call any contract. Between 16:20 and 16:47 it tested that contract on a third wallet. By evening it was ready.

Why 50 signatures

An EIP-7702 authorization only takes effect if its nonce (a counter that goes up by one with every transaction the wallet sends) matches the wallet's current nonce at the moment it executes. A busy exchange hot wallet sends transactions constantly, so its nonce moves every block. One signature would almost certainly be stale by the time it landed.

So the attacker brought 50 of them, covering nonces 18,914,775 to 18,914,824, in a single transaction. In block 26,300,753, Binance 14 first sent one of its own transactions (nonce ...808), and then the attacker's authorization for nonce ...809 took effect. The other 49 were simply skipped.

50 signed authorizations, nonces 18,914,775 to 18,914,824 (last three digits shown). Only the one matching the wallet's live nonce applies; the rest are skipped.

775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824

…808 Binance 14's own transaction, in the same block

…809 the attacker's authorization that took effect

Under EIP-7702, an account's code can only be changed by an authorization signed with that account's own key. So when Binance 14's code switched from empty to a pointer to the attacker's contract, that alone proves the signature came from Binance 14's key. From that moment, Binance 14 ran the attacker's code.

What the delegation allowed

The smart wallet is the detail I keep coming back to. A hot wallet owned another wallet holding 823M USDC, so taking over one gave the attacker both.

Separately, Binance 16 sent nine ordinary transfers it signed itself, all in the same second (20:24:47), with no delegation involved: 28,005.6 ETH, 55.7M USDT, 25.9M RLUSD, 84.5 WBTC, and smaller amounts of UNI, ENA, LINK, XAUt and PEPE. In total, Ethereum lost 200,630 ETH, 1.88B USDT, 823M USDC, 88.5M RLUSD and about 165 other tokens.

What was taken

Priced in USD at the 20:00 UTC hourly open on Binance's own market data:

USD at the 20:00 UTC price. Ethereum includes the 823M USDC smart wallet and 169 priced tokens; 15 obscure tokens are unpriced.

Ethereum$3.79B

Bitcoin$1.48B

Tron$628M

XRP Ledger$299M

Solana$97M

Arbitrum$32M

Avalanche$28M

Polygon$10M

Optimism$4.9M

Base$2.9M

The prices used: BTC $80,848.64, ETH $2,336.90, SOL $99.83, XRP $1.2824, TRX $0.3315, AVAX $8.854, ARB $0.1684, OP $0.1101, POL $0.09203, VIRTUAL $0.6088, and $1.00 for USDT and USDC. Other tokens use the same hourly candle against USDT; WBTC is priced as BTC, XAUt as PAXG, and stablecoins at $1.00.

About $625 million of the Ethereum figure is the long tail of tokens other than ETH, USDT and USDC. These are the 25 largest tokens taken from Binance 14 and Binance 16, summed from the token transfers:

What was frozen, and what can't be

The freezes follow one simple rule: issued tokens can be frozen, native coins cannot. A stablecoin like USDT or USDC is a contract run by its issuer, and the issuer can block an address. Bitcoin, ETH, XRP and SOL have no issuer to call.

USD at 20:00 UTC. Frozen means blacklisted by the issuer, or moved to a frozen address by chain governance, read on-chain.

Frozen (verified on-chain)Not frozen

USDT$2.50B71%

BTC$1.48B0%

USDC$823M100%

ETH (Ethereum)$469M0%

Other Ethereum tokens$373M0%

XRP$299M0%

SOL$97M0%

RLUSD$89M46%

wBETH$78M100%

XAUt (gold)$51M100%

USD1$28M100%

AVAX$20M0%

ETH (Arbitrum)$20M100%

TRX$15M0%

ARB$13M100%

PAXG (gold)$7.7M100%

OP$4.9M0%

POL$4.3M0%

VIRTUAL$2.9M0%

That is about $2.83 billion, each freeze checked on-chain. For the smaller tokens I simulated a transfer out of the attacker's address: it fails with the issuer's own error ("Account is frozen", "transfers are blocked", "account is blacklisted"). Binance's own figure is about $3 billion. About $373 million of other Ethereum tokens, such as UNI, ENA, PEPE and LINK, were not frozen.

The race against the freezes

The attacker knew the clock was running. On Tron, they swapped 234M USDT into 638M TRX through a decentralized exchange before Tether acted, and moved 66M USDT just 81 seconds before their wallet was frozen. On Avalanche, they swapped 200,000 AVAX into USDC and bridged it to Ethereum with Circle's own bridge, CCTP. Circle blacklisted the receiving address four minutes after the USDC landed.

RLUSD shows the same race. The attacker moved all 88.5M RLUSD out at 21:22:59, sold about 48M of it in under half an hour, and Ripple froze the remaining 40.54M at 22:00:59. All of that happened on Ethereum. On the XRP Ledger, the attacker's only RLUSD payment had already failed, and the issuer took no action there.

Arbitrum's intervention

Arbitrum did something more unusual. Using its upgrade powers on Ethereum, it briefly swapped out the contract that delivers messages to the chain, injected two messages as if they came from the attacker's wallet, and restored the contract. Those messages moved 74.56M ARB and 8,426 ETH to a frozen address. It worked. It is also a clear demonstration of how much power an L2's security council holds over funds on its chain.

What is still out there

• 18,270 BTC in 19 addresses, seventeen of them holding 1,000 BTC each. None of it had moved when I checked.
• 233.46M XRP at one address.
• About 970,500 SOL at one address.
• 197,460 ETH at 0x8532...43d4, with no outgoing transaction yet.

The attacker is also selling tokens that can still be frozen, as with the RLUSD above, so these balances keep changing.

Signing service abused, or keys stolen?

This is the question that matters most, and chain data alone cannot settle it. Binance says it found no evidence of a private-key leak. The chain data allows two readings:

• The signing service was abused. The attacker controlled a trusted internal component (in Binance's account, a service container reached from a DevOps laptop) and had the signing service sign withdrawals to the attacker's addresses. The keys never left their hardware.
• Keys were copied. The attacker obtained usable copies of hot-wallet keys, or the ability to sign at will, and built the transactions themselves.

Why "withdrawals" reached the attacker at all

A withdrawal is, by definition, a transfer to whatever external address the request names. Under the first reading, the attacker created requests with their own address as the destination, and the checks a customer withdrawal goes through (account balance, risk approval) did not apply on that internal path.

Here is how the evidence falls:

My reading: the XRP Ledger and Bitcoin evidence leans towards an abused signing service; Solana, Tron and Ethereum cannot tell the two apart; and nothing on-chain points only to stolen keys.

There is also a test that would settle it. If keys are out, the attacker can still sign for the drained addresses, for example by re-delegating Binance 14 or by sweeping new deposits that land in the old hot wallets. When I checked on 30 October, no such transaction existed. A future one, from those wallets to an attacker address, would prove the keys are out.

Either way, the lesson is the same. For as long as the access lasted, controlling a trusted caller of the signer was as good as holding the keys.

Testing every scenario, including an inside job

An investigator doesn't take a victim's account on trust, especially when the victim holds all the internal evidence. So it is worth testing every scenario, including the uncomfortable ones. To be clear from the start: nothing public points to Binance staging this, or to any employee being involved. On the public evidence, a hack staged by Binance is the least consistent explanation, and a well-prepared outside attacker the most consistent. Whether the attacker had help from inside stays open, because only Binance's own forensics can answer it.

Why a staged hack fits poorly

• Binance is paying it all back. It says it will cover the losses from its SAFU fund and company funds. Paying back about $6.3 billion makes a fake theft pointless, unless it was meant to hide a shortfall that already existed. That is the one version worth testing, and the test is below.
• Outsiders froze about $2.83 billion within hours. Tether, Circle, Ripple, Paxos, World Liberty and Arbitrum each acted on their own. Anyone staging a theft would avoid assets that someone else can freeze.
• Everything is public and permanent. A trail across ten blockchains that anyone can trace and analyse is the worst possible cover story.
• The thief behaves like a thief. They sold about 48M RLUSD in 27 minutes, swapped 234M USDT into TRX before Tether's freeze, moved 66M USDT 81 seconds before their wallet was frozen, and swapped 200,000 AVAX into USDC and bridged it, only for Circle to blacklist the receiving address four minutes after it landed.

What would change that view, and how to test it

My read: the evidence points to a professional, well-prepared outside operation that came in the way Binance describes. The real open question is not whether Binance faked it. It is whether the attacker had help from inside, and how long they had been in Binance's systems before 20:04. Only Binance's forensics can answer that, which is one more reason its post-mortem matters.

Questions Binance's post-mortem needs to answer

1. How could one engineer's laptop reach a container with signing rights over hot wallets on ten chains? What separated developer access from production signing?
2. Does the signer check what it signs, or will it sign any payload a trusted caller sends? Why could it produce EIP-7702 authorizations at all?
3. Which risk checks and approvals did these withdrawals pass, and which did they skip? Why didn't ten chains emptying in 31 minutes trip a circuit breaker?
4. How did the attacker still get withdrawals signed at 23:04 to 23:06, almost three hours in and during the evacuation?
5. Why did a hot wallet own a smart wallet holding 823M USDC? What other trust links exist between wallets?
6. Why did removing the Ethereum delegation take 3 hours 50 minutes, while deposits arriving in Binance 14 kept being swept out?
7. Why were billions sitting in hot wallets at once? How are hot-wallet limits set?
8. Has the compromised access been fully removed and the keys rotated? When will the updated Proof of Reserves confirm it?
9. Could any key be exported from the signing service at all? Can Binance show that the hot-wallet keys never left their hardware?
10. How long was the attacker inside Binance's systems before 20:04, and were there earlier test signing requests?

Lessons for every custodian

• The perimeter is no longer the private key. It is every system allowed to ask for a signature.
• Allow-list what a signer will sign. A withdrawal signer has no reason to sign EIP-7702 authorizations or arbitrary payloads.
• Separate developer access from production signing in practice, not just in policy.
• No hot wallet should own another wallet.
• Treat new code on a hot-wallet address as an alarm that triggers an automatic revoke within seconds.
• Halt all signing automatically when outflows hit many chains at once.

Addresses to block

For exchanges, bridges and DEX front ends:

How I checked this, and the limits

Everything here comes from read-only public chain data across the ten blockchains, plus Binance's own published market data for prices. I checked the key claims (the 50 authorizations and the revocation, the sweeps and Binance 16's transfers, every freeze, the Bitcoin split, the XRP retries, the Solana and Tron transaction settings, and the current balances) directly against public blockchain APIs and explorers on 30 October. The EIP-7702 signers were recovered from the signatures themselves (with Foundry's cast recover-authority), and the smaller freezes by simulating a transfer out of the frozen address.

The limits:

• Interpretation. The patterns and the two hypotheses are my reading of the data. They may differ from what Binance's post-mortem finds.
• Labels. "Binance" for the source wallets comes from public explorer labels plus on-chain behaviour (exchange-scale nonces, shared evacuation targets, a common contract). There is no on-chain identity registry.
• Arbitrum's actor. That the Arbitrum action came from its Security Council is inferred from the upgrade rights used.
• Attribution. This analysis does not say who the attacker is, and Binance has not named anyone.
• BNB Chain. I found no theft there, but native BNB moving to unknown addresses can't be fully ruled out.
• Timing. Balances were read on 30 October between 02:30 and 03:40 UTC. Funds are still moving, so some of these numbers will change.

This post is an analysis of public on-chain data, not financial or legal advice.

Evidence

The transactions and addresses behind every claim in this post, grouped by chain. Open a group to see them.

Sources

• Binance's initial incident statement
• Fox Business: Binance says security incident had an estimated $6.3B impact
• Axios: Binance probes what may be biggest crypto hack in history
• Binance market data used for USD prices
• The EIP-7702 takeover transaction and the revocation
• Tether's first freeze on Ethereum, Circle's and Ripple's
• Tether's freezes on Tron