Binance's Ethereum hot wallets drained: the attacker held Binance 14's EIP-7702 authorisation signatures, and three minutes later swept 167k ETH and 1.8B USDT

This is an on-chain account of a breaking incident, and the story is still developing. We only write two kinds of things: facts that can be checked directly on Ethereum (with transaction hashes), and public statements by the parties involved (with attribution). Figures circulating in the media and on social platforms vary widely (from $2.8B to $5.7B); we do not present unverified numbers as facts. All times are UTC (UK winter time equals UTC).

The short version

1. The attacker used EIP-7702 to turn Binance’s hot wallet into their own contract. At 20:20:59 UTC, address 0x7c86…5ca0 sent an EIP-7702 (type 4) transaction delegating the hot wallet Etherscan labels Binance 14, 0x28c6…1d60, to contract 0x63e8…6fae. Reading Binance 14’s account code now returns 0xef0100 plus that contract’s address: it is still delegated.

2. Three minutes later, one transaction emptied Binance 14. At 20:24:23 the same address called Binance 14, and a single transaction moved 167,464 ETH (about $377M) and 63 tokens to 0x5227…2f8c. Binance 14’s ETH balance went from 167,445 at 20:22 to 1. By 21:44 that address had received 1.82B USDT from Binance 14. At 20:41 the attacker went through Binance 14 again to move 823M USDC out of Hot Wallet 34.

3. The authorisation signatures came from Binance 14 itself. An EIP-7702 authorisation must be signed with the delegating wallet’s key. We recovered the signers of all 50 authorisations in that transaction: every one is Binance 14, covering 50 consecutive nonces (18914775–18914824). The attacker held valid signatures from Binance 14.

4. Most stablecoins were frozen; ETH was not. Tether began blacklisting attacker addresses at 21:01, and CEO Paolo Ardoino says more than 1.567B USDT is frozen; Circle blacklisted at 21:04, and CEO Jeremy Allaire says more than 800M USDC is frozen; World Liberty says it froze $27M of USD1, and Ripple says it is freezing RLUSD. No issuer can freeze ETH, wBETH or most other tokens.

What happened: timeline

How the attack worked

What EIP-7702 is. Added in Ethereum’s Pectra upgrade in May 2025, it lets an ordinary wallet (EOA) sign an “authorisation” that delegates its account code to a contract. After that, anyone calling the wallet runs that contract’s code. The intended use is batching, sponsored gas and similar features for ordinary wallets.

How it was used here. The attacker prepared sweeper contract 0x63e8…6fae, packed authorisations signed by Binance 14 into a type-4 transaction and sent it. Once on-chain, Binance 14 became “an account that runs 0x63e8’s code”. Calling it then made that code send all the wallet’s ETH and tokens to the attacker, without touching Binance 14’s normal transaction flow.

The key on-chain fact: the signatures came from Binance 14. The signer of an EIP-7702 authorisation can be recovered from the signature. The transaction carried 50 authorisations pointing to the same contract, and all of them recover to Binance 14. So this is not a bug in Ethereum or a smart contract: the attacker had valid authorisation signatures from Binance 14.

Why 50. Each authorisation is bound to the wallet’s nonce (its transaction counter) at the time. A Binance hot wallet sends withdrawals every minute, so its nonce keeps climbing and nobody can know in advance what it will be when a transaction lands. The attacker therefore brought signatures for 50 consecutive nonces, 18914775 to 18914824, to make sure one would match.

That points to an inference worth flagging: an attacker holding Binance 14’s private key would only need to read the nonce and sign once, not prepare 50 in advance. Having 50 consecutive nonces signed looks more like being able to get Binance’s signing system to produce signatures in bulk: a compromised signing service, a tricked approval, or misused internal access. This is an inference from on-chain data; Binance has not disclosed the cause.

Not yet established: the 823M USDC left Hot Wallet 34, but the attacker called Binance 14. What authority Binance 14 had over Hot Wallet 34 is still unclear to us.

What was taken, and what was frozen

Main assets the attacker’s address 0x5227…2f8c (Etherscan: Binance Hot Wallet Exploiter 2) received from Binance 14, at Etherscan’s page prices:

The main items add up to about $3.4B. The issuers’ freeze statements add up to about $2.4B. What is visible on-chain now: about 1.38B USDT and 825M USDC sit frozen in blacklisted addresses; the attacker also sent 500M and 200M USDT to two downstream addresses that were blacklisted at 21:01 but now hold nothing, so where that went is still being traced. Tether’s figure (1.567B) is higher than what is visible on-chain, so the difference may be in addresses we have not found yet. ETH and most other tokens were not frozen, about $600–700M at page prices, roughly in line with CZ’s remark that the loss “might be a bit higher” than about $1B.

Where the ETH went (updated 00:40 UTC). We followed the verified attacker addresses six hops down:

