16 mins read
Beyond EIP-7702: The Real Lessons from the $6 Billion Binance Hack
Between 20:04 and 20:35 UTC on 29 October, Binance hot wallets were drained across eight blockchains, according to one on-chain reconstruction. Estimates of the losses range from $5.3 billion to $5.8 billion, with one chain-by-chain count reaching $6.28 billion.
If confirmed, the incident would rank as the largest cryptocurrency theft on record, surpassing the $1.5 billion stolen from Bybit in February 2025. Binance has not confirmed a final loss figure. The exchange has suspended deposits and withdrawals, reported that approximately $3 billion has been frozen, and pledged to cover the losses.
Much of the attention has focused on EIP-7702, the Ethereum feature used to empty one wallet holding approximately $2.5 billion in a single transaction. But that explains only part of the incident.
The same attacker moved Bitcoin, XRP, Solana and Tron from Binance hot wallets within the same half-hour. None of those blockchains supports EIP-7702. Their outflows point to a broader compromise involving the systems or credentials used to authorise transactions across multiple chains.
For digital asset platforms, that distinction matters. A vulnerability in one blockchain feature is one problem. An attacker gaining the ability to authorise transactions across multiple hot wallets is an infrastructure security problem.
Here's what happened, how the attack unfolded, and what it reveals about wallet security and treasury controls.
What Happened in the Binance Hack
The timeline below is based on an on-chain reconstruction by Dickson, a CertiK engineer and SEAL member, with the Ethereum details cross-checked against CryptoTicker's Etherscan timeline. All times are UTC. Binance has not independently confirmed the complete sequence.
- 28 October, 07:39: The attacker's main wallet makes its first withdrawal from Tornado Cash.
- 29 October, 02:28: A sweeper contract is deployed. Test sweeps against the attacker's own wallets run from 13:51 to 16:47, and a second version of the contract goes live at 15:59.
- 20:04: The first XRP outflow occurs. Four more Binance XRP wallets are drained by 20:09.
- 20:10 to 20:22: Outflows occur on Solana, Optimism, Bitcoin (18,270 BTC, split into 1,000 BTC chunks) and Tron.
- 20:20:59: A transaction carrying 50 EIP-7702 authorisations, signed with the key of the hot wallet Etherscan labels Binance 14, is broadcast.
- 20:24:23: A single contract call sweeps approximately $2.53 billion from Binance 14, including 167,464 ETH, 1.615 billion USDT and more than 60 other tokens. CryptoTicker puts the transaction fee at $0.93.
- 20:24:47: A second hot wallet, Binance 16, signs nine transfers to the attacker.
- 20:30 to 20:35: Outflows occur on Arbitrum and Avalanche.
- 20:41 and 20:59: Approximately $822.6 million in USDC leaves through a Binance smart wallet trusted by Binance 14.
- 21:01 and 21:04: Tether's first blacklist and Circle's freeze take effect.
- 21:44 and 22:39: Further sweeps of Binance 14 take place.
- 22:55 to 23:07: Binance moves the remaining tokens from Binance 14 into another of its wallets.
The incident also affected the wider cryptocurrency market. By late evening US time, CoinDesk reported that Bitcoin had fallen approximately 5% to just below $77,000, while BNB was down 8.2%.
Investigator ZachXBT and security firm Blockaid said North Korea was likely responsible, although attribution remains subject to further investigation.
How the Binance Hack Worked on Ethereum
EIP-7702, introduced on Ethereum with the Pectra upgrade in May 2025, allows an externally owned account (EOA), or ordinary wallet, to temporarily delegate its execution logic to a smart contract.
The wallet owner signs an authorisation specifying the contract, blockchain and current nonce. Once a transaction carrying that authorisation is included on-chain, calls to the wallet execute the delegated contract code against the wallet's own balance.
The feature was designed to support use cases such as transaction batching and sponsored gas fees. But in this incident, the same capability provided a way to empty a hot wallet through a single transaction.
Rather than signing dozens of individual transfers, Binance 14 needed only one EIP-7702 authorisation. The sweeper contract then handled the transfers, moving more than 60 different tokens in a single transaction.
The 50 authorisations are also significant. Each covered a different nonce, meaning one could remain valid regardless of the wallet's nonce when the transaction landed. Analyst Detective Pho interpreted the batch as protection against rapid revocation. Revoking a delegation requires another signed authorisation, and the attacker had already prepared several alternatives.
This may help explain why Binance 14 continued to be swept more than two hours after the initial transaction.
However, EIP-7702 does not explain how the attacker obtained the required authorisation in the first place.
An EIP-7702 authorisation must be signed using the wallet's private key. The attacker therefore either possessed the key or gained access to a system capable of producing a valid signature. Investigators are still working to establish how that access was obtained, including whether an authorised signer was deceived.
Why EIP-7702 Doesn't Explain the Rest
Bitcoin, XRP, Solana and Tron do not support EIP-7702. Transfers on these networks require their own valid transaction signatures.
If the on-chain reconstruction is accurate, the attacker obtained valid signatures for Binance hot wallets across multiple blockchains within approximately 30 minutes. EIP-7702 was used on Ethereum because it offered an efficient way to empty the largest wallet, but it cannot account for the other outflows.
This distinction narrows the possible explanations.
Compromising one Ethereum wallet key would not, by itself, explain simultaneous withdrawals across multiple networks. The attacker may have obtained multiple hot wallet keys, access to the seed material from which those keys were derived, or control over a signing system capable of authorising transactions across chains.
The common point is the infrastructure responsible for holding keys and authorising transactions.
EIP-7702 provided the mechanism for the Ethereum sweep. The broader question is how the attacker gained the ability to initiate transactions across Binance's hot wallet infrastructure.
Some analysts have also cautioned that the larger loss estimates may include unrelated transfers. Binance's eventual post-mortem should help clarify the scale of the incident and the method of compromise.
What the Binance Hack Says About Hot Wallet Security
The incident highlights several areas of wallet infrastructure that digital asset platforms should examine. These extend beyond private key protection to include transaction authorisation, balance exposure, fund movement and incident response.
1. Treat Delegation as a Withdrawal
A hot wallet designed to process customer withdrawals has little operational reason to sign an EIP-7702 authorisation.
A signing policy that explicitly rejects unnecessary delegation authorisations can close this particular attack path. However, that safeguard does not protect against an attacker who already possesses the raw private key and can sign transactions independently.
The distinction is important. Security controls must account for both the protection of private keys and the transactions that authorised systems are permitted to execute.
The Bybit incident in February 2025 demonstrated how attackers could manipulate what signers saw through the Safe{Wallet} interface. NCC Group's technical analysis details how the attack altered the transaction approval process.
For digital asset platforms, this reinforces the need for transaction policies that evaluate more than transaction fees or basic approval requirements. Signing systems should assess transaction type, value, destination and other relevant risk conditions before authorisation.
2. Limit the Amount One Hot Wallet Can Move
CoinDesk, citing DefiLlama, estimated the stolen amount at approximately 4% of Binance's $144 billion in holdings.
The aggregate hot and cold wallet allocation may have limited the overall exposure. But the concentration of funds in a single address created a significant point of failure: Binance 14 held approximately $2.53 billion, and one authorisation enabled the attacker to move it.
The amount a platform can lose in a hot wallet compromise is determined partly by decisions made long before an attack occurs. These include how much value remains online, how funds are distributed across addresses and how much each signing key can authorise.
Platforms should consider distributing hot wallet balances across multiple addresses, with independent keys and transaction limits. This reduces the amount exposed to any single compromised wallet.
The objective is not simply to maintain a favourable hot-to-cold wallet ratio. It is to limit the amount any individual key or signing event can put at risk.
We explore this further in our guide to how exchanges decide what to keep in hot wallets.
3. Account for the Limits of Asset Freezes
Tether, Circle, Ripple, World Liberty Financial and the Arbitrum Security Council froze assets within hours of the incident.
Dickson's on-chain count puts frozen funds at approximately $2.8 billion, with about $3.27 billion remaining beyond reach. These included 18,270 BTC, 458,770 ETH, 233.5 million XRP, 684.6 million TRX and 970,500 SOL.
Stablecoins issued by centralised entities can be frozen by their issuers under certain circumstances. Native cryptocurrencies do not have an equivalent issuer-controlled mechanism.
The distinction has direct implications for treasury risk management. The composition of a hot wallet affects not only how much value is exposed but also how much may be recoverable following a compromise.
Platforms should account for these differences when determining which assets remain in online wallets and how frequently funds are moved into cold storage.
4. Automate the Response to a Suspected Compromise
The on-chain timeline raises another important question: how quickly can a platform isolate and empty a compromised hot wallet?
Analyst Spreek flagged the outflows on X at 20:32, eight minutes after the major Ethereum sweep. Binance issued its first statement at 21:24. Further sweeps of Binance 14 occurred at 21:44 and 22:39, while Binance moved the remaining tokens out only between 22:55 and 23:07.
The sequence suggests that the attacker retained the ability to move funds from the address for an extended period after the incident became public.
Revoking access to a compromised wallet may take time, particularly when multiple keys, networks and approval systems are involved. Platforms therefore need a predefined incident response process that can isolate affected wallets and move remaining funds to secure addresses without relying on improvised manual intervention.
These procedures should be tested in advance, with clear escalation responsibilities and predefined destination wallets.
How CoinsDo Helps Platforms Implement Wallet Controls
The Binance incident highlights an important distinction in digital asset security: protecting private keys is only one part of controlling wallet risk.
Platforms also need to determine how much value each wallet holds, who can authorise transactions, what approval conditions apply and how quickly funds can be moved when a wallet needs to be isolated.
CoinsDo provides wallet infrastructure designed to help digital asset platforms manage these operational requirements.
CoinSend: Structured Withdrawal Authorisation
CoinSend, CoinsDo's withdrawal engine, supports configurable approval workflows with reviewer tiers, value thresholds and escalation rules for high-value withdrawals. Approval requests can also be configured to expire after a specified period.
Within CoinSend, CoinSign supports the approval and signing process using RSA and HMAC-SHA256 mechanisms. Reviewers can approve transactions through mobile devices, PCs or browser extensions, with approval records retained for subsequent review.
These controls help platforms establish clearer transaction authorisation procedures, define approval responsibilities and maintain an auditable record of withdrawal activity.
For platforms looking to formalise their approval structures, we explain the process in our guide to structuring tiered approval workflows.
CoinGet: Automated Fund Collection and Movement
CoinGet, CoinsDo's deposit engine, automates fund collection from deposit addresses based on configurable time, balance or custom rules.
Collected funds can be routed to designated wallets, including cold storage, according to the platform's configured collection strategy.
This helps platforms manage the amount of value accumulating in individual deposit addresses and reduce reliance on manual fund transfers.
Client-Controlled Wallet Infrastructure
CoinsDo does not hold customer private keys. Its wallet runs client-side on the customer's Android device, PC or cloud server, rather than pooling customer funds within a CoinsDo-controlled wallet.
This architecture gives customers control over their own private keys and wallet operations. However, responsibility for securing the underlying devices, environments and signing infrastructure remains with the customer.
Understanding the relationship between seed phrases and private keys is an important part of that responsibility. We explain the distinction in our guide to seed phrases vs. private keys.
Building More Resilient Digital Asset Wallet Infrastructure
Binance has said it will cover the losses from the incident. Most digital asset platforms would not have the same financial capacity.
The more important question for operators is what a compromised signing credential could authorise, how much value it could move and how quickly the platform could respond.
The Binance incident demonstrates why wallet security cannot rely on private key protection alone. Transaction authorisation, wallet balance limits, automated fund movement and incident response all play a role in managing exposure.
CoinsDo's Wallet-as-a-Service infrastructure combines withdrawal approval workflows, automated fund collection and client-controlled wallet architecture to help digital asset platforms manage these operational requirements.
