What is EIP-7702? Why is it a key link in the Binance theft?

CN
链捕手
Follow
34 minutes ago

Author:Blockaid Research Team

Translation:Shenchao TechFlow

According to publicly available on-chain statistics, on October 29, 2026, hackers stole at least $6.3 billion in assets from multiple hot wallets belonging to Binance on Ethereum, Arbitrum, Avalanche, Optimism, Bitcoin, and Tron, setting a record for the highest amount involved in a theft in the history of cryptocurrency.

The primary target of the attack was Binance 14 (Ethereum address: 0x28C6c06298d514Db089934071355E5743bf21d60). This address is one of the largest core Ethereum hot wallets under Binance, with frequent on-chain interactions.

At Coordinated Universal Time (UTC) 20:24, the attackers drained approximately $2.5 billion in assets from Binance 14 in a single transaction. Just minutes before the asset heist, the attackers, holding a leaked copy of the wallet's private key, signed an EIP-7702 authorization, entrusting the hot wallet to a malicious cleaning contract that had been pre-deployed by the attackers.

Within 12 minutes of the initial funding heist, another 10 hot wallets of Binance across four public chains initiated transfers to the same aggregation address. Subsequently, the attackers further drained the smart contract custody account under Binance using the still entrusted Binance 14.

Overview of the Attack Incident

Blockaid's security detection system triggered an alarm less than two minutes after the assets were cleared, a response time far earlier than any public media or social network disclosure. The automated analysis engine subsequently confirmed the private key leak and the EIP-7702 delegated attack mechanism within 11 minutes.

Subsequently, stablecoin issuers Tether and Circle urgently froze approximately $1.8 billion in funds in the hacker's core receiving address. Tether CEO Paolo Ardoino then stated that the total amount of USDT frozen by Tether had exceeded $1.5 billion.

However, native assets like ETH, AVAX, OP, and ARB, which cannot be centrally frozen, remained firmly under the control of the attackers’ wallets.

This review report comprehensively covers the preparatory work of the attackers, EIP-7702 delegation and asset cleaning, concurrent private key signing across four public chains, money laundering paths and fund freezes, as well as Blockaid's detection and emergency response.

This report is specifically written for exchanges, custodial institutions, and financial organizations that hold and manage signed private keys on a large scale. It targets two core defense lines that determine the success or failure of such attacks: enforcing security policies before generating signatures and maintaining continuous on-chain monitoring while funds are in motion.

Background Overview: Exchange Hot Wallets, Signed Private Keys, and EIP-7702 Account Delegation Mechanism

Exchange hot wallets are online accounts used by exchanges to pay customers for withdrawals and transfer funds between their various wallets. These accounts hold large amounts of daily operational liquidity and continuously sign transactions, often initiating thousands of transfers each day.

The private keys behind these signatures are the only control barrier between massive account balances and any hacker holding a copy of the private key. Historically, these wallets have been External Owned Accounts (EOA) on Ethereum and other EVM-compatible public chains.

An EOA is a pure address account without any contract code; as long as the on-chain validation of the signature is legitimate, the funds will be unconditionally transferred, and the underlying blockchain will not perform any additional business logic verification.

The introduction of the EIP-7702 protocol allows regular EOA accounts to run smart contract code. The account only needs to sign an authorization proof for a designated contract address; once the authorization is packed into a block through a Type-4 transaction, any subsequent calls to that account will execute the corresponding logic of the smart contract and have complete control over the account's assets.

This authorization is closely tied to the account's transaction counter (Nonce). Unless the account signs and broadcasts a new authorization to replace or clear it, the delegation will remain in effect long-term.

For ordinary individual retail investors, this feature enables convenient functionalities such as batch transaction packing and Gas fee sponsorship. However, for exchange hot wallets, a single leak of a signature at the correct Nonce would hand over long-term code-level control of the account to the attacker, including every new deposit into that address.

In the first half of 2026, Blockaid had already verified and confirmed four security incidents related to EIP-7702, with total losses amounting to approximately $1.08 million, each incident misusing different features of the delegation mechanism. Blockaid had explicitly warned in its "2026 First Half On-Chain Security Report" that the first loss reaching seven digits (millions of dollars) would occur by the end of this year.

