Updated October 31, 2026. This is still developing: Binance hasn’t published its post-mortem yet, so some of what follows is reconstruction from on-chain data and early analysis. Where something is confirmed, assessed or still unknown, I say so.
On the evening of Thursday, October 29, 2026, an attacker took about $6.3 billion in crypto out of Binance hot wallets on ten blockchains in roughly twenty minutes. That’s Binance’s own estimate. TRM Labs, valuing each asset at the moment it was taken, puts it at $6.36 billion. Either way it is the largest crypto theft on record, about four times the $1.5 billion taken from Bybit in February 2025.
Binance suspended withdrawals and said customer balances are safe. It has promised to cover every dollar from its SAFU emergency fund and company money. Bitcoin dropped below $80,000 on the news. Within hours, Tether, Circle, Ripple and others froze roughly $2.7–3 billion of the stolen funds on-chain.
Crypto Twitter has spent two days pulling apart the on-chain trail. The most interesting part is a trick on Ethereum: a single transaction carrying fifty pre-signed authorizations, of which only one had to work. This piece walks through the whole thing in plain terms: what happened, how the Ethereum part worked, what it says about how Binance was breached, how the money is being moved, and what we still don’t know.
The short version
- The way in (per Binance, preliminary): a DevOps engineer’s laptop was compromised. That gave the attacker access to a service container (part of Binance’s backend infrastructure) from which unauthorized withdrawal transactions were submitted. Binance has since said it found additional points of breach and that this was not a one-click job. It has not said what they are.
- The keys: Binance’s CEO Richard Teng says they have found no evidence of any wallet private key leak. Yet Blockaid counted eleven Binance hot-wallet keys signing transfers to attacker addresses. The likeliest way both are true, and the working theory of Blockaid and TRM Labs, is that the attacker didn’t steal keys. They got Binance’s signing system to sign whatever they asked for.
- The Ethereum trick: using EIP-7702, an Ethereum feature live since the Pectra upgrade in May 2025, the attacker got Binance’s best-known Ethereum hot wallet (“Binance 14”) to hand control of itself to an attacker-written “sweeper” contract. The contract then emptied the wallet in one transaction worth about $2.5 billion, and kept re-sweeping new money that arrived for hours.
- Everywhere else: on Bitcoin, Tron, XRP Ledger, Solana and the rest there was no clever contract trick. Hot wallets just signed ordinary transfers to the attacker.
- Who: TRM Labs says with high confidence it was TraderTraitor, North Korea’s top crypto-theft unit and the group the FBI named for the Bybit hack. Chainalysis says “likely.” Binance hasn’t confirmed an attacker.
Timeline (October 29, UTC)
Times come from TRM Labs’ and Blockaid’s on-chain reconstructions.
| Time (UTC) | What happened |
|---|---|
| Oct 28, morning | An “operator” wallet receives the first of three small withdrawals from Tornado Cash, the Ethereum mixer. Preparation starts at least 36 hours before the theft. |
| Oct 29, early | The operator deploys a first version of its code and tests it on two wallets it controls, moving a few dollars each time. |
| 15:59 | The final sweeper contract is deployed on Ethereum. |
| later Oct 29 | Full dress rehearsal on a third attacker wallet. Test funds are routed back to the operator. |
| 20:05–20:09 | Five Binance XRP Ledger wallets send 233.46 million XRP to one attacker address, each left with only the minimum reserve. |
| ~20:10 | Binance wallets on Solana and Optimism start sending funds out. |
| 20:20:59 | The key moment. The operator submits one Ethereum transaction to Binance 14 carrying 50 EIP-7702 authorizations. One of them is valid. Binance 14 now runs the attacker’s code. |
| 20:20 | A Binance Bitcoin hot wallet sends 18,270 BTC to the attacker, split right away into round 1,000 BTC and 100 BTC chunks. |
| ~20:22 | A Binance Tron hot wallet sends 612.7 million USDT and 46.4 million TRX. |
| 20:24:23 | The big sweep. 3 minutes 24 seconds after the delegation, Binance 14 is emptied: 167,464 ETH, 1.615 billion USDT and about 60 other tokens, roughly $2.5 billion in one transaction. |
| 20:24:47 | 24 seconds later, a second Ethereum hot wallet (“Binance 16”) sends 28,005.6 ETH, 55.7M USDT and 25.9M RLUSD. This one is an ordinary signed transfer, with no delegation. |
| ~20:25–20:36 | Arbitrum, Optimism and Avalanche hot wallets drain: 74.6M ARB and 8,426 ETH on Arbitrum, 44.2M OP on Optimism, 1.81M AVAX and 8.41M USDT on Avalanche. |
| 20:41:23 | 780 million USDC, then 43 million more, leaves a Binance smart account that Binance 14 controlled (details below). |
| 20:41 → 23:56 | Binance 14 is re-swept at least six more times as Binance’s own systems keep routing deposits into it. |
| 21:01 | Tether freezes 971.1M USDT in the main receiving wallet, 37 minutes after the sweep. |
| 21:04 | Circle freezes 823M USDC. |
| 22:01 | Ripple freezes the wallet holding stolen RLUSD (40.5M left in it). |
| 22:10 | World Liberty Financial freezes 27.8M USD1. |
| 23:05 | A second wave: Binance wallets on Avalanche and Polygon send funds out. |
| Oct 30, 00:08 | The Arbitrum Security Council forces 8,426 ETH and 74.6M ARB (~$30M) out of the attacker’s Arbitrum wallet. |
| Oct 30, ~01:20 | Binance 14’s code is empty again: the malicious delegation has been revoked. |
What was taken, chain by chain
From TRM Labs, valued at time of transfer:
| Chain | What left | Approx. value |
|---|---|---|
| Ethereum | 200,630 ETH + 185 tokens incl. 1.875B USDT, 823M USDC, 88.5M RLUSD | $3.79B |
| Bitcoin | 18,270 BTC | $1.47B |
| Tron | 612.7M USDT + 46.4M TRX | $628M |
| XRP Ledger | 233.46M XRP | $296M |
| Solana | 970,500 SOL | $96M |
| Arbitrum, Optimism, Base | incl. 74.6M ARB | $39M |
| Avalanche | $28M | |
| Polygon | $10M | |
| Total | ~$6.36B |
Ethereum was the biggest share, and it’s where the most technically interesting thing happened.
The technical core: EIP-7702 and the fifty-signature trick
First, what EIP-7702 is
Ethereum has two kinds of accounts. Externally owned accounts (EOAs) are ordinary wallets controlled by a private key; they have no code. Contract accounts are smart contracts, which have code but no key. Exchange hot wallets like Binance 14 are EOAs.
EIP-7702 arrived with the Pectra upgrade in May 2025. It lets an EOA point itself at a smart contract’s code. Once it does, anyone who calls the wallet runs that contract’s code, but as the wallet: with its balance, its tokens and its permissions. It was designed for good reasons, like batching transactions, having someone else pay gas, and “smart wallet” features without moving to a new address.
Mechanically it works like this:
- The wallet owner signs a small message called an authorization: in effect, “I, this account, delegate to contract address X, on chain Y, at nonce N.” (Technically it’s a signature over
keccak256(0x05 || rlp([chain_id, address, nonce])).) - Anyone can then submit that authorization to the network inside a special “type 4” transaction. The submitter pays the gas; the wallet owner doesn’t even need to be online.
- When the transaction is processed, the network checks each authorization. If it’s valid, the wallet’s code is set to a short pointer (
0xef0100followed by the contract address), and the wallet’s nonce goes up by one. - The delegation stays in place until the same wallet signs a new authorization, for example one pointing at the zero address to clear it.
Two details of the rules turned out to matter a lot here:
- The nonce must match exactly. Every Ethereum account has a nonce, a counter of how many transactions it has sent. An authorization is only valid if its nonce equals the wallet’s nonce at the moment the transaction is processed. One off and it’s invalid.
- Invalid authorizations are skipped, not fatal. A type 4 transaction can hold a whole list of authorizations. If one fails its checks, the network just skips it and moves on to the next. The transaction as a whole still goes through.
The problem the attacker had to solve
Binance 14 isn’t a dormant wallet. It’s one of the busiest hot wallets on Ethereum, paying out customer withdrawals all day. Its nonce was around 18.9 million and climbing every time it sent a withdrawal.
So the attacker had a timing problem. Suppose they got the wallet to sign one authorization for nonce N. By the time their transaction landed, Binance’s own withdrawal flow might already have used nonce N, and the authorization would be dead. As Blockaid put it, the attacker didn’t know Binance 14’s live nonce.
The solution: sign a window, not a number
Instead of one authorization, the attacker obtained fifty, all signed by Binance 14, all pointing at the same sweeper contract, each for a different consecutive nonce: 18,914,775 through 18,914,824.
They packed all fifty into a single type 4 transaction, sent from their own operator wallet, and broadcast it at 20:20:59 UTC (transaction 0xad9926…298b, per Blockaid).
Whatever Binance 14’s nonce was when that transaction got into a block, as long as it fell somewhere in that 50-wide window, exactly one authorization would match. The other 49 would be skipped as invalid, and the transaction would still succeed.
That’s what happened. Forty-nine failed. One matched. Binance 14 was now running the attacker’s code.
Ethlabs researcher Derek Chiang made the point that EIP-7702 itself wasn’t broken: the protocol did exactly what it’s specified to do. What it did was make the theft faster and cleaner once the attacker could get valid signatures. Without 7702 the attacker would have had to race Binance’s own withdrawal system for each individual nonce, one transaction at a time.
The sweeper contract
The delegated contract (0x63e842…6fAe, deployed at 15:59 UTC that day) is unverified, meaning its source code isn’t published. But Blockaid’s analysis of its behaviour shows two key functions:
- A sweep function that moves every listed token, plus the account’s ETH, to a chosen recipient.
- A forwarding function that lets the delegated wallet call other contracts.
Both can be called by only one address: the attacker’s operator wallet. That matters, because a delegated wallet’s code can be called by anyone. Without that check, any opportunistic bot watching the chain could have swept Binance 14 too.
At 20:24:23, the operator called sweep. In one transaction, Binance 14 sent 167,464 ETH, 1.615 billion USDT and about 60 other tokens (about $2.5 billion) to the attacker’s main collection address (0x5227…2f8c). Blockaid notes the wallet was left holding exactly 1 ETH.
The forwarding function and the $823 million USDC
The forwarding function explains one of the stranger flows. Binance 14 wasn’t only a wallet holding funds. It was also the controller of a separate Binance smart account (“Binance Hot Wallet 34”) that held a large USDC balance.
Once Binance 14 ran the attacker’s code, the attacker could make it call that smart account and tell it to send its USDC out. At 20:41:23, 780 million USDC left, then another 43 million: 823 million in total. Circle froze all of it about twenty minutes later.
This is a real lesson: compromising one EOA through delegation also compromises everything that trusts that EOA as an owner or executor.
Why it kept bleeding
Delegation lives on the address, not the key. Until Binance 14 itself signed a new authorization to clear it, any money arriving at Binance 14 could be swept by the attacker.
And money kept arriving. Big exchanges automatically gather customer deposits from thousands of deposit addresses into hot wallets like Binance 14. Coinbase’s Conor Grogan warned publicly that these automated sweeps were still running after the attack. On-chain, the attacker re-swept the wallet at 20:41, 20:59, 21:04, 21:44, 22:39 and 23:56. The 21:44 sweep alone took about 200 million USDT plus 13 other tokens that had come in since the first one.
Blockaid also made an important point for defenders: rotating keys doesn’t fix this. Moving to a new key means moving to a new address. The old address stays delegated to the attacker, and anything sent to it is gone. The only cure is a fresh authorization from the compromised wallet itself, pointing the delegation at the zero address. By about 01:20 UTC on October 30, Binance 14’s code was empty again, and Binance says it revoked the affected address authorizations.
The bigger question: how did the attacker get Binance’s signatures?
The 7702 trick is clever, but it’s the last step. Every one of those fifty authorizations had to be signed by Binance 14’s key. The other chains needed ordinary signed transfers from at least ten more wallets. That’s the real breach, and it’s the part Binance hasn’t explained yet.
What Binance has said
- The first finding: a DevOps engineer’s laptop was compromised. It gave the attacker access to a service container, from which they submitted unauthorized withdrawal transactions.
- Later: investigators found additional points of breach. Teng said the attacker didn’t simply use one engineer’s permissions, and that the attack wasn’t done by one person.
- On keys: no evidence of a private key leak so far.
- The delegation didn’t go through Binance’s normal approval controls.
- Teng said the attackers used a self-destruct mechanism that destroyed their tooling and traces.
- Binance is running a full security review of endpoints, cloud, key management and transaction signing.
What the evidence points to
Here’s the puzzle: no keys leaked, yet many keys signed. TRM Labs points out that the wallets drained across ten chains use different key types and signing schemes. Bitcoin, Ethereum and Tron use secp256k1 keys; Solana uses ed25519; XRP Ledger has its own transaction format. Yet all of them produced valid signatures for attacker transactions within about half an hour.
If the attacker had stolen individual keys, they’d need to have stolen all of them, from what are probably separate storage systems. The simpler explanation is the one TRM and Blockaid both lean towards: the attacker took over the system that decides what the keys sign. A Check Point analyst, quoted by the BBC, put it this way: they took over the system that tells the keys what to sign. Blockaid CEO Ido Ben-Natan called it key misuse rather than key theft.
The keys may well have stayed sealed inside whatever hardware or MPC system Binance uses. The attacker didn’t need them out. They needed to be able to ask for signatures and have the system say yes.
What the fifty signatures tell us
The 50-nonce window is a clue in itself. TRM notes it suggests the attacker’s access was limited in time, or that signatures had to be requested through a system rather than produced at will. An attacker holding the raw key could just sign one authorization for the exact live nonce at the last moment.
It also implies the signatures were made shortly before they were used. A window of 50 nonces on a wallet sending withdrawals non-stop only stays “live” for a limited time before the wallet’s own activity moves past it.
An analysis point for anyone running a signer
This is my own analysis, not Binance’s findings. An EIP-7702 authorization is a different kind of message from a normal transaction. It starts with its own 0x05 prefix and contains no recipient, no amount and no transfer at all, just “run this code from now on.” A hot-wallet signer that only ever needs to sign withdrawals has no reason to sign one, let alone fifty in a row for future nonces.
A signing service that decodes and checks what it’s signing, and refuses anything that isn’t an expected withdrawal type, would have refused these messages. One that just signs whatever bytes it’s handed wouldn’t notice anything odd. Whether Binance’s signer behaved like the second, or whether the attacker reached a layer below its policy checks, is exactly what the post-mortem needs to answer.
About that “self-destruct”
Teng’s “self-destruct” comment caused some confusion online. Since Ethereum’s Dencun upgrade (March 2024, EIP-6780), the SELFDESTRUCT opcode can no longer delete a contract’s code unless the contract is destroyed in the same transaction that created it. The sweeper contract was deployed at 15:59 and used hours later, so it couldn’t have wiped itself from the chain that way. Decrypt’s wording, that the attackers destroyed tooling and traces along the way, suggests Teng meant the attacker’s off-chain footprint inside Binance’s systems (malware, scripts, logs), not the on-chain contract.
The getaway: how the money is moving
Once a theft this large is public, the attacker’s enemy is the freeze. Stablecoins like USDT, USDC and RLUSD are issued by companies that can blacklist an address. ETH and BTC can’t be frozen that way. So the first hours were a race to turn freezable assets into unfreezable ones.
Overpaying for speed on UniswapX. On Ethereum, about 325 million USDT was sold through UniswapX and other “intent-based” trading systems, where professional market makers fill large orders. The attacker got about 122,300 ETH. That works out to about $2,650 per ETH at a time ETH traded around $2,300–2,350, more than 10% worse than market. That’s what panic looks like on-chain: paying a big premium to get out of USDT before Tether’s blacklist arrived. The remaining 175 million USDT from that batch was frozen anyway.
Using Aave as an exit. A second attacker wallet deposited 60 million USDT into the lending protocol Aave and borrowed about 19,760 ETH against it, within minutes. The attacker walks away with ETH. Aave is left holding USDT collateral that Tether then froze. Aave froze the affected markets in response and unfroze them on October 30.
Tron and JustLend. On Tron, 300 million USDT moved to a wallet that deposited into JustLend (Tron’s lending protocol). Another 200 million went through hop wallets and was swapped. About 30 million was frozen.
Bitcoin peel chain. The 18,270 BTC was split straight away into round 1,000 and 100 BTC pieces, a classic setup for gradually “peeling” funds off through many addresses. Investigators are watching every output.
XRP sitting still. The 233.46 million XRP has, so far, not moved.
THORChain (single-source claim). On-chain investigator ZachXBT reported that funds from this hack and from a separate $388 million Bitget exploit ended up at the same address after passing through THORChain, the cross-chain swap protocol. Only one source reports this; treat it as unconfirmed until others verify it.
TRM notes that the laundering so far, with big swaps through market makers and lending protocols, differs from the bridge-heavy pattern seen after Bybit. It expects bridges, swap services and OTC brokers to follow. As of October 30, the funds had not been cashed out to fiat, and with past North Korean thefts that has taken weeks to years.
By TRM’s count the attacker still holds more than 420,000 ETH and 18,270 BTC, about $2.4 billion.
The freezes
| Who | What | Notes |
|---|---|---|
| Tether | ~1.77B USDT | 971.1M frozen at 21:01. Later sweeps landed in the already-frozen wallet, which now holds 1.175B. More on Tron, Avalanche and Polygon. |
| Circle | ~825M USDC | 823M at 21:04 + 1.56M later |
| Ripple | 40.5M RLUSD | Binance co-CEO Yi He said Ripple helped stop ~$200M; TRM confirmed 40.5M on-chain |
| World Liberty Financial | 27.8M USD1 | |
| Arbitrum Security Council | 8,426 ETH + 74.6M ARB (~$30M) | A forced transfer out of the attacker’s wallet |
That’s about $2.7 billion by TRM’s count, or about $3 billion by Binance’s (counted at a later time).
The Arbitrum move is worth noticing. The Security Council used its emergency powers to take funds out of an address on a network many people think of as decentralized. In this case almost everyone will cheer, but it’s a power that exists, and it was used.
Who did it
TRM Labs attributes the hack to TraderTraitor “with high confidence,” citing on- and off-chain intelligence it hasn’t published. The public pattern matches TraderTraitor’s playbook from Bybit and from TRM’s comparison to the April 2026 KelpDAO hack:
- An operator wallet funded with small Tornado Cash withdrawals.
- Staging well ahead of the theft, with test runs on throwaway wallets.
- Signatures obtained in advance, then used in one fast burst.
- A way in through a developer’s or engineer’s machine.
That last point is the strongest link to Bybit. There, according to Safe’s investigation, a Safe developer’s laptop was compromised on February 4, 2025. A stolen AWS session token let the attackers plant malicious code on February 17, and the theft happened on February 21. North Korean groups are known for targeting engineers with fake job interviews, poisoned coding tests and malicious software packages. Nobody has said yet how the Binance engineer’s laptop was compromised.
Chainalysis calls the North Korea link “likely.” Blockaid’s CEO said it remains unconfirmed. Binance hasn’t named anyone. The US Secret Service says it is tracking the funds.
Binance’s response
- Withdrawals suspended across networks. Binance says deposits were not affected.
- Full reimbursement promised from the SAFU fund and company funds. Binance says it has set aside more than $6.34 billion, including about $5 billion already held in the exact tokens taken (USDT, USDC, BTC, ETH, BNB and others). It is buying the rest on exchanges and OTC.
- Customer funds: Teng says the attack hit Binance’s own hot wallets and that customer funds were never used. One nuance: CoinDesk found the compromised wallets had previously appeared in Binance’s reserve data as backing customer balances. That doesn’t mean customers lose anything, since Binance says it is covering everything, but “customer funds weren’t touched” is more of an accounting statement than a technical one.
- Restart: a phased reopening of withdrawals aimed for Sunday, November 1, after security checks.
- Proof of reserves: an initial snapshot first, then a full report around Monday, November 2.
- Post-mortem: promised, not yet published.
What we still don’t know
- How the laptop was compromised, and what the “additional points of breach” were.
- How the signing system was reached: through the service container, through cloud credentials, or a layer deeper.
- Why a hot-wallet signer signed fifty EIP-7702 authorizations for future nonces, and why that didn’t trip any policy or rate limit.
- When exactly withdrawals were paused, given that Binance 14 was re-swept until almost midnight.
- What “self-destruct” refers to.
- Attribution: TRM’s call is strong but rests on intelligence it hasn’t published.
Takeaways
For exchanges and anyone holding hot wallets:
- Your signer is the crown jewel, not just your keys. Locking keys in hardware or MPC protects them from being copied. It doesn’t stop them from being used by someone who controls what gets sent to them.
- Decode what you sign. Allow only the message types a wallet actually needs. A withdrawal wallet should never sign an EIP-7702 authorization unless someone deliberately approves it through a separate channel.
- Watch for code on your EOAs. A hot wallet suddenly having code (
0xef0100…) should be a page-everyone, stop-all-flows alert. - Have a plan to un-delegate. Rotating keys doesn’t clear a 7702 delegation. You need a pre-planned, tested way to sign a reset to the zero address, and to stop automatic deposit sweeps into a compromised address at once.
- Map who trusts whom. Binance 14 controlled a smart account holding $823 million in USDC. A compromised owner takes everything it owns down with it.
- Engineers’ laptops are part of your perimeter. Both of the two biggest crypto thefts ever reportedly started on an engineer’s machine.
For regular crypto users:
- The same EIP-7702 feature is used in wallet-drainer phishing against individuals. If a site asks you to sign something that “upgrades” or “delegates” your wallet, stop. Many wallets now show delegation status, and there are tools to check and revoke a delegation.
- Exchange custody risk is real even at the biggest venue. Binance can absorb a $6.3 billion hit; most exchanges couldn’t. That’s the oldest argument for holding your own keys, and this week made it again.
Sources
- TRM Labs: North Korea Steals USD 6.36 Billion From Binance in the Largest Hack in History
- Blockaid: on-chain analysis of the Binance hack
- Cointelegraph: Binance Hack May Involve Key Misuse, Not Theft: Blockaid
- CoinDesk: Binance discovers multiple breach points in $6.3 billion attack, eyes Sunday reopening
- Decrypt: Binance Sets Aside $6.34B to Cover Hack Losses
- Gizmodo: How Hackers Stole $6.3 Billion From Binance in Minutes
- CryptoTicker: Binance Hack On-Chain Analysis
- FinanceFeeds: Binance Hack: 11 Keys Signed, No Leak Says Teng
- Aikido Security: Binance hack: how a developer laptop can put $6.3B in play
- CNBC: $6.3 billion Binance hack is largest crypto theft on record
- Ethereum: EIP-7702 specification · EIP-6780 (SELFDESTRUCT change)