On 29 October 2026, an attacker moved about US$6.36 billion out of Binance wallets on ten blockchains, most of it in roughly 20 minutes from 20:05 UTC. That is TRM Labs' figure; Binance cites about $6.3 billion. It is the largest crypto theft on record. TRM Labs and Chainalysis attribute it to TraderTraitor, a North Korean hacking unit, and the FBI named the same group on 31 October.
On Ethereum, the attacker used an EIP-7702 authorization signed by Binance's own hot wallet to install a sweeper contract on it. On the other chains, the wallets simply signed ordinary transfers. Either way, Binance's signing system signed things it should never have signed. That is the lesson for every team that runs hot wallets.
What happened, in numbers
| Item | Figure (as of 3 November 2026) |
|---|---|
| Total taken | About $6.36bn at transfer-time prices (TRM); Binance cites about $6.3bn; Chainalysis about $6.4bn |
| Largest chain | Ethereum, about $3.79bn, including 200,630 ETH and 1.875bn USDT |
| Other chains | Bitcoin (18,270 BTC, about $1.47bn), Tron (about $628m), XRP Ledger (about $296m), Solana, Arbitrum, Optimism, Base, Avalanche, Polygon |
| Frozen | Nearly $2.7bn by 00:30 UTC on 30 Oct (TRM); about $2.8bn by 3 Nov (Chainalysis) |
| User coverage | Binance said 90% covered on 31 Oct, 95% on 1 Nov, 98% in its 3 Nov security report |
| Attribution | TraderTraitor (DPRK): TRM "with high confidence", Chainalysis, FBI |
The freezes came from issuers and one Layer 2 governance body acting within hours. TRM recorded Tether freezing about $1.77bn of USDT across chains and Circle about $825m of USDC. Ripple froze 40.5m RLUSD and World Liberty Financial 27.8m USD1. The Arbitrum Security Council forced out 8,426 ETH and 74.6m ARB, about $30m. The attacker raced to swap stablecoins into ETH before the freezes landed. TRM puts the remainder beyond any issuer's reach at more than 420,000 ETH and 18,270 BTC, about $2.4bn.
How the attacker got in
Binance has not published a full technical root cause. On 3 November, co-CEO Richard Teng told CNBC the attackers "spent months building their way in". According to Binance's security report as described by CNBC:
- In June, an engineer was lured into installing a tampered version of a developer tool (a Homebrew installation) after searching for an AI coding tool.
- In September, attackers posing as recruiters gave another engineer a coding exercise with hidden malware.
- The attackers moved through internal AI tools and reached the system that authorised wallet transactions.
Teng said earlier that investigators found no evidence that wallet private keys leaked. TRM's reading of the on-chain evidence fits that: the attacker gained "the ability to make Binance's hot wallet signing system sign transactions across chains". Binance says it has rebuilt the affected wallet system and internal AI tool, replaced compromised devices, revoked the affected engineers' credentials and tokens, and brought in an independent expert to review the work.
This is the same pattern as the Bitget breach in September. In both cases the keys stayed safe while the system feeding requests to them was compromised. Chainalysis watched Binance-stolen funds mix with Bitget proceeds in real time, which strengthened its attribution.
EIP-7702 in plain terms
EIP-7702 shipped in Ethereum's Pectra upgrade in May 2025. It lets an ordinary wallet (an externally owned account, or EOA) point to a smart contract and run that contract's code as if it were its own. This enables batching, gas sponsorship and spending sub-keys.
The wallet grants this by signing an authorization: a small message containing a chain ID, the contract address to delegate to, and the wallet's current nonce. Anyone can submit that signed authorization in a transaction. Once processed, the wallet's code becomes a pointer to the contract, and the delegation persists until the wallet signs a new authorization to change or clear it.
Three properties make this dangerous for custody keys:
- It hands over everything. The EIP warns that delegated code has unrestricted access to the account and that "a poorly implemented delegate can allow a malicious actor to take near complete control".
- It persists. One signature keeps working for every future deposit until it is revoked.
- It can be pre-signed. Each authorization is valid only at a specific nonce, so an attacker who can obtain signatures in advance simply asks for a range.
That last point is what TRM observed at Binance. The operator submitted one transaction with 50 authorizations, each signed by the Binance Ethereum hot wallet for 50 consecutive nonces. As TRM put it, "One matched, which was all the attacker needed." Three minutes and 24 seconds later, the full balance had been swept: 167,464 ETH and 63 tokens. Because the delegation persisted, later sweeps followed over the next few hours. The hot wallet also acted as executor for a separate Binance smart account, which let the attacker pull 823m USDC that Circle then froze.
Did EIP-7702 cause the hack? No. Blockaid's Ido Ben-Natan told Cointelegraph the takeaway is that "ultimately the signer signed a transaction that they shouldn't have". On the other nine chains the attacker took funds with plain signed transfers. What 7702 did was turn one round of signing access into a persistent "sweep" on Ethereum.
Why authorization signing is high-risk
Most custody policy engines were built to inspect transactions: destination, value, asset, calldata. An EIP-7702 authorization is not a transaction. It is a separate signed tuple that can ride inside someone else's transaction. A policy that checks "amount below limit, destination on allowlist" can pass a request that never moves funds directly but gives away the whole account.
The EIP authors saw this coming. The specification states that applications "must not expect that they can suggest the user sign an authorization" and that, for wallets offering a generic signing interface, "there is no safe way to provide this interface".
Controls that would have helped
None of these is exotic. Together they close the path TRM describes.
| Control | What it does |
|---|---|
| Refuse 7702 authorizations on custody keys | The signing policy rejects any EIP-7702 authorization (a message hashed with the 0x05 prefix) from hot, warm or treasury keys outright. Custody wallets have no reason to delegate. |
| Allowlist delegate contracts | If a wallet does need 7702, only sign authorizations to a short, audited list of delegate addresses, never to anything new. |
| Scope chain ID and nonce | Never sign chain_id = 0, which is valid on every chain. Never sign more than one future nonce, and alert on any request for a nonce range. |
| Independent decode and simulation | A separate service decodes every payload and simulates the result before signing. "Withdraw $X to user Y" must match what the bytes actually do. |
| Rate limits at the signer | Per-hour value caps and an automatic pause when outflows spike, enforced where the key lives, not in the app that may be compromised. |
| Delegation monitoring | Alert immediately if any company EOA's code changes from empty to a 0xef0100 delegation designator, and have a pre-signed or ready process to clear it. |
| Developer endpoint hygiene | Pinned and verified toolchains, no unvetted "coding tests" on work machines, and separation between engineering laptops and anything that can request a signature. |
Ambire's Ivo Georgiev made a related point to Cointelegraph: teams may forget to revoke a malicious delegation after regaining control. Recovery runbooks for Ethereum wallets now need a "check and clear delegation" step.
What this means for builders and projects
Few projects run billions in hot wallets, but many run bots, treasuries, relayers or payout wallets with automated signing. If your stack signs on the word of another service, ask what happens when that service lies. Review smart contracts that assume tx.origin or EOA-only callers, since EIP-7702 breaks the assumption that msg.sender == tx.origin only occurs at the top of a call. Our smart contract audit checklist covers that review. For the wallet and signing side, an outside review of policy rules, simulation and monitoring is the scope of our cybersecurity service.
For users, Binance has pledged to absorb the loss, and by its 3 November report had replenished 98% of affected assets. Withdrawals reopened in phases from 1 November, starting with Bitcoin. Users should remember that an exchange's pledge to cover losses is a company commitment rather than an insured deposit.
Sources
- TRM Labs — North Korea steals USD 6.36 billion from Binance in the largest hack in history
- Chainalysis — Binance exploit: latest findings and response
- CNBC — Binance resumes withdrawals following $6.3 billion hack, says 90% of stolen user assets are covered
- CNBC — Binance co-CEO Richard Teng says hackers used fake job interviews, AI tool to steal $6.3 billion in crypto
- Reuters via Khaleej Times — Binance resumes bitcoin, ether withdrawals after covering bulk of stolen $6.3 billion
- Cointelegraph — EIP-7702 didn't cause Binance hack, but may have amplified losses
- Ethereum Improvement Proposals — EIP-7702: Set Code for EOAs
- FBI IC3 — North Korea responsible for $1.5 billion Bybit hack (PSA, 26 Feb 2025)
- Arkham — Arkham uncovers $3.5B heist (LuBian)
- DefiLlama — Hacks database
How we research, write and fact-check: Editorial & AI policy.
Disclaimer: this article is for informational and educational purposes only and does not constitute financial, investment, legal or tax advice. Crypto-assets are volatile and high-risk: always do your own research (DYOR) and consult a qualified professional before making any decision. Not financial advice.
