On October 29, 2026, starting at 20:05 UTC, an attacker moved about $6.3 billion out of Binance hot wallets on ten blockchains (Binance, TRM Labs). Two days later the FBI attributed the theft to the North Korean group it calls TraderTraitor (FBI). It is the largest crypto theft on record, roughly four times the $1.5 billion taken from Bybit in February 2025.

This post walks through the Ethereum part of the attack transaction by transaction. Transaction details in the Ethereum sections come from our own reads of archive data through public RPC nodes, and we recovered the signer of every authorization ourselves. No bug in Ethereum or in a smart contract was involved. The Binance 14 hot wallet signed 50 EIP-7702 authorizations for the attacker, and one of them handed the wallet to attacker code for 3 hours and 49 minutes.

Status on November 1, 2026: Binance has not published its technical post mortem yet. Figures come from Binance statements, blockchain analytics firms and our own reads of Ethereum mainnet. Where they disagree, we say so.

To follow along on Etherscan, start with the delegation transaction and the drain.

Key takeaways

  • $6.3 billion left Binance hot wallets on ten chains. Between $2.7 billion and $3 billion was frozen, almost all of it stablecoins.
  • On Ethereum, one transaction carried 50 EIP-7702 authorizations signed by the Binance 14 hot wallet, each for a different nonce. Exactly one matched.
  • The wallet stayed delegated to attacker code for 3 h 49 min. Four more sweeps took the ETH and tokens that kept arriving in it.
  • Binance found no evidence of a leaked private key. The onchain pattern fits an attacker who could get Binance signing systems to sign on request, which is also how TRM Labs and Elliptic read it.
  • The fix belongs in the signer. An EIP-7702 authorization needs its own policy, separate from the one for transfers.

What was taken, chain by chain

Ethereum and Bitcoin account for about 83% of the loss. Data: TRM Labs snapshot, October 30, 00:30 UTC.
Ethereum and Bitcoin account for about 83% of the loss. Data: TRM Labs snapshot, October 30, 00:30 UTC.

Per TRM, on Ethereum the attacker took 200,630 ETH and 185 other tokens, including 1.875 billion USDT and 823 million USDC. Bitcoin lost 18,270 BTC in a single transaction. Tron lost 612.7 million USDT and 46.4 million TRX.

The trackers do not fully agree. TRM counts $6.36 billion on ten chains. Elliptic counts $6.43 billion and adds NEAR as an eleventh (Elliptic). Binance itself gives "around $6.3B".

Step 1: Preparation, 36 hours ahead

The attacker ran the Ethereum delegation and every sweep from one address, 0x7c86…5ca0. Before the attack it had sent ten transactions.

  • October 28, 07:39 UTC. The first funding arrives from the Tornado Cash 0.1 ETH pool. A second one follows at 08:53.
  • October 29, 02:28 UTC. The operator deploys a first sweeper contract.
  • 13:51 to 14:24 UTC. It delegates two throwaway wallets to that sweeper with EIP-7702 and sweeps both. Each rehearsal already used several authorizations in descending nonce order (2, 1, 0 for one of the wallets), the same trick that would hit Binance.
  • 15:59 UTC. The final sweeper goes live at 0x63e8…6fae. Its 1,674 bytes of bytecode hardcode the operator address as the only allowed caller.
  • 16:20 to 16:47 UTC. A third test wallet gets the same treatment with the final code.

Then nothing for three and a half hours. Hypernative says its monitoring flagged the Tornado Cash funding and the sweeper deployment hours before any Binance money moved (Hypernative).

Step 2: Fifty signatures for one wallet

EIP-7702 arrived with the Pectra upgrade in May 2025. It added transaction type 4, which carries a list of authorizations. Each authorization is a signature by an ordinary account over three values: a chain ID, a contract address and the account nonce. Once processed, the account code becomes 0xef0100 followed by that contract address, and every call to the account runs the contract code in the account context (EIP-7702).

Anyone can submit the transaction. Only the account key can sign the authorization.

At 20:20:59 UTC, block 26,300,753, the operator sent a type 4 transaction to the Binance 14 hot wallet (0x28c6…1d60). It carried 50 authorizations. Every one pointed at the live sweeper, every one used chain ID 1, and each covered a different nonce of Binance 14, from 18,914,775 to 18,914,824. We recovered the signing address from all 50 signatures: each of them is Binance 14.

javascript
// tx 0xad99264d…298b, block 26,300,753, type 0x4, from the attacker operator
authorizationList: [
  { chainId: 1, address: "0x63e842b0…6fae", nonce: 18914824 },  // position 1
  { chainId: 1, address: "0x63e842b0…6fae", nonce: 18914823 },
  // ...
  { chainId: 1, address: "0x63e842b0…6fae", nonce: 18914809 },  // position 16, the one that matched
  // ...
  { chainId: 1, address: "0x63e842b0…6fae", nonce: 18914775 },  // position 50
]
// every entry also carries yParity, r, s: a valid signature by the Binance 14 key