The security incident faced by Binance not only confirmed this assessment but also exceeded the initial prediction by three orders of magnitude in scope.

In contrast, direct transfer attack paths are more traditional. Hackers use the stolen private keys to sign regular transfer transactions, which seem extremely routine in a hot wallet that handles thousands of withdrawals daily. Only by cross-referencing the receiving targets, individual amounts, and transfer sequences can anomalies be detected.

Ultimately, both attack paths stem from private key theft. Therefore, defenses against such risks must rely on dynamic awareness of behavioral patterns rather than solely depending on known malicious signatures or contract vulnerability characteristics.

Attack Simulation: How the Hackers Achieved Their Goals

The following timestamps are recorded in Coordinated Universal Time (UTC) on October 29, 2026. As this report is published, related on-chain activities of the incident are still evolving.

Preparation Phase: Mixing Funds and Deploying Cleaning Contracts

The hacker's operator address (0x7C8601d4645b93cea45F71e118A729332e6B5CA0) obtained initial testing funds through three withdrawals from Tornado Cash starting October 28.

On October 29, the address fully rehearsed the "authorization delegation and cleaning" process across three controlled test wallets, transferring between $2 to $6 in test funds each time.

On that day at 15:59, the hacker officially deployed the cleaning contract used for robbing Binance (address: 0x63e842B054Bd624a465454D533C33F573e9c6fAe, corresponding deployment transaction hash: 0x97408e…).

The contract was completely unverifiable as open-source, designating the hacker’s operator address as its sole authorized caller and containing a cleaning function (Sweep) that could transfer all tokens in the list as well as the native ETH in the account to a designated receiving address in one go. Additionally, the contract included a forwarding function, allowing the delegated account to call other external contracts.

Nonce Spraying Collision: 50 Authorization Signatures, One Accurate Hit

At 20:20:59, the hacker operator sent a Type-4 transaction (transaction hash: 0xad9926…) to Binance 14 (address: 0x28C6c06298d514Db089934071355E5743bf21d60).

This transaction carried 50 previously signed EIP-7702 authorization proofs from the Binance 14 private key, corresponding to continuous Nonce values from 18,914,775 to 18,914,824, each authorization entrusting the wallet to the cleaning contract deployed by the hacker.

As Binance 14 was still processing withdrawal requests from all network users at the time, the hacker couldn't precisely know the real-time Nonce at the moment of calling; hence, they adopted a spraying strategy for batch signing the Nonce range window.

Ultimately, of the 50 authorizations, 49 failed due to Nonce mismatches, but one hit accurately. While Binance's regular withdrawal transactions continued to flow from that wallet, the hacker's malicious delegation quietly took over the address.

Single Transfer of $2.5 Billion: One Transaction Clears the Core Assets of the Hot Wallet

3 minutes and 24 seconds after the delegation became effective, at 20:24:23, the hacker operator triggered a cleaning call on Binance 14 (transaction hash: 0x53bd38…).

This transaction simultaneously transferred 167,464 ETH, 1.615 billion USDT, and about 60 other tokens to a hacker aggregation address (0x5227f603C1eE34CE3C06eFe6477003BDfCCB2f8c) that had no prior historical records.

After this epic heist, the once-billion-dollar Binance 14 wallet was left with just 1 symbolic ETH. By market price estimation at the time, the total value of this single asset portfolio reached approximately $2.5 billion.

Crossing Four Public Chains: Multiple Hot Wallet Private Keys Stolen Concurrently

Just 24 seconds after the initial massive cleaning was completed, Binance 16 wallet (address: 0xDFd529…) initiated a transfer to the same aggregation address (transaction hash: 0x51f263…), totaling 28,005.6 ETH, 55.7 million USDT, 25.9 million RLUSD, 84.5 WBTC, and 5 other tokens.

In the following 12 minutes, Binance 55 wallet on Optimism transferred out 44.2 million OP; four hot wallets on Arbitrum transferred out 74.6 million ARB and 8,426 ETH; and another four hot wallets on Avalanche transferred out 1.81 million AVAX and 8.41 million USDT.

It is noteworthy that these subsequently stolen wallets did not contain any smart contract code. Each fund transfer was a regular transaction directly signed by the genuine private keys of the respective wallets, cunningly mixed with the regular flow of daily user withdrawal transactions.

