How the $6.3 billion Binance hack happened: a laptop, a signing system and one Ethereum feature

On the evening of Thursday 29 October 2026, Binance's hot wallets started emptying. Over the next few hours roughly $6.3 billion left the exchange across ten blockchains, most of it in about twenty minutes. That is more than four times the $1.46 billion taken from Bybit in February 2025, which was itself the previous record, and Elliptic's chief scientist called it almost certainly the largest known theft of any kind.

Binance has not published a root cause yet, so parts of this will change. But between Binance's own statements and the on-chain analysis from TRM Labs and Elliptic, the shape of the attack is already clear, and it is worth understanding because almost none of it is specific to crypto.

drained from hot walletsTRM puts it at $6.36bn at transfer-time prices

$6.3bn

blockchains hitElliptic counts eleven

10

for most of the outflowon the evening of 29 October, UTC

~20 min

frozen so faralmost all of it stablecoins

~$3bn

Step 1: getting inside

Binance's first explanation was a compromised laptop belonging to one of its DevOps engineers. From there, it said, the attacker reached a service container and was able to submit unauthorised withdrawal transactions. How the laptop was compromised has not been disclosed.

A day later, co-CEO Richard Teng widened that picture. The investigation had found additional points of breach beyond the laptop, the attack was not a single one-click mistake, and it did not rely on one engineer's permissions alone. Binance also says it has found no evidence that any wallet's private keys leaked.

That last point is the important one. The attacker did not need the keys. TRM Labs' assessment is that they gained the ability to make Binance's hot wallet signing system sign transactions of their choosing, across every chain it served. If the machine that holds the keys will sign whatever you hand it, you have everything the keys would have given you, without ever touching them.

Step 2: rehearsing

This was not improvised. According to TRM, the attacker's main wallet was funded with three small withdrawals from the Tornado Cash mixer starting on 28 October, at least 36 hours before the theft. On the 29th they deployed their attack code, tested it on two wallets of their own, rehearsed the final version on a third, and routed the test funds back to themselves. About four hours later, the same code went live against Binance.

Step 3: the EIP-7702 sweep

The Ethereum side, about $3.8 billion of the total, is where the method gets interesting. It used EIP-7702, a feature added to Ethereum in the Pectra upgrade of May 2025. It lets an ordinary wallet sign an authorisation that makes it run a smart contract's code, as if the wallet had become that contract. It was designed for useful things like batching payments. It also lets someone point a wallet at a contract that does nothing except send everything to them, which security people call a sweeper.

The batch of fifty pre-signed authorisations is a telling detail. TRM reads it as a sign that the attacker's access to the signing system may have been limited in time, so they signed a spread of options in advance and fired them all at once. Because the delegation stayed in place, the wallet kept forwarding customer deposits to the attacker for almost four hours. The same wallet also controlled a Binance smart account, which let the attacker pull a further 823 million USDC.

Teng said the EIP-7702 delegation did not pass through Binance's normal approval controls. Security firms are split on how much that mattered. Blockaid's view is that the funds could have been stolen without it, but the feature let it happen in one sweep and may have dodged some checks. Others point out that an attacker who can already make your signer sign does not need a clever transaction type. Both are probably right.

Step 4: everything else, all at once

The other nine chains do not support EIP-7702, and they did not need it. Binance's wallets there simply sent ordinary, correctly signed transfers. From TRM's timeline: five XRP Ledger wallets sent 233 million XRP between 20:05 and 20:09 UTC, Solana and Optimism followed, a Bitcoin hot wallet sent 18,270 BTC at 20:20, a Tron wallet sent 612.7 million USDT within about two minutes, and Avalanche and Polygon were drained at 23:05. That pattern, valid signatures on ten chains within hours, is the strongest evidence that the signing system itself was under the attacker's control.

Step 5: the race to freeze and launder

Stablecoins can be frozen by the company that issues them, and the issuers moved fast. Tether froze 971 million USDT in the main receiving wallet at 21:01 UTC and about 1.77 billion in total. Circle froze 823 million USDC three minutes later. Ripple, World Liberty Financial and Arbitrum's security council froze smaller amounts. Binance now puts the total frozen at around $3 billion.

The attacker clearly expected this. They dumped some 325 million USDT for ETH at a discount of more than ten percent, posted stolen stablecoins as collateral on Aave and JustLend to borrow assets that cannot be frozen, and started splitting the Bitcoin into 1,000 and 100 BTC pieces. Elliptic notes the movements look largely automated. Roughly $2.4 to $3.2 billion in ETH, BTC and other native assets remains beyond any issuer's reach, and recovering any of it now means tracing it to an exchange that will cooperate.

Who did it

TRM Labs and Chainalysis attribute the attack with high confidence to TraderTraitor, a North Korean state-backed unit that the FBI previously blamed for the Bybit theft. The tradecraft matches: Tornado Cash funding, staging well ahead of time, and pre-signed transactions executed in one burst. Elliptic agrees it is likely but flags some differences, including that North Korean groups usually move money faster than this. No government has confirmed attribution yet.

For Binance customers, the exchange says it will cover every loss from its own funds and has set aside $6.34 billion to do so. The stolen money came from Binance's hot wallets rather than individual accounts, and analysts quoted by CNBC see no immediate solvency risk. Deposits and withdrawals were paused while the investigation runs.

The lesson for anyone who builds systems that sign things

Strip away the crypto and this is a familiar story. One person's laptop led to a service that could submit withdrawals, and that service could get the signer to sign. Each hop was trusted by the one before it. The keys were perfectly safe the whole time, which turned out not to matter at all.

• Protecting the key is not the same as protecting what it signs. The policy, meaning which amounts, which destinations, which transaction types, has to be enforced inside the signer, not in the service that calls it.
• New transaction types need new rules. A policy engine written before EIP-7702 existed had never been asked whether a hot wallet should ever delegate its code to a contract. The answer is almost certainly never, and the check is one line.
• Rate limits are a control, not a nuisance. No legitimate hot wallet operation sends its entire balance in one go. A cap per hour turns twenty minutes and $6 billion into a bad afternoon.
• An engineer's laptop should not be one hop from production money. Bybit fell to a compromised developer machine in 2025. It is the same entry point a year and a half later.

The same principle applies well outside exchanges: payment systems, admin consoles, and increasingly AI agents with tool access. Whatever can act should be checked by something it cannot talk its way past, which is the idea behind harness engineering for coding agents.

Nobody broke Binance's cryptography. They got its own system to sign, and the blockchain did exactly what it was told.

If you run anything that moves money or takes privileged actions on someone's behalf and you are not sure where its approval checks actually live, I can review the path from a developer's machine to the action and tell you which hop is weakest. Start that conversation here.