The number follows from how EIP-7702 handles nonces. It checks each authorization against the current nonce of the account and silently skips the ones that do not match. Binance 14 was a busy wallet. In the hour before the attack it sent 635 transactions, about ten a minute, so the attacker could not know the exact nonce at the moment the transaction would land and brought a range instead.

The block shows how tight the timing was. Binance 14 sent a regular transaction with nonce 18,914,808 earlier in the same block, so at execution the wallet nonce was 18,914,809. The 16th authorization matched.

The list runs in descending order, which means that after the match the next nonce had already been passed, and nothing else in the list could apply. One delegation, one nonce increment. We checked: the nonce went from 18,914,808 before the block to 18,914,810 after it, one step for the regular transaction and one for the authorization.

The 50 authorizations against the Binance 14 nonce at execution: 34 already used, 1 match, 15 not yet reached.
The 50 authorizations against the Binance 14 nonce at execution: 34 already used, 1 match, 15 not yet reached.

34 of the 50 signatures were already dead. The lowest one, nonce 18,914,775, was used by a regular Binance 14 transaction at 20:17:47 UTC, 3 minutes and 12 seconds before the attack transaction. At ten transactions a minute, the whole window covered less than five minutes of normal traffic.

The size of the batch hints at the kind of access the attacker had. With the raw private key, none of this would be needed: you sign one authorization for the exact nonce at the moment you send, or you skip delegation and send transfers. A batch of fifty consecutive nonces, set within minutes of the live value, is what you prepare when you can obtain signatures from a system, with some delay, and cannot count on asking twice. That is our inference, and it fits Binance ("no evidence of any wallet private key leak") and TRM, which gives as one reading of the batch "that signatures had to be requested through a system".

The transaction used 1,258,562 gas at 5.2 gwei, about 0.0065 ETH or roughly $15. Under EIP-7702 the sender pays for every authorization in the list, valid or not, so the 49 unused signatures cost the attacker almost nothing.

The EIP-7702 text warns wallet developers directly: applications "must not expect that they can suggest the user sign an authorization", and "There is no safe way to provide this interface." An exchange signing service is a wallet with no person in front of it. If it can produce an authorization at all, that capability deserves the same protection as the key.

Step 3: The sweep

At 20:24:23 UTC, 3 minutes and 24 seconds after the delegation, the operator called Binance 14 directly. The account now ran sweeper code, so the call executed with the wallet's own balances. One transaction moved 167,464.25 ETH and 63 ERC-20 tokens, among them 1,615,409,498.97 USDT, to the attacker address 0x5227…2f8c.

The sweeper left exactly 1 ETH behind. Elliptic values that single transaction at $2.53 billion.

Binance 14 also controlled a separate contract account, an upgradeable proxy at 0xee7a…4055, that held USDC. Through the delegation the attacker made Binance 14 instruct that contract twice: 780,000,000 USDC at 20:41:23 and 43,000,000 USDC at 20:59:47. Those two calls account for the 823 million USDC that Circle later froze.

A second Ethereum hot wallet, Binance 16, sent 28,006 ETH, 55.7 million USDT and 25.9 million RLUSD in the same minutes. It had no delegation code. Those were ordinary signed transfers, which TRM and Chainalysis also report.

Add the five Binance 14 sweeps (172,624 ETH in total) to the 28,006 ETH from Binance 16 and you get the 200,630 ETH that TRM reports for Ethereum. USDT reconciles the same way: 1,615.4 million in the first sweep, 3.9 million at 21:04 and 200.4 million at 21:44, plus 55.7 million from Binance 16, give the 1.875 billion USDT in the TRM count.

Binance systems kept using the wallet in the meantime. Binance 14 sent 39 transactions of its own between 20:21 and 20:41, some of them routine calls to the same USDC contract the attacker would use at 20:41.

Step 4: The wallet stayed delegated

An EIP-7702 delegation does not expire. It stays on the account until the account signs a new one. Binance 14 revoked it at 00:10:35 UTC on October 30, with a type 4 transaction delegating to the zero address (tx). That was 3 hours and 49 minutes after the delegation landed.

What the attacker took from Binance 14 after the first sweep, while the delegation stayed active. Data: Ethereum mainnet, our reads.
What the attacker took from Binance 14 after the first sweep, while the delegation stayed active. Data: Ethereum mainnet, our reads.

