Skip to main content
Hashnode
AI Software Development

The $6.3B Binance Hack: How EIP-7702 and One Laptop Drained Hot Wallets on 10 Chains

Updated 21 min readMarkdown
A
AI Developer
The $6.3B Binance Hack: How EIP-7702 and One Laptop Drained Hot Wallets on 10 Chains

On the evening of October 29, 2026 (UTC), Binance hot wallets on ten blockchains sent their balances to an attacker in a burst that lasted roughly half an hour. Binance says the estimated total impact is "around $6.3B" and that about $3 billion has been frozen on-chain so far (FinanceFeeds, quoting Binance's statement; BBC). Blockchain intelligence firm TRM Labs puts the figure at about USD 6.36 billion and attributes the attack "with high confidence" to TraderTraitor, the North Korean unit the FBI named for the 2025 Bybit theft (TRM Labs).

If those numbers hold, this is the largest crypto theft on record, about four times Bybit's USD 1.5 billion in February 2025.

This post is for developers, founders and technically minded traders. We go through what is confirmed, how the Ethereum part of the attack worked (it used EIP-7702, the account delegation feature Ethereum added in 2025), what the evidence says about Binance's signing infrastructure, and what you can do this week if you run wallets, build on exchange APIs or just keep money on an exchange. There is tested Python code for spotting the pattern TRM describes.

The story is less than 48 hours old. Binance has not published its root cause yet, and some numbers below differ between sources. We say so where they do. Facts come from the sources linked inline. Sections marked Our take are opinion.

Disclaimer: This article is educational and is not financial, investment or legal advice. Crypto assets are volatile and exchange balances carry custody risk. Do your own research and talk to a qualified professional before making decisions about your funds.

TL;DR

  • What: On October 29, 2026, an attacker moved roughly USD 6.3 billion out of Binance hot wallets on Ethereum, Bitcoin, Tron, the XRP Ledger, Solana, Arbitrum, Optimism, Base, Avalanche and Polygon. Most of it left in about 20 minutes starting at 20:05 UTC (TRM Labs).
  • Binance's preliminary cause: a compromised DevOps engineer's laptop "allowed an attacker to gain access to a service container and submit unauthorized withdrawal transactions." Binance says it found "no evidence of any wallet private key leak" (Bitcoin.com News; PANews).
  • How on Ethereum: one transaction carried 50 EIP-7702 authorizations, each signed by a Binance hot wallet for a consecutive nonce. One matched, the wallet started running the attacker's sweeper contract, and 167,464 ETH plus 1.615 billion USDT left in a single call (TRM Labs; ChainCatcher / Dickson).
  • Freezes: Tether, Circle, Ripple, World Liberty Financial and Arbitrum's Security Council froze about USD 2.7 billion by TRM's count. Binance says about USD 3 billion.
  • Users: Binance says it will "cover all losses from the SAFU fund and the company's funds", has suspended deposits and withdrawals, and will publish an updated proof of reserves after remediation. Binance.US says it is not affected (BBC).
  • The lesson for builders: the attacker didn't need the keys. They needed something that was allowed to ask for signatures. That is a design problem most of us have in smaller form.

What we know so far

The timeline

All times are UTC and come from TRM Labs' write-up and an on-chain reconstruction by CertiK engineer and SEAL member Dickson, translated by ChainCatcher. Dickson's figures were his own count as of about 00:00 UTC on October 30 and had not been confirmed by Binance.

  • October 28, 07:39: the attacker's operator wallet receives the first of three small withdrawals from Tornado Cash, the mixing service. TRM says preparation began "at least 36 hours before the theft."
  • October 29, early: the operator deploys a sweeper contract and tests it. Dickson reports test runs on the attacker's own wallets between 13:51 and 16:47, including EIP-7702 delegation and sweeping test USDT and USDC, and a "v2" with a general call function deployed at 15:59.
  • 20:04:52: the first move fails. A Binance XRP wallet sends 42.75 million RLUSD to an XRP Ledger account that doesn't exist yet, so it bounces. Eight seconds later a 185 million XRP payment succeeds and creates the account (Dickson).
  • 20:05–20:09: five Binance XRP wallets send 233.46 million XRP to one address, each left with only its minimum reserve (TRM).
  • Around 20:10–20:18: Solana (about 965,000–970,000 SOL depending on the source) and Optimism (44.2 million OP per Dickson).
  • 20:20: a Binance Bitcoin hot wallet sends 18,270 BTC, which the receiving address immediately starts splitting into 1,000 BTC and 100 BTC pieces, a "peel chain." Within two minutes a Tron hot wallet sends 612.7 million USDT and 46.4 million TRX (TRM).
  • 20:20:59: the Ethereum delegation transaction with 50 authorizations lands (Dickson).
  • 20:24:23: a sweep() call moves 167,464 ETH and 63 tokens, including 1.615 billion USDT, out of the delegated Binance wallet (TRM, Dickson).
  • 20:41 onward: the delegation stays in place, so new deposits keep getting swept: at 20:41, 20:59, 21:04, 21:44, 22:39 and 23:56 (TRM). Because that wallet was also the executor of a separate Binance smart account, the attacker pulled 823 million USDC out of it.
  • 21:01 and 21:04: Tether freezes 971.1 million USDT in the main receiving wallet, and Circle freezes the 823 million USDC (TRM).
  • 22:15: Binance's deposit and withdrawal suspension, per FinanceFeeds.
  • 23:05: a second wave hits Binance wallets on Avalanche and Polygon (TRM).
  • October 30, 02:25: Binance's statement with the $6.3B figure, the DevOps laptop finding, and the SAFU commitment (FinanceFeeds).

How much, and how much is frozen

TRM values each transfer at the price when it was taken and gets about USD 6.36 billion. By chain: Ethereum about USD 3.79 billion (200,630 ETH plus 185 other tokens, including 1.875 billion USDT, 823 million USDC and 88.5 million RLUSD), Bitcoin about USD 1.47 billion, Tron about USD 628 million, XRP about USD 296 million, Solana about USD 96 million, and smaller amounts on the others.

Freezes, by TRM's count at 00:30 UTC on October 30: Tether about 1.77 billion USDT, Circle about 825 million USDC, Ripple 40.5 million RLUSD, World Liberty Financial 27.8 million USD1, and Arbitrum's Security Council, which used its emergency powers to force 8,426 ETH and 74.6 million ARB (about USD 30 million) out of the attacker's wallet. Roughly USD 2.7 billion in total. Binance's own figure is about USD 3 billion, and earlier it reported a verified USD 2.54 billion.

TRM says the attacker still controls more than 420,000 ETH and 18,270 BTC, about USD 2.4 billion that no issuer can freeze.

What Binance has said

From Binance's statement, as quoted by FinanceFeeds, Bitcoin.com News and PANews:

  • 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."
  • "We have found no evidence of any wallet private key leak."
  • It has "revoked the affected address authorisation" and suspended deposits and withdrawals.
  • Losses will be covered from the SAFU fund and company funds.
  • It will publish a detailed technical post-mortem and an updated proof of reserves.

Co-CEO Yi He said withdrawals will be enabled "as soon as the security scan is complete" (Bitcoin.com News). No reopening date had been given when we wrote this.

How EIP-7702 was turned into a drain

You don't need to be a Solidity developer to follow this, but it helps to know what EIP-7702 is.

EIP-7702 in one paragraph

EIP-7702 arrived with Ethereum's Pectra upgrade in May 2025. It lets an ordinary externally owned account (EOA), the kind of wallet controlled by a single private key, point itself at a smart contract. After that, calls to the wallet run the contract's code. The goal was good: batching, gas sponsorship and smart-wallet features without moving funds to a new address.

The mechanics matter here:

  1. The wallet owner signs an authorization: the hash of 0x05 || rlp([chain_id, contract_address, nonce]).
  2. Anyone can put that signed authorization into a type-4 transaction and pay the gas. The account that pays doesn't have to be the wallet.
  3. When it executes, the chain checks that the authorization's nonce equals the wallet's current nonce. If it matches, the wallet's code is set to a 23-byte delegation indicator, 0xef0100 followed by the contract address, and the wallet's nonce goes up by one. If it doesn't match, that authorization is skipped and the rest of the transaction still runs.
  4. The delegation persists until the wallet signs a new one.
  5. A chain_id of 0 makes an authorization valid on every EVM chain.

What the attacker did with it

A busy exchange hot wallet sends withdrawals constantly, so its nonce moves forward every few seconds. A single pre-signed authorization would probably go stale before it could be used.

According to TRM and Dickson, the attacker solved that by having the Binance hot wallet sign 50 authorizations for 50 consecutive nonces, 18,914,775 through 18,914,824. Dickson notes the wallet had used nonce 18,914,775 itself at 20:17:47, so the batch was signed minutes before use. When the transaction landed, the authorization for nonce 18,914,809 matched (the wallet had just used 18,914,808 in the same block). The other 49 were simply ignored, which is how the spec works.

From then on the wallet ran the attacker's sweeper, which accepted instructions only from the attacker's operator address. Three minutes and 24 seconds later, one sweep() call emptied it. Because a delegation stays in place, every new deposit that arrived over the next three hours was swept too, until the stablecoin issuers froze tokens inside the wallet itself.

That is the clever and ugly part. A normal stolen-signature attack gets you one transaction. A delegation gets you the wallet until someone signs it back.

Why "no private key leak" can be true

Binance says no keys leaked. TRM points out why that doesn't contradict the theft. On the other nine chains, Binance wallets sent funds to the attacker through ordinary signed transfers, with different chains, key types and signature schemes, all within about half an hour. Another Ethereum hot wallet sent 28,006 ETH, 55.7 million USDT and 25.9 million RLUSD the same way, with no delegation at all.

In TRM's words, "the most likely explanation is that the attacker gained the ability to make Binance's hot wallet signing system sign transactions of its choosing across chains." The batch of 50 authorizations "suggests the access may have been limited in time, or that signatures had to be requested through a system."

That lines up with Binance's description: a compromised laptop gave access to a service container that could submit withdrawal transactions. FinanceFeeds summed it up: the attacker "did not need to steal the key, only to reach the machine that uses it."

Until the post-mortem is out, the exact path from laptop to container to signer is unknown. Don't trust anyone, including us, who claims to know it.

The race against the freezes

Stablecoins can be frozen by their issuers. ETH and BTC can't. So the attacker's first job after the sweep was converting. TRM reports about 325 million USDT sold to market makers and solvers through UniswapX and other intent-based contracts for about 122,300 ETH, at an implied price near USD 2,650 when ETH traded around USD 2,300–2,350. That's a discount of more than 10%, which tells you how much speed mattered. Another wallet supplied 60 million USDT to Aave and borrowed about 19,760 ETH against it before Aave froze the affected markets. On Tron, 300 million USDT went toward the JustLend lending protocol.

TRM expects the next stage to involve cross-chain bridges, swap services and OTC brokers, and is asking exchanges to screen deposits against the attacker addresses it has labelled.

The pattern: Bybit, then Binance

In February 2025, attackers compromised a developer machine at wallet provider Safe and used it to show Bybit's signers a malicious transaction, which they then approved. The FBI attributed that theft to North Korea. TRM lists the shared features with this week's attack: small Tornado Cash withdrawals to fund an operator wallet, staging that starts well before the theft, and signatures obtained in advance then executed in one burst. It also mentions the KelpDAO hack in April 2026 as fitting the pattern.

In both of the two largest exchange thefts on record, the cryptography held. What failed was an engineer's computer and the trust that computer had in the system around it.

What to do this week

If you run wallets or a signing service

These recommendations come straight from TRM's guidance, with our implementation notes:

  1. Alert on EIP-7702 delegations on treasury and hot wallets. A delegated EOA has code at its address, 0xef0100…. Any code appearing on a wallet that should have none is an incident.
  2. Refuse unexpected 7702 authorizations at the signer. Your policy engine, HSM front end or MPC coordinator should reject them by default, and treat "many authorizations over a range of nonces" as an indicator of compromise.
  3. Keep a tested revocation ready. Undoing a delegation means the wallet signs a new authorization pointing to the zero address. Practise that before you need it.
  4. Separate signing by chain and wallet tier. In this incident one actor got valid signatures on ten chains within hours. One compromised caller should not reach every signer.
  5. Market makers and solvers: screen counterparties before filling large orders. The 325 million USDT that was sold had come from the hack minutes earlier.

Here is a small Python module that does three of those things: recover who signed a 7702 authorization, refuse suspicious signing requests, and recognise a delegated wallet from its code. We tested it on our box with eth-account 0.14.0. It signs authorizations with a throwaway key, recovers the signer, runs the 50-nonce batch from this incident through the policy check, and checks the delegation parser.

# eip7702_guard.py  (pip install "eth-account>=0.13.6")
import rlp
from eth_hash.auto import keccak
from eth_keys import keys

MAGIC = b"\x05"                 # EIP-7702 authorization domain byte
DELEGATION_PREFIX = "0xef0100"  # code of a delegated EOA = 0xef0100 || address

def auth_digest(chain_id: int, address: str, nonce: int) -> bytes:
    addr = bytes.fromhex(address[2:])
    return keccak(MAGIC + rlp.encode([chain_id, addr, nonce]))

def recover_authority(chain_id, address, nonce, y_parity, r, s) -> str:
    sig = keys.Signature(vrs=(y_parity, r, s))
    pub = sig.recover_public_key_from_msg_hash(auth_digest(chain_id, address, nonce))
    return pub.to_checksum_address()

def check_signing_request(req: dict, allowed_delegates: set, max_auths: int = 1):
    """Return a list of reasons to REFUSE a request to sign 7702 authorizations."""
    reasons = []
    auths = req.get("authorizations", [])
    if not auths:
        return reasons
    if len(auths) > max_auths:
        reasons.append(f"{len(auths)} authorizations requested (max {max_auths})")
    nonces = sorted(a["nonce"] for a in auths)
    if len(nonces) > 1 and nonces[-1] - nonces[0] + 1 == len(nonces):
        reasons.append(f"consecutive nonce range {nonces[0]}..{nonces[-1]} (nonce spraying)")
    for a in auths:
        if a["address"].lower() not in allowed_delegates:
            reasons.append(f"delegate {a['address']} not on allowlist")
        if a["chain_id"] == 0:
            reasons.append("chain_id 0 = valid on every EVM chain")
    return reasons

def is_delegated(code_hex: str):
    """Given eth_getCode output, return the delegate address or None."""
    code = code_hex.lower()
    if code.startswith(DELEGATION_PREFIX) and len(code) == 2 + 46:
        return "0x" + code[len(DELEGATION_PREFIX):]
    return None

And the test that replays the shape of this incident:

# test_guard.py
from eth_account import Account
from eip7702_guard import *

acct = Account.create()
sweeper = "0x" + "ab" * 20
for n in (0, 18_914_809):
    signed = acct.sign_authorization({"chainId": 1, "address": sweeper, "nonce": n})
    assert recover_authority(1, sweeper, n, signed.y_parity, signed.r, signed.s) == acct.address

batch = {"authorizations": [{"chain_id": 1, "address": sweeper, "nonce": n}
                            for n in range(18_914_775, 18_914_825)]}
print(*check_signing_request(batch, allowed_delegates=set()), sep="\n")

ok = {"authorizations": [{"chain_id": 1, "address": sweeper, "nonce": 5}]}
assert check_signing_request(ok, {sweeper}) == []
assert is_delegated("0xef0100" + "ab" * 20) == sweeper
assert is_delegated("0x") is None

Output on our box:

50 authorizations requested (max 1)
consecutive nonce range 18914775..18914824 (nonce spraying)
delegate 0xabababababababababababababababababababab not on allowlist

The important design point: put check_signing_request in front of the signer, in a separate service with its own deploy pipeline and credentials, not in the application that builds the request. If the caller is compromised, as Binance's service container apparently was, a check inside the caller is worth nothing.

A delegation watcher you can run today

This polls eth_getCode for the addresses you care about and alerts if one becomes delegated. We ran it once against a public RPC on our box: the burn address showed no code, and the USDT contract was correctly reported as having contract code.

# watch_delegation.py  — usage: python watch_delegation.py 0xYourHotWallet 0xYourTreasury
import os, sys, time, requests
from eip7702_guard import is_delegated

RPC = os.environ.get("ETH_RPC", "https://ethereum-rpc.publicnode.com")
WATCH = [a.strip() for a in sys.argv[1:]]

def get_code(addr):
    r = requests.post(RPC, json={"jsonrpc": "2.0", "id": 1,
                      "method": "eth_getCode", "params": [addr, "latest"]}, timeout=10)
    r.raise_for_status()
    return r.json()["result"]

def check_once():
    alerts = []
    for addr in WATCH:
        code = get_code(addr)
        delegate = is_delegated(code)
        if delegate:
            alerts.append(f"ALERT {addr} is delegated to {delegate}")
        elif code not in ("0x", "0x0"):
            alerts.append(f"WARN {addr} has contract code ({len(code)//2-1} bytes)")
    return alerts

if __name__ == "__main__":
    while True:
        for line in check_once() or ["ok: no delegation on watched wallets"]:
            print(time.strftime("%H:%M:%S"), line, flush=True)  # wire this to your pager
        time.sleep(12)  # roughly one Ethereum slot

Polling is a floor, not a ceiling. In production, subscribe to new blocks and decode type-4 transactions so you see the authorization list before the sweep, run it against more than one RPC provider, and repeat for every EVM chain where you hold a hot wallet, since TRM saw delegated or drained wallets on several L2s too. In this incident the gap between delegation and the main sweep was 3 minutes 24 seconds. A watcher that pages a human in under a minute, with a pre-approved revocation runbook, at least gives you a chance.

If you're a DevOps or platform engineer anywhere

Binance's preliminary finding is about an engineer's laptop reaching a production container. That isn't a crypto-specific problem. Questions worth asking about your own systems this week:

  • Can any laptop reach a container that can move money or data? Production access should go through a short-lived, audited path (just-in-time access, session recording, hardware-key MFA), not standing kubeconfigs or SSH keys on a developer machine.
  • Is "can submit a withdrawal" the same permission as "can approve one"? Submission and approval should live in different services with different credentials, with limits enforced by the approver.
  • Do your signers have velocity limits? Draining ten chains in half an hour is a rate anomaly as well as a security one. A signer that refuses to send more than X per hour per wallet, without a second, independent approval, caps the damage.
  • How big are your hot wallets? Hot wallets exist to pay withdrawals. Anything above what you expect to need before the next cold-to-hot top-up is exposure.

We wrote about the same principle for AI agents earlier this week: give each actor a short-lived, narrowly scoped grant instead of a broad standing credential. A signing service is just another actor.

If you trade on Binance or any exchange

Binance says user funds are safe and losses will be covered. We cannot verify that statement until the updated proof of reserves is out. Practical points that don't depend on either:

  • Use official channels only. Binance itself urged users to rely on official channels (BBC). Big incidents bring phishing: fake "claim your compensation" sites, fake support DMs and fake "withdrawals reopened" links.
  • Audit your API keys. If you run bots against exchange APIs, now is a good time to check that each key has only the permissions it needs, has withdrawals disabled unless strictly required, is restricted to your server's IP addresses, and is rotated. Keys with trading but no withdrawal permission limit what a stolen key can do.
  • Turn on withdrawal address allowlisting where the exchange offers it, and use hardware-key 2FA rather than SMS.
  • Read the proof of reserves when it comes out, and know what it proves. A proof of reserves shows assets the exchange controls and lets you check that your balance was included in the liabilities snapshot (usually via a Merkle tree). It is a point-in-time snapshot. It does not prove the absence of other liabilities, and it would not have prevented this attack.
  • Decide how much you keep on any exchange. That's a personal risk decision, not advice from us. Self-custody has its own risks: lost keys, phishing, and wallet-drainer signatures, including malicious 7702 authorizations.

Our take

This section is opinion.

The keys were never the weak point. For years, exchange security debates were about cold storage percentages, HSMs, multisig and MPC. Those still matter. But Bybit in 2025 and Binance in 2026 both appear to have failed one level up, at the question "who is allowed to ask the signer for a signature, and what does the signer check before it says yes?" If a compromised container can get valid signatures on ten chains in half an hour, the signer is acting as a printer, not a gatekeeper.

EIP-7702 changed what one signature is worth. Before Pectra, a stolen signature on an EOA meant one transaction. Now a single authorization can hand the whole account, including future deposits, to someone else's code until it is revoked. Every custodian, wallet vendor and exchange signing policy should treat a 7702 authorization as the most dangerous thing it can sign, as dangerous as a key export. Defaults should be "refuse", with allowlisted delegates and a human in the loop.

The freezes worked, and that is a double-edged lesson. Tether froze the main USDT wallet 37 minutes after the sweep, and the Arbitrum Security Council forced funds out of an attacker wallet. That saved billions. It also shows, very visibly, that large parts of "decentralised" finance have admin keys and emergency powers. Builders should know which of their assets can be frozen and by whom, in both directions.

Speed of disclosure deserves credit, with an asterisk. Binance gave a figure, a preliminary cause and a funding commitment within about six hours of the drain starting. That's fast. FinanceFeeds noted its first statement was edited twice in 13 minutes, which is normal in a crisis. The real test is the post-mortem: how a laptop reached a signing-capable container, why the signer accepted 50 consecutive-nonce authorizations, and what changed.

Don't wait for the post-mortem to fix your own version of this. Most teams reading this don't hold billions. But most of us have a CI runner, a support tool or an AI agent that can trigger payments, refunds, data exports or deployments, and a laptop somewhere that can reach it. The cheap fixes (separate submit from approve, put policy in front of the signer, rate-limit, alert on the weird thing) are the same at every scale.

What to watch next

  • Binance's technical post-mortem and root cause.
  • The withdrawal reopening date and the updated proof of reserves.
  • Official attribution. TRM's is high confidence; no government agency had commented when FinanceFeeds published.
  • Laundering of the roughly USD 2.4 billion in ETH and BTC that can't be frozen, through bridges, swap services and OTC desks.
  • Whether wallet vendors and custodians change default EIP-7702 signing policies.

We'll update this post if the post-mortem changes anything above. At Lycore we build software where money and automation meet, so we'll be reading it closely.

Disclaimer (again): Educational content only. Nothing here is financial, investment, legal or security-assurance advice. Figures are as reported by the cited sources at the time of writing and may change.

Sources

8 views

About the author

  • AI Developer
    Custom software & AI development company. We build production-ready AI integrations, mobile apps, and web platforms for businesses that want real results. lycore.com

Comments

Join the discussion

No comments yet. Be the first to comment.

More from this blog