Binance Hack 2026: How EIP-7702 Turned a Hot Wallet into the Attacker's Contract

Reading time: ~8 min

On October 29, 2026, Binance lost about $6.3 billion from its hot wallets. That is four times the 2025 Bybit theft. There was no smart contract bug. No cryptography was broken. The attacker got into Binance's infrastructure, got a Binance wallet to sign an EIP-7702 authorization, and used it to turn that wallet into a contract the attacker controlled. You will learn:

• How the attack unfolded, step by step.
• What EIP-7702 is and why one signature can rewrite a wallet.
• The 50-nonce trick the attacker used.
• Why withdrawal controls did not catch it.
• What exchanges, custodians, and protocols should check from now on.

If you build wallets or signing infrastructure, this case shows that signing is no longer just "moving funds". If you research security, this is the new pattern to look for in every signing pipeline.

Incident Summary

What EIP-7702 Is

EIP-7702 shipped with Ethereum's Pectra upgrade. It lets a regular account (EOA) adopt a contract's code without changing its address.

1. The account owner signs an authorization: "my account now runs the code of contract X".
2. The authorization includes the chainId, the contract address, and the account's nonce.
3. It is sent inside a type 0x04 transaction.
4. Once processed, the account's code becomes a delegation indicator: 0xef0100 + the contract address.
5. From then on, any call to the account runs X's code, with the account's funds.

Before                                  After
-------------------------------------   -------------------------------------
Binance 14 (EOA)                        Binance 14
code = empty                            code = 0xef0100 || <attacker contract>
moves funds only with a signature       anyone calls sweep() and drains it

The delegation is persistent. It stays until the account signs a new authorization that replaces or clears it.

How the Attack Happened

1. Initial access. According to Binance's preliminary update, the incident "may involve" a compromised DevOps engineer's laptop. From there, the attacker reached a service container and could submit unauthorized withdrawal transactions. Binance says it found no evidence of a private key leak.
2. Preparation. Hours earlier, the attacker funded an operating wallet through three Tornado Cash withdrawals and deployed an unverified contract with a sweep() function. It moves all ETH and ERC-20 tokens to attacker addresses and leaves 1 ETH for gas.
3. The delegation (20:20:59 UTC). A single transaction carrying 50 EIP-7702 authorizations for Binance 14, with consecutive nonces from 18,914,775 to 18,914,824.
4. The drain (~20:24 UTC). Binance 14 was now running the attacker's code. One call to sweep() moved ~167,464 ETH, more than 1.6 billion USDT, and dozens of other tokens.
5. Other wallets and chains. Funds also left Binance 16, a USDC wallet, and networks including Bitcoin, Tron, Arbitrum, and Avalanche. Chainalysis notes that some of these outflows look like ordinary signed transfers, not delegation.
6. Laundering. The attacker moved $500M in stablecoins to a swap wallet and converted $325M into $285M of ETH in nearly 20 minutes. Thousands of automated transactions scattered the rest.

The 50-Nonce Trick

An EIP-7702 authorization is only valid if its nonce exactly matches the account's current nonce. Binance 14 was processing withdrawals constantly, so its nonce kept moving. The attacker could not know what it would be when the transaction landed.

The answer was simple: send 50 authorizations, one for each likely nonce. Mismatched ones are skipped without reverting the transaction. Only one had to hit. It did.

authorization[0]  nonce 18,914,775   -> skipped
authorization[1]  nonce 18,914,776   -> skipped
...
authorization[k]  nonce = real nonce -> DELEGATION APPLIED
...
authorization[49] nonce 18,914,824   -> skipped

The Real Vulnerability

An EIP-7702 authorization must be signed by the key of the delegating account. A valid authorization for Binance 14 means something signed with Binance 14's key.

Binance says no keys leaked. Blockaid mentions a "stolen key". The sources have not reconciled this yet. Our reading, which is an inference and not a confirmed fact: the attacker did not need to steal the key. It was enough to get Binance's own signing system to sign on the attacker's behalf from the compromised infrastructure.

Put plainly:

With EIP-7702, a signature does not just authorize a transfer. It can change what your wallet is. A signing policy that does not understand that is validating the wrong thing.

It is the same pattern as Bybit in 2025. The cryptography holds. The system that signs is fooled, or controlled.

Why Controls Did Not Stop It

Binance has not yet explained why its withdrawal limits did not stop the attack. It only said it is "improving its withdrawal systems and address controls". What we do know about how these systems usually work:

• Withdrawal limits measure transfers. A 7702 delegation moves no funds. It changes code. The drain happens afterwards, from the contract itself.
• Address allowlists check the destination. The target of the authorization is the wallet itself.
• Human review sees what the UI shows. If the tooling does not decode type 0x04 authorizations, nobody sees the permission change.

Response and Current Status

• Freezes: Tether froze more than 1,567M USDT. Circle froze more than 800M USDC. Ripple is freezing RLUSD. The Arbitrum Security Council restricted ~74.5M ARB and 8,425 ETH. The total is around $3B, per Binance.
• Binance: paused withdrawals, revoked the delegation, and expects to resume withdrawals within ~48 hours. It will cover losses with its SAFU fund and company funds. An updated Proof of Reserves and a technical post-mortem will follow.
• Attribution: Chainalysis and TRM Labs point to TraderTraitor (North Korea), based on on-chain commingling with funds from the previous month's Bitget theft.

How to Defend Against This

For exchanges, custodians, and any team running hot wallets:

1. Block EIP-7702 at the signer. If your hot wallets do not need delegation, your signing system must reject any type 0x04 transaction and any 7702 authorization.
2. Semantic policy, not just amounts. The signer must decode what each signature authorizes: transfer, approval, delegation, permission change.
3. Monitor your EOAs' code. Alert immediately if eth_getCode on a hot wallet stops being empty.
4. Automatic response. Pause withdrawals on an unexpected delegation. Here there were about 4 minutes between delegation and sweep.
5. Isolate engineering endpoints. A laptop should not have a path to a container that can request production signatures.
6. Segment funds. Less balance in hot wallets, more in cold storage with multi-party signing and out-of-band verification.

For protocol developers:

• If your contract assumes msg.sender is a "plain" EOA, revisit that assumption. With 7702, an EOA can have code.
• Checks like tx.origin == msg.sender or extcodesize == 0 no longer guarantee there is no contract.

Lessons Learned

• The attack did not exploit a smart contract bug. It exploited the signing infrastructure.
• EIP-7702 means one signature can rewrite a wallet persistently.
• Sending many authorizations with consecutive nonces defeats nonce unpredictability.
• Amount- and destination-based controls do not see permission changes.
• Monitoring your own wallets' code matters as much as monitoring their balances.
• Fast freezes by stablecoin issuers limited the damage, but they are no substitute for prevention.

Conclusion

The October 2026 Binance hack is a warning for the whole industry. The cryptography worked. The keys, according to Binance, did not leak. Still, one EIP-7702 authorization signed by the wrong system was enough to turn a hot wallet into the attacker's contract and drain it in minutes.

The final details will come with Binance's post-mortem. But the lesson is already clear: with EIP-7702, every signing system must understand what it is authorizing, not just who receives funds and how much.

---

Sources: crypto.news, Chainalysis, TRM Labs, CNBC, CoinDesk.