During that time money kept arriving in the wallet and the attacker kept collecting it:

  • 21:04:23: 1,699.9 ETH and 23 tokens.
  • 21:44:11: 369.8 ETH and 14 tokens, among them 200.4 million USDT.
  • 22:39:35: 128.5 ETH and 122 tokens, now to a new address 0xa97b…8d10. Tether had frozen the first receiving wallet at 21:01.
  • 23:56:47: 2,961.9 ETH. That ETH arrived in a single transfer at 23:55:47, one minute earlier.

Between 23:36 and 23:55 the operator sent five more sweep calls that moved nothing. The attacker appears to have been polling the wallet for the next refill. Meanwhile, between 22:55 and 23:08, Binance 14 itself sent a run of token transfers to one address, 0xf977…acec, which looks like Binance moving the remaining tokens to its own wallet. The revocation came after the last sweep.

The other nine chains

TRM reports standard signed transfers on every other chain, with no EIP-7702 involved. The XRP Ledger went first: between 20:05 and 20:09 five Binance wallets sent 233.46 million XRP to one address, each left at its minimum reserve.

Solana and Optimism followed shortly after 20:10. At 20:20 the Bitcoin hot wallet sent 18,270 BTC, split in the same block into pieces of 1,000 and 100 BTC. Tron followed within two minutes. A second wave hit Avalanche and Polygon at 23:05.

These chains use different transaction formats, and Solana uses a different signature algorithm (Ed25519). Hot wallets on nine of the ten chains signed transfers for the attacker within about half an hour, and Polygon followed at 23:05. EIP-7702 explains only the Ethereum part. What the chains have in common, as far as public data goes, is that the attacker could get hot wallet signatures on each of them.

What Binance has said about the root cause

The attack path as far as public information goes. Solid: stated by Binance in preliminary updates or visible onchain. Dashed: not disclosed yet.
The attack path as far as public information goes. Solid: stated by Binance in preliminary updates or visible onchain. Dashed: not disclosed yet.

Binance has published four updates so far, and two of them address the cause. The first, on October 30 at 02:23 UTC: "the security 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. We have found no evidence of any wallet private key leak." (Binance)

The second, the same evening, adds that "our subsequent investigation has uncovered additional points of breach". Co-CEO Richard Teng wrote that "the attacker did not simply use one engineer's permissions, and this was not a single 'one-click' action" (BleepingComputer). According to Elliptic, Teng said in a video update on October 30 that the attacker's use of EIP-7702 delegation "did not pass through our normal approval controls". Reuters reports that Teng described a "complex attack" involving malicious software designed to delete evidence of its activity.

Put together with the chain data, our reading is this. Someone got from an engineer laptop, and possibly other footholds, to a point allowed to submit signing requests. The signing layer then signed what it received on ten chains, including a payload type that a withdrawal service never needs. Teng says the delegation went around the normal approval controls, and Binance has not said whether those controls covered authorizations at all.

What the chain cannot tell us: how the service container reached the signers, whether the hot wallet keys sit in MPC or HSM custody, whether approval rules existed for authorizations and were bypassed or never existed, and why the Bitcoin and Tron signers accepted the requests. Binance said on October 30 that it expected to share more technical findings within about 48 hours, and on November 1 that a post incident report will follow once the investigation is complete. We will update this post when it does.

Freezes, and the race against them

Stablecoins were most of what anyone could stop. Per TRM, Tether froze 971.1 million USDT in the main receiving wallet at 21:01 UTC, 37 minutes after the sweep. Circle froze 823 million USDC at 21:04. Ripple froze 40.5 million RLUSD at 22:01, World Liberty Financial froze USD1 at 22:10, and the Arbitrum Security Council forced 8,426 ETH and 74.6 million ARB out of the attacker wallet on Arbitrum shortly after midnight.

Estimates of the frozen total range from $2.7 billion (TRM) to about $3 billion (Binance). Bitcoin, XRP and SOL have no issuer, so nothing there could be frozen.

The attacker moved the stablecoins quickly. TRM saw about 325 million USDT sold to market makers through UniswapX and intent contracts at an implied discount above 10%. Another wallet supplied 60 million USDT to Aave and borrowed about 19,760 ETH against it. On October 31 the FBI said the group was "converting stolen assets primarily into Ethereum (ETH)" and asked node operators, instant exchanges and DeFi services to block transactions with 608 Ethereum addresses listed in its alert, along with Bitcoin and Solana addresses.

Earlier thefts that passed the checks

In May 2019 Binance lost more than 7,000 BTC, about $40 million, from a hot wallet that held roughly 2% of its bitcoin. Binance said then that the transaction "is structured in a way that passed our existing security checks" (CNBC).

The Bybit theft of February 2025, which the FBI also attributed to TraderTraitor (IC3), started with a compromised Safe{Wallet} developer machine. The attackers changed JavaScript served from an AWS S3 bucket, so that Bybit signers approved a transaction that replaced their cold wallet logic with a contract exposing sweep functions (Sygnia). Radiant Capital lost more than $50 million in October 2024 after attackers gained control of at least three of its multisig signers (rekt.news). We covered its earlier, unrelated January 2024 exploit step by step.

Elliptic points to the same traits in earlier TraderTraitor thefts: long preparation, apparent targeting of staff, and use of the victim's own systems to sign transactions. In the Bybit case the keys stayed with their holders and signed a transaction that the tampered web interface had altered.

What we would change in a hot wallet signing stack

These are the controls we would check first on any exchange, custodian or treasury that signs automatically.

1. Put the policy inside the signer. The service that requests signatures can be compromised, as it was here. The signer has to decode every payload, recognize its type and refuse whatever it cannot classify. No raw hash signing for hot wallet keys: an EIP-7702 authorization is a signature over keccak256(0x05 || rlp([chain_id, address, nonce])), and a signer that only sees the 32 byte hash cannot tell it apart from anything else.

2. Deny EIP-7702 authorizations for custody keys by default. If a wallet really needs delegation, allowlist the delegate contract and require a separate quorum. A request for many authorizations across consecutive nonces should be treated as an incident on its own, as TRM also recommends.

3. Watch the code at your own addresses every block. For an EOA hot wallet, eth_getCode must return 0x. A value starting with 0xef0100 means the account now runs somebody else's code.

python
# Run on every new block (for example from a newHeads subscription).
# An EOA hot wallet must never carry code.
import requests

RPC = "https://your-archive-or-full-node"
HOT_WALLETS = ["0xYourHotWallet1", "0xYourHotWallet2"]

def code_at(address: str) -> str:
    body = {"jsonrpc": "2.0", "id": 1, "method": "eth_getCode", "params": [address, "latest"]}
    return requests.post(RPC, json=body, timeout=10).json()["result"]

for wallet in HOT_WALLETS:
    code = code_at(wallet)
    if code != "0x":
        delegate = "0x" + code[8:48] if code.startswith("0xef0100") else "unknown code"
        halt_withdrawals_and_refills(wallet)   # your circuit breaker
        page_on_call(f"{wallet} delegated to {delegate}")   # your alerting

4. Make revocation a prepared, tested action. Undoing the delegation took one type 4 transaction, and it came 3 h 49 min after the delegation landed. Keep a revocation path that does not depend on the infrastructure under investigation, and practice it.

5. Tie refills to wallet health. Funds kept arriving in a wallet that was running attacker code: 2,962 ETH came in at 23:55:47 and was gone a minute later. A circuit breaker that stops refills when the wallet code, nonce rate or outflow pattern changes keeps that money at home.

6. Cap what a single hot wallet can lose. One sweep took more than $2.5 billion from one address. Enforce balance caps and outflow limits per wallet and per hour inside the signer, sized to real withdrawal volume, with larger moves going through a slower, quorum approved path.

7. Split signing paths by chain and wallet tier. Whatever the compromised path was, it produced valid signatures on nine chains within about half an hour and on a tenth three hours later. Separate hosts, credentials and approval rules per chain limit how far one breach reaches.

8. Treat developer machines as part of custody. The first lead in the Binance investigation was a compromised laptop. There should be no route from an engineer workstation to a container that can submit withdrawals, and production signing access should be granted per task and expire on its own.

What happens to Binance users

Binance says it will cover all losses from its Secure Asset Fund for Users (SAFU) and company funds. On October 30 it had set aside more than $6.34 billion. On October 31 it reported 90% of the stolen amount covered, using part of SAFU, part of its futures insurance fund and corporate treasury (Binance). Co-CEO Yi He told Reuters that half of the SAFU fund would be used, and Binance committed to refilling it to about $1 billion.

Withdrawals started reopening in phases on November 1 between 06:00 and 09:00 UTC, on 15 networks including Bitcoin, Ethereum, BNB Chain, Tron, Solana and the XRP Ledger (Binance). The same update put coverage at about 95%. After the news broke, bitcoin fell nearly 5%, ether nearly 6% and BNB nearly 10% (The Guardian).

If you build or audit signing infrastructure, our blockchain development team reviews signing infrastructure for exchanges and DeFi teams.

Frequently Asked Questions

Signing service review for exchanges and DeFi teams

We review signing policies, EIP-7702 exposure and wallet monitoring, and show you what an attacker with a foothold could get signed.

Book a free technical validation

Sources

Onchain figures for Ethereum come from our own reads of Ethereum mainnet through public RPC nodes (blocks 26,289,786 to 26,301,896). Everything else is attributed in the text.