A laptop, a container and one signature: the $6.3B Binance drain, in three numbers

On 29 October 2026, starting at 20:05 UTC, Binance wallets on ten blockchains sent their balances to addresses controlled by a single attacker. Most of it left in about twenty minutes. It is the largest crypto theft on record, roughly four times the $1.5 billion Bybit hack of February 2025.

No smart contract was exploited. Every outflow carried a valid Binance signature. That is the part worth understanding, because it applies far beyond one exchange.

Three numbers, and why they don't add up neatly

About $6.3 billion taken. That is Binance's own estimate of the total impact (Security Incident Update, 30 Oct). TRM Labs, valuing each transfer at the price of the moment, counts $6.36 billion across ten chains.

About $3 billion frozen. Stablecoins have issuers, and issuers can freeze. Binance puts the frozen total at about $3 billion. TRM's on-chain count at 00:30 UTC on 30 October was about $2.7 billion: roughly 1.77 billion USDT frozen by Tether, 825 million USDC by Circle, 40.5 million RLUSD by Ripple, 27.8 million USD1 by World Liberty Financial, and about $30 million in ETH and ARB moved out of the attacker's reach by Arbitrum's Security Council. That leaves a little over $3 billion that the freezes did not stop.

About $2.4 billion beyond anyone's reach. Bitcoin and ether have no issuer. Racing the freezes, the attacker sold about 325 million USDT for ether at a discount of more than 10% and borrowed ether against USDT on a lending protocol. TRM's count: more than 420,000 ETH and 18,270 BTC, about $2.4 billion, that no freeze can touch.

The figures come from different sources, at different hours, with different price references, and the attacker lost value on every hurried conversion. They will not add up to the dollar, and anyone who tells you they do is rounding.

There is a fourth number, and it is the one customers care about. Binance says it will absorb the loss with its emergency fund (SAFU), part of its futures insurance fund and its own treasury. On 31 October it reported 90% of the stolen assets replenished; on 2 November, 95%. The remainder is less liquid tokens that take longer to buy. "Replenished" is not "recovered": the exchange paid with its own money, and the stolen coins are still where the attacker put them.

How it happened

Binance's initial investigation says the incident "may involve a compromised DevOps engineer's laptop, which allowed an attacker to gain access to a service container and submit unauthorized withdrawal transactions." It found no evidence that a wallet private key leaked. A full post-mortem is still to come.

That fits what the chain shows. Wallets on ten chains, with different key types and signing schemes, all produced valid signatures for the attacker within about half an hour. One leaked key does not do that. Access to the system that asks for signatures does.

On Ethereum, the attacker added a step. It used EIP-7702, a feature introduced with Ethereum's Pectra upgrade in May 2025.

EIP-7702 in two paragraphs

An ordinary Ethereum address (an "externally owned account") has no code; it just signs. EIP-7702 lets that address sign an authorization that points it at a smart contract. From then on, any call to the address runs that contract's code, with the address's full balance and permissions. The arrangement stays until the address signs a new authorization.

That is useful: it is how wallets add batching, spending limits or gas sponsorship without moving funds. It also means that one signature can hand an address to someone else, permanently, until it is revoked.

The Ethereum takeover, minute by minute

The preparation was visible days ahead. The attacker's operator wallet was funded through Tornado Cash about 36 hours before. On 29 October it deployed a "sweeper" contract, tested it on throwaway wallets, rehearsed, and deployed the final version at 15:59 UTC. That contract accepts instructions only from the attacker, and can move every token out of whatever address runs it.

At 20:20:59 UTC, one transaction carried 50 authorizations, each signed by Binance's main Ethereum hot wallet (the address labelled "Binance 14"), each pointing it at the sweeper. Why 50? An authorization is valid only at the wallet's current transaction count (its nonce), and a busy exchange wallet's count moves every few seconds. Signing 50 consecutive counts in advance guaranteed one would match. One did.

Three minutes and 24 seconds later, a single call moved 167,464 ETH and 63 tokens, including about 1.6 billion USDT.

