On October 29, 2026, attackers pulled an estimated $6.3 billion out of Binance-linked hot wallets, the largest cryptocurrency theft on record. The number is easy to fixate on, but the mechanics matter more. Nobody extracted private keys from a hardware security module, and no executive was phished for credentials. The attackers exploited something quieter: exchanges treat protecting a key and controlling what that key may sign as the same problem, and they are not. Ethereum’s Pectra upgrade made the gap much more dangerous.
What happened in the Binance breach
TRM Labs and other blockchain intelligence firms traced roughly $6.36 billion leaving Binance-attributed wallets across ten blockchain networks within a few hours. The drains hit Ethereum, Bitcoin, the XRP Ledger, Tron, Solana and several Layer-2 ecosystems at once. Coordination like that points to a failure in a centralized orchestration layer, not a string of separate network-specific exploits.
Binance suspended deposits and withdrawals, revoked the affected authorizations and worked with partners to freeze assets. It has also committed to covering user losses through its Secure Asset Fund for Users (SAFU). That makes users whole financially, but it leaves open the harder question of how an attacker got the operational leverage to move this much liquidity.
How attackers abused EIP-7702 on Ethereum
The Ethereum leg of the attack is the most instructive. Investigators found that the attackers had weaponized EIP-7702, a feature introduced in the Pectra upgrade.
What EIP-7702 does
EIP-7702 narrows the gap between Externally Owned Accounts (EOAs) and smart contracts. It adds a transaction type, 0x04, that lets an EOA temporarily delegate its execution to an existing smart contract. It does this by writing a delegation indicator into the EOA’s code field: the bytes 0xef0100 followed by a 20-byte target address. The Ethereum Virtual Machine (EVM) then runs the referenced contract’s logic in the context of the delegating account’s assets and state. Used as intended, this gives users batched transactions and session keys without forcing them onto full smart contract wallets.
The 50-authorization nonce trick
According to analyses from LlamaRisk and TRM Labs, the attacker submitted a transaction carrying 50 EIP-7702 authorizations. They targeted a consecutive range of nonces on a primary Binance hot wallet known as “Binance 14.” That wallet’s nonce kept advancing as it handled routine exchange operations. By preparing signatures for a spread of possible nonce values, the attacker made sure at least one would match the account’s state when the transaction executed.
ECDSA was not broken. The attacker still needed a valid signature for the authorization that was finally applied. Binance’s preliminary findings say there was no evidence of a wallet private key leak. The most consistent reading is that a compromised internal signing interface was manipulated into signing a malicious delegation request.
The sweeper contract and persistent delegation
Once the authorization was accepted and the delegation indicator was written, the attacker’s smart contract controlled the account. That contract worked as a sweeper. It moved about 167,464 ETH and dozens of ERC-20 tokens to attacker-controlled addresses. The EVM does not judge intent or check whether a contract’s source is verified. It runs whatever bytecode the delegation points to.
There is a further catch. A delegation stays in place until someone applies an authorization that targets the zero address. So even after the initial drain, the hot wallet stayed compromised and would have been exposed again if more assets arrived before Binance cleared the authorization state.
Key security vs signing authority: the gap that made this possible
Binance’s early investigation points to a compromised DevOps engineer’s laptop as the initial access vector. From there, the attacker reached a service container and submitted unauthorized withdrawal transactions.
📬 Stay Ahead of Cyber Threats
Get the latest cybersecurity news, critical vulnerabilities, threat intelligence, tutorials, and exclusive giveaways delivered straight to your inbox. No spam. Unsubscribe anytime.
Subscribe to the Newsletter →This is the core custody problem. HSMs and secure enclaves are excellent at key security. They keep the secret material that produces signatures inside a protected boundary. They have no view into signing authority, meaning the policy decision about what a key is allowed to sign. If a compromised internal service can hand a malicious EIP-7702 authorization to an HSM, and the policy engine around it does not recognize the danger, the key signs its own downfall.
Why traditional withdrawal controls miss EIP-7702 attacks
Most withdrawal controls and policy engines judge transactions by economic properties: withdrawal limits, destination allowlists, asset types and balances. An EIP-7702 set-code transaction slips past all of that. It does not tell the wallet to send a fixed amount of ETH or USDT anywhere. It tells the wallet to change how it executes. To a simple policy engine, the outer transaction may look nearly worthless and never trigger a high-value escalation.
Defenders have to evaluate the semantic effect of an operation. For an EIP-7702 request, that means identifying the delegation target, validating the chain scope and deciding whether that contract may control the account’s execution context at all. A delegation change deserves the same scrutiny as a multi-million dollar outbound transfer, and arguably more. After Pectra, it is a baseline requirement.
A multi-chain blast radius: the orchestration layer problem
EIP-7702 explains the Ethereum drain, but it cannot explain the simultaneous outflows on Bitcoin, Solana, Tron and the XRP Ledger. Those networks use different transaction formats, scripting languages and authorization models. The most plausible hypothesis is that the attacker reached a shared orchestration layer or operational environment that coordinates withdrawals across the exchange’s whole multi-chain portfolio.
Centralized orchestration is efficient, and it is also a single point of failure. If a compromised service container holds the credentials and network permissions to send signing requests to every chain-specific signer, least privilege has already failed. Each signing system needs its own security boundary, so that compromising the orchestration layer does not automatically grant unrestricted withdrawals on every supported network.
Stablecoin freezes and DeFi laundering after the hack
Once outflows were detected, the industry moved to trace and contain the funds. Tether, Circle and Ripple used their contract-level administrative functions to freeze about $2.7 billion in assets linked to the suspected attacker’s wallets. Centrally issued stablecoins carry issuer-controlled blacklist capabilities that Bitcoin and Ether do not have. A freeze is not a recovery, though. It limits the attacker’s ability to cash out through compliant centralized exchanges and sets up a long legal and administrative process.
The attacker also used DeFi to obscure the trail. LlamaRisk’s assessment is that a wallet tied to the attacker supplied roughly $60 million in stolen USDT as collateral on Aave V3 and borrowed about 19,762 WETH against it. No Aave contract was exploited here. The attacker used the protocol’s overcollateralized lending as designed. Turning stablecoins into wrapped Ether through a collateralized debt position layered the funds and made on-chain tracing harder. Aave froze markets as a precaution, which shows how large injections of illicit liquidity can strain DeFi protocols even when their code behaves correctly.
Who is behind it: TraderTraitor and the Lazarus Group
TRM Labs attributes the incident with high confidence to TraderTraitor, a North Korean state-sponsored actor closely linked to the Lazarus Group. The assessment rests on preparation activity, including deployment and testing of malicious contracts and the use of pre-signed authorizations. It also cites laundering behavior that resembles earlier operations, such as the Bybit theft in early 2025.
Public blockchains show where funds move but not who is typing. Attribution from intelligence firms is an informed assessment, not an adjudicated fact. Still, if a state-sponsored actor is involved, major exchanges are up against heavily resourced geopolitical adversaries and not just opportunistic hackers.
How exchanges should redesign crypto custody after Pectra
Containment, asset freezes and SAFU reimbursement come first. A rigorous and transparent technical post-mortem has to follow. Exchanges should design their signing architecture on the assumption that internal networks and developer endpoints will eventually be compromised. In practice that calls for:
- Decentralized signing policies, so no single application or service container can start high-value transactions or change account execution state across multiple chains on its own.
- Multi-party approval for high-value operations and semantic state changes such as EIP-7702 delegations.
- Strict destination allowlists.
- Independent policy checks that run entirely outside the potentially compromised orchestration layer.
signing authority matters as much as the private key
The Binance breach shows that the authority to sign matters as much as the secrecy of the key. Protocol features like EIP-7702 improve user experience and account flexibility, and custodial systems holding billions of dollars have to keep pace with them. The security boundary can no longer stop at the private key. It has to cover what each transaction means, which includes checking whether the signature is mathematically valid and also what the signed operation intends to do. Until exchanges give signing authority the same controls they give key material, new protocol features will keep creating new ways in.
