What to Know
- An attacker used Ethereum’s EIP-7702 feature to drain about $2.5 billion from a Binance wallet in less than four minutes on Thursday.
- The feature went live in May 2025 as part of Ethereum’s Pectra upgrade and allows ordinary wallets to run smart-contract code after signing an authorization.
- The attacker’s transaction carried 50 authorizations signed by the wallet labeled Binance 14, with one accepted by the network.
- The malicious delegation remained active for nearly four hours, allowing further sweeps as customer deposits continued arriving.
- Binance said losses across several blockchains totaled $6.3 billion and pledged to cover them using its SAFU emergency fund and company funds.
- Investigators continue examining how the attacker obtained valid signatures from Binance-controlled wallets across Ethereum and other networks.
- Binance said about $3 billion of the affected assets had been frozen as of Friday.
Ethereum Upgrade Becomes a Key Part of Binance Breach
A major Binance wallet breach has put renewed scrutiny on Ethereum’s EIP-7702 feature after an attacker used the mechanism to turn an ordinary exchange wallet into a vehicle for malicious smart-contract execution. The Ethereum portion of the incident involved about $2.5 billion in ether and tokens moving out of a Binance wallet in less than four minutes on Thursday, forming a large part of the broader $6.3 billion in losses that Binance said occurred across several blockchains.
The affected Ethereum wallet, labeled Binance 14 by Etherscan, signed a permission that allowed an attacker-controlled contract to operate it. Once the authorization was accepted by the network, the wallet effectively ran the attacker’s code as though that code belonged to the wallet itself. That shift was central to the Ethereum attack path because it allowed the attacker to sweep assets from the wallet and later capture additional deposits routed into it.
EIP-7702 was introduced in May 2025 as part of Ethereum’s Pectra upgrade. It was designed to make ordinary wallets more flexible by allowing them to temporarily behave like smart-contract accounts. In legitimate use, that can enable features such as batched payments and fee sponsorship, where another party can pay transaction costs. In this case, the same functionality appears to have been used against one of the largest crypto exchanges in the market.
How EIP-7702 Changed the Wallet’s Behavior
Most ordinary Ethereum wallets are controlled by a private key. The key signs transactions, and the wallet sends them. Such wallets do not normally enforce their own programmable rules, such as daily spending caps or lists of approved recipients. By contrast, smart-contract wallets can run code and apply custom conditions before funds move.
EIP-7702 bridges that gap by letting an ordinary wallet sign an authorization pointing to a smart contract. Once that authorization is submitted and accepted onchain, the ordinary wallet can run the referenced contract code as if it were its own. Importantly, anyone can submit the signed authorization to the network, and the delegation remains in place until a replacement or cancellation is recorded onchain.
That persistence is what made the Binance 14 incident especially damaging. The malicious authorization did not simply enable one isolated transfer. It allowed the attacker’s code to keep operating through the wallet while the delegation remained active. As customer deposits continued to flow into Binance 14, the attacker was able to sweep additional funds before the permission was revoked.
Within weeks of EIP-7702’s launch, market maker Wintermute had found that many delegations pointed to copy-pasted sweeper scripts. Such scripts are designed to automatically forward a wallet’s funds to a thief once a key or authorization path has been compromised. Thursday’s incident showed how the same pattern can scale dramatically when applied to an exchange hot wallet holding large balances and processing frequent withdrawals.
The Blockchain Trail Behind the Ethereum Drain
The attacker’s main wallet, identified as 0x7C86…5CA0, was funded through Tornado Cash in small withdrawals starting Wednesday. On Thursday afternoon UTC, the attacker rehearsed the approach on wallets under their own control. At about 16:00 UTC, they deployed a sweeper contract identified as 0x63e8…6fAe. The contract’s code only allowed the attacker’s wallet to operate it.
At 20:20:59 UTC, the attacker sent a transaction carrying 50 authorizations. Each authorization was signed by Binance 14, and each pointed Binance 14 toward the attacker’s sweeper contract. This mattered because Binance 14 was actively processing many withdrawals, and its transaction counter, known as a nonce, was changing quickly.
Ethereum accounts use nonces to order transactions and prevent replay. Each signed authorization had to match the account’s current counter at the moment the network processed it. To increase the odds that one permission would land correctly, the attacker prepared 50 authorizations covering consecutive nonce values from 18,914,775 to 18,914,824. The network accepted the authorization numbered 18,914,809 and ignored the other 49. Five transactions earlier in that Ethereum block, Binance 14 had sent transaction number 18,914,808, making 18,914,809 the next valid number.
The accepted authorization indicates that someone had obtained valid Binance 14 signatures across a sequence of possible transaction counters. That detail has become a central question for investigators because the authorization was not a generic instruction. It was a signed permission allowing the wallet to run attacker-controlled code at a specific nonce value.
Funds Moved in Minutes, Then Again as Deposits Arrived
At 20:24:23 UTC, the attacker called the sweeper through Binance 14. In a single transaction, the contract moved about 167,464 ETH and 63 tokens, including roughly 1.6 billion USDT, to the attacker. The initial sweep occurred less than four minutes after the malicious authorization was submitted.
The incident did not end with the first transaction. Binance systems continued routing customer deposits into Binance 14 while the wallet remained under the malicious delegation. The attacker swept incoming funds again at 21:04 and 21:44 UTC. This shows why EIP-7702 permissions can be dangerous when a malicious delegation is active on a wallet that continues receiving assets.
The attacker also used Binance 14’s borrowed code to issue instructions to a separate Binance smart wallet, Hot Wallet 34. That move pulled 823 million USDC out of the wallet, according to TRM Labs. Binance 14 remained under the attacker’s delegation for nearly four hours, until the permission was revoked at 00:10:35 UTC Friday.
Broader Cross-Chain Losses Raise Signature Questions
The Ethereum exploit was only one component of a wider incident. The attacker also moved 18,270 bitcoin, hundreds of millions of XRP, and funds on Solana, Tron and other networks. Those blockchains do not use EIP-7702, and the stolen assets on those networks left Binance-controlled wallets through ordinary signed transfers, according to TRM Labs.
The common factor across the wider breach is that transactions carried valid signatures from Binance-controlled wallets. How the attacker obtained the authority to produce those signatures remains under investigation. That question is especially important because the activity stretched across multiple networks with different transaction formats, security assumptions and wallet architectures.
Binance co-CEO Richard Teng said Friday that preliminary findings pointed to a compromised DevOps engineer’s laptop, which may have allowed the attacker to access a service container and submit unauthorized withdrawals. Teng said the attacker did not simply use one engineer’s permissions and that the incident was not a single one-click action. He described a more complex attack process and said the investigation had not attributed responsibility to any individual. He also said there was no evidence that wallet private keys leaked.
Binance later said investigators had uncovered additional points of breach beyond the laptop initially suspected. The exchange did not identify those entry points or explain how the attacker obtained the signatures needed to authorize transfers across its wallets. One possibility under discussion among security specialists is that the attacker may have induced Binance’s own signing infrastructure to produce the authorizations. Binance has not published the full attack path.
Why the Permission Structure Matters
An EIP-7702 authorization specifies what code an account will run. It does not need to specify a single payment recipient or a fixed spending amount. That makes the permission powerful: approving malicious code can expose not only a wallet’s current balance, but also assets deposited later while the delegation remains active.
For exchanges, the risk is magnified because hot wallets are operational accounts that often process high transaction volumes and receive continuous deposits. In the Binance 14 case, the wallet’s high activity also explains why the attacker prepared multiple authorizations over consecutive nonce values. The strategy gave the malicious transaction room to land even as the wallet’s counter kept advancing.
The incident is likely to intensify debate over wallet authorization design, signing infrastructure controls and monitoring for unusual delegations. EIP-7702 can support useful account features, but the Binance breach highlights how any mechanism that lets an ordinary wallet execute external code demands strict safeguards, rapid revocation capabilities and real-time detection when high-value accounts delegate control.
Binance has said it will cover losses using the SAFU emergency fund and company funds. The exchange also said about $3 billion of the affected assets had been frozen as of Friday. Even with recoveries and coverage commitments, the attack underscores a difficult reality for large custodial platforms: a valid signature can be enough to move assets, even when the surrounding circumstances suggest a deeply unauthorized action.
Frequently Asked Questions (FAQs)
What happened to the Binance wallet on Ethereum?
An attacker used Ethereum’s EIP-7702 feature to make the Binance 14 wallet run malicious smart-contract code. The wallet then moved about $2.5 billion in ether and tokens to the attacker in less than four minutes.
What is EIP-7702?
EIP-7702 is an Ethereum feature that allows an ordinary wallet to run smart-contract code after signing an authorization. It went live in May 2025 as part of Ethereum’s Pectra upgrade.
Why was EIP-7702 important in this attack?
The feature allowed Binance 14 to delegate execution to an attacker-controlled sweeper contract. Once the authorization was accepted, the wallet could run the attacker’s code as if it were its own.
How many authorizations were used?
The attacker’s transaction carried 50 authorizations signed by Binance 14. Ethereum accepted the one matching nonce 18,914,809 and ignored the other 49.
How long did the malicious delegation stay active?
The malicious delegation remained active for nearly four hours. Binance 14 revoked the permission at 00:10:35 UTC Friday.
Were other blockchains affected?
Yes. Binance said the broader losses across several blockchains totaled $6.3 billion. The attacker also moved 18,270 bitcoin, hundreds of millions of XRP, and funds on Solana, Tron and other networks.
Did Binance say private keys were leaked?
Binance co-CEO Richard Teng said there was no evidence that wallet private keys leaked. The investigation is still examining how valid signatures were obtained and how unauthorized withdrawals were submitted.
Will Binance cover the losses?
Binance said it would cover all losses using its SAFU emergency fund and company funds. The exchange also said about $3 billion of the affected assets had been frozen as of Friday.