Two details make this attack instructive rather than merely large:

• The delegation stayed in place. Customer deposits kept arriving, and the attacker swept the wallet four more times, until Binance revoked the delegation at 00:10 UTC on 30 October. As Hypernative notes, the delegation belongs to the address, not to the key: rotating the key would not have removed it.
• The delegation inherited everything the wallet owned. The hot wallet was the sole owner of a separate smart account holding USDC. Once the attacker controlled the wallet, it controlled that account too, and pulled about $823 million USDC out of it. Circle froze it shortly afterwards.

"But what if the laptop story is wrong?"

It might be incomplete. Binance's own wording is "may involve", and the post-mortem is not out yet. It does not matter much for the lesson. Every element of this scenario is ordinary:

• a workstation belonging to someone with production access;
• a service that can request signatures without a human looking at each one;
• a signature format, EIP-7702, that hands over an address in one step;
• no automatic limit on how much can leave, or to where.

Each of these exists in thousands of companies and teams far smaller than Binance. Whether this particular chain of events is confirmed or revised, the chain itself is possible, and that is reason enough to check your own.

What you can check tonight

If your team signs from a hot wallet or a treasury wallet

1. Look for code at your addresses. An address that should be a plain wallet should have no code. With Foundry installed: cast code <address> — rpc-url <your RPC>. An empty answer (0x) is normal. An answer starting with 0xef0100 means the address is delegated, and the 20 bytes that follow are the contract it now runs. Put that check on an alert, not on a to-do list.
2. Refuse EIP-7702 authorizations by policy unless you expect one. A request for many authorizations across a range of nonces is not a configuration quirk; TRM calls it an indicator of compromise.
3. Know how to revoke before you need to. An authorization that points to the zero address clears a delegation. Prepare it, test it on a test network, and know who signs it at 3 a.m.
4. List what your hot wallet owns. Smart accounts, admin roles, allowances: a delegation inherits all of them.
5. Put limits on outflows. A transfer of an entire balance to an address that did not exist yesterday should be stopped automatically, not reviewed the next morning. That is what circuit breakers, withdrawal velocity limits and pause roles on contracts are for.
6. Separate signing paths by chain and by wallet tier, so one compromise cannot reach ten chains in half an hour.

If you run any company where someone's laptop can reach production

The laptop is the front door. The usual controls exist and are not exotic: endpoint detection and response on every admin machine (commercial suites such as Microsoft Defender for Endpoint, CrowdStrike Falcon or SentinelOne, or open-source monitoring such as Wazuh and osquery); hardware security keys (FIDO2) instead of codes that can be phished; a dedicated machine for administrative access, kept separate from email and browsing; and short-lived, just-in-time access to production rather than standing credentials, as tools like Teleport or HashiCorp Boundary provide.

If you simply hold crypto in your own wallet

EIP-7702 applies to you too. A phishing page no longer needs your seed phrase; it can ask you to sign an "account upgrade". Read every signature request, and be wary of anything that mentions delegation, smart account upgrades or authorizations you did not start. An authorization signed with chain ID 0 is valid on every EVM chain at once. You can check whether your own address is delegated with a block explorer or the cast code command above.

The lesson

Binance survived this because it could pay $6 billion out of its own pocket and because stablecoin issuers froze about half of it within an hour. Almost nobody else can count on either. For everyone else, the protections that matter are the boring ones: knowing when your own addresses change, limiting what can leave and how fast, and treating the laptop of anyone with signing access as part of the vault.

— -

I build Sentinelleai, which watches the servers you enroll for signs of compromise and can pause a contract you own when an attack starts.

Sources: Binance Security Incident Update (30 Oct) and Recovery Updates #3 (31 Oct) and #5 (2 Nov); TRM Labs (29 Oct, figures as of 30 Oct 00:30 UTC); Hypernative (30 Oct); EIP-7702 specification (eips.ethereum.org/EIPS/eip-7702). Figures may change as investigations continue.