Controlling Smart Accounts: Continuously Draining Subsequent Deposited Assets

At 20:41:23, the hacker operator, utilizing the still delegated Binance 14, called the Circle smart custody account Binance Hot Wallet 34 (address: 0xEe7aE8…).

The hacker drained 780 million USDC (transaction hash: 0xdc102d…) from that smart account to the hacker aggregation address, then followed up by extracting another 43 million USDC.

At 21:44, the hacker executed a second cleaning on Binance 14 (transaction hash: 0x55ba4d…), draining 200 million USDT and 13 other tokens that had been newly deposited by outside users after the first round of cleaning.

By 22:00 that day, the malicious delegation remained stubbornly on-chain; any new assets inadvertently deposited into Binance 14 could be directly cleaned away by the hacker without needing to provide a wallet signature again.

Mechanism Reflection: How EIP-7702 Enables Leaked Private Keys to Evolve into Permanent Control

Before the birth of the Ethereum EIP-7702 protocol, hot wallet private key theft often turned into a race against time for asset transfers. Hackers had to quickly sign transactions to steal money, while the exchange operational team had a chance to transfer the remaining funds by increasing Gas fees once they detected it; once the exchange rotated its business hot wallet to a new address, the old stolen private keys would become utterly worthless.

However, when the stolen private keys gained the ability to sign account abstract delegations, the offensive and defensive landscape fundamentally reversed. Just with a proof of authorization valid under a specific Nonce, Binance 14 was completely transformed into a withdrawal program owned by the attacker.

After the first cleaning took away the remaining assets at UTC 20:24, the delegation relationship continued to be active on-chain. By 21:44, without any need for Binance 14 to provide any new signatures, the hacker effortlessly took away more than $200 million in subsequently deposited assets.

At this point, even if the exchange rotated its internal business keys to new private keys, it would not be able to clear the on-chain delegation because the delegation relationship is bound to the underlying address. Only by signing a new authorization with the leaked private keys to explicitly reset the delegation target to the zero address can the hacker’s code control over the account be thoroughly released. Until then, any asset flowing into Binance 14 was readily available to the hacker.

For teams managing large EOA accounts, this incident serves as a wake-up call for crucial security measures, with specific response strategies being very clear: EIP-7702 authorizations must be treated as privileged operations governed by the same strict policy controls as cold wallet withdrawals.

Implement round-the-clock monitoring for code status changes on all hot wallet addresses and prepare pre-signed revocation transactions; avoid leaving any liquidity in the address until the safety of the delegation state is confirmed; after a private key leak incident occurs, the delegation relationship must be thoroughly cleared on-chain before rotating keys and supplementing wallets.

At the same time, when initiating any delegated transaction, the authorization list must be fully transmitted to the transaction review layer. Because if this list is stripped, a dangerous delegated transaction may appear to be a harmless blank call to a trusted address.

Incident Review and Final Conclusions

Private key leakage remains the largest source of financial loss facing the current public chain world. If the publicly available statistics are confirmed, this incident will become the largest theft disaster in cryptocurrency history, with a scale three times the losses experienced by Bybit in February 2025 (approximately $1.5 billion).

In a short time, 11 hot wallet private keys under Binance initiated transfer signatures to a hacker address that was created just a few minutes prior, with one key wallet even signing an EIP-7702 authorization, directly becoming a long-term looting tool for the hacker.

Although compliant stablecoin issuers urgently froze approximately $2.4 billion in assets within two hours of the incident, the hacker still succeeded in stealing a massive amount of Ethereum and other native assets.

From the perspective of the underlying blockchain, a legitimate signature issued by a stolen private key is indistinguishable from a normally authorized legitimate signature. In such private key attacks, the true dividing line depends on the strategy gatekeeping at the moment the signature is generated and whether it can be precisely intercepted during the golden minutes when funds just begin to flow.

免责声明:本文章仅代表作者个人观点,不代表本平台的立场和观点。本文章仅供信息分享,不构成对任何人的任何投资建议。用户与作者之间的任何争议,与本平台无关。如网页中刊载的文章或图片涉及侵权,请提供相关的权利证明和身份证明发送邮件到[email protected],本平台相关工作人员将会进行核查。

Share To
APP

X

Telegram

Facebook

Reddit

CopyLink