• Binance 14 was not the only wallet that paid out. At 20:24:47 Binance 16 (0xdfd5…) sent 28,005.6 ETH and 55.74M USDT to the attacker’s main address in an ordinary transaction of its own, and Binance 14 sent a further 1,699.9 and 369.8 ETH at 21:04 and 21:44. In all, the main address received about 197.5k ETH. Why Binance 16 sent funds itself cannot be seen on-chain, and Binance has not explained it.
• At 20:38:47 the main address moved 195,460 ETH in one transfer to a fresh address, 0x8532…43d4. It has not moved since.
• Before the freezes, the attacker sent 500M and 200M USDT to two downstream addresses and swapped them into ETH through Uniswap and others; 0xc887…286a now holds about 122k ETH. On the RLUSD side, 88.54M reached 0xe702…958d after three hops; about 47.5M of it was sent on before any freeze (15.3M straight into Uniswap V4) and about 40.54M is still there. That address then sent 26,825 ETH to 0x5440…c942. Roughly $60M of USDT was deposited into Aave.
• Altogether the attacker side now holds about 360k ETH, roughly $790M, across 17 addresses, and no issuer can freeze it. That is more than the $600–700M implied by the stolen ETH alone, because some of the stablecoins were swapped into ETH before they could be frozen.

Our tracker recomputes these figures every 10 minutes; see the live tracking panel and fund graph at the top of this page. The attacker’s address also sent many zero-value and dust transfers to look-alike addresses that share their first and last characters with real ones: that is address poisoning, not a real flow of funds.

What the parties say

• Binance (official X): aware of reports of a potential security issue and actively investigating; user funds are completely safe; updates will come through official channels once verified; users should beware of scams and ignore unofficial links and requests for account information. Later: security checks under way, and withdrawals will resume as soon as the issue is fully resolved.
• CZ (X): “It does look like a hack on Binance”; user funds are safe; the loss “might be a bit higher than that [about $1B], but will cover”. He also noted he no longer manages Binance.com.
• Tether: CEO Paolo Ardoino says more than 1.567B USDT is frozen (CZ earlier cited about $971M).
• Circle: CEO Jeremy Allaire says it froze more than 800M USDC in coordination with law enforcement.
• World Liberty (USD1): Zach Witkoff says $27M of USD1 is frozen.
• Ripple: Jack McDonald says it is freezing the attackers’ RLUSD.
• Withdrawals: several outlets report some networks have reopened and others remain paused; Binance has not published a full list. Rely on Binance’s official channels.

What ordinary users should watch for

• Rely on Binance’s official channels: in-app announcements and its official X account. Phishing peaks during incidents like this: ignore any DM, group message, “compensation claim” link, or request for account details or a seed phrase.
• While withdrawals are paused, do not trust offers of “proxy withdrawals” or “internal channels”.
• This was an attack on an exchange’s hot wallet, not a flaw in Ethereum or EIP-7702 itself. But EIP-7702 raises the stakes of signing an authorisation: sign a malicious one and someone else’s contract takes over your wallet. If a signature request is unclear, do not sign it.

This page states facts and on-chain data only; it is not investment advice.

Other security news the same night

Two other security items spread on social platforms the same day: Polymarket users reported that its front end might be injecting malicious transactions, and Singapore police said Ledger’s supply chain in Singapore was affected. There is no evidence so far linking either to the Binance incident; we note them only as a caution.

Update log

• 30 Oct, 00:45 UTC: added where the ETH went (Binance 16 also sent funds out, 195,460 ETH parked untouched at 0x8532…43d4, USDT and part of the RLUSD moved and swapped into ETH before the freezes, about 360k ETH now on the attacker side); Binance 14’s delegation cleared; Circle blacklisted Binance 14 and Hot Wallet 34; added live tracking and a fund graph that refresh every 10 minutes.
• 30 Oct, 00:30 UTC: first version. Verified on-chain: the delegation transaction, the signers of all 50 authorisations, Binance 14’s balance change, the main outflows and the USDT/USDC blacklist events; summarised public statements by Binance, Tether, Circle, World Liberty and Ripple.

On-chain evidence

• Binance 14: 0x28c6c06298d514db089934071355e5743bf21d60 (current account code 0xef0100 + 63e842b054bd624a465454d533c33f573e9c6fae)
• Hot Wallet 34: 0xee7ae85f2fe2239e27d9c1e23fffe168d63b4055
• Attack sender: 0x7c8601d4645b93cea45f71e118a729332e6b5ca0 (Etherscan: Binance Hot Wallet Exploiter)
• Attacker main address: 0x5227f603c1ee34ce3c06efe6477003bdfccb2f8c (Etherscan: Binance Hot Wallet Exploiter 2)
• Delegate contract: 0x63e842b054bd624a465454d533c33f573e9c6fae
• Delegation tx: 0xad99264d5532ae0dd04b2004eebda05f25657e70dacb764f7ac8d4ccd051298b
• First sweep: 0x53bd38b816c23e74134786c29a8c18d792777998a3b9326047b583100e88e2f3
• USDC transfer: 0xdc102dd89dded5a83f1008906883ffb7c81ff3b7d7965d8c7277d170b5e17481

This is an analysis of public data, not investment advice. The story is developing; the latest update takes precedence.