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

Author: Blockaid Research Team

Compiled by: Deep Tide 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 of Binance located on Ethereum, Arbitrum, Avalanche, Optimism, Bitcoin, and Tron, setting a record for the highest amount involved in a theft in cryptocurrency history.

The core target of the entire attack was Binance 14 (Ethereum address: 0x28C6c06298d514Db089934071355E5743bf21d60). This address is one of the largest and most frequently interacted core Ethereum hot wallets under Binance.

At 20:24 UTC, the attackers drained approximately $2.5 billion in assets from Binance 14 in a single transaction. Just minutes before this asset heist occurred, the attackers, holding a leaked copy of the wallet's private key, signed an EIP-7702 authorization, delegating the hot wallet to a malicious sweep contract that the attackers had deployed in advance.

Within 12 minutes after the initial fund heist was completed, 10 other hot wallets of Binance on four public chains also initiated transfers to the same aggregation address. Subsequently, the attackers further looted the smart contract custody accounts under Binance through Binance 14, which was still in a delegated takeover state.

Overview of the Attack Incident

Blockaid's security detection system triggered an alarm less than two minutes after the assets were swept, a response time far earlier than any public media or social network disclosures. Subsequently, the automated analysis engine confirmed the fact of the private key leak and the underlying EIP-7702 delegation attack mechanism within 11 minutes.

Following this, stablecoin issuers Tether and Circle urgently froze approximately $1.8 billion in funds at the hackers' core receiving address. Tether CEO Paolo Ardoino later stated that the total amount of USDT frozen by Tether had exceeded $1.5 billion.

However, the native assets stolen by the hackers, such as ETH, AVAX, OP, and ARB, which cannot be frozen by centralized entities, remain firmly under the control of the attackers' wallets.

This retrospective report comprehensively covers the attackers' preparations, EIP-7702 delegation and asset sweeping, concurrent private key signing across four public chains, money laundering paths, and fund freezing, as well as Blockaid's detection and emergency response.

This report is specifically written for exchanges, custodians, and financial institutions that hold and manage signed private keys on a large scale. It directly addresses the two core defenses that determine the life and death outcomes of such attacks: enforcing security policies before signatures are generated and conducting continuous on-chain monitoring while funds are in a liquid state.

Background: 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 different wallets. These accounts hold substantial 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 separating massive account balances from any hacker holding a copy of the private key. On Ethereum and other EVM-compatible public chains, these wallets have historically been externally owned accounts (EOA).

EOA is a pure address account without any contract code; as long as the on-chain signature is verified as valid, funds will be unconditionally transferred, and the underlying blockchain will not execute any additional business logic checks.

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

This authorization is tightly bound to the account's transaction counter (Nonce). Unless the account signs and broadcasts a new authorization to replace or clear it, this delegation relationship will remain in effect for a long time.

For ordinary individual retail investors, this feature enables convenient functions such as batch transaction packaging and gas fee sponsorship. However, for exchange hot wallets, if a signature is leaked at the correct Nonce, it will hand over long-term code-level control of the account to the attacker, including every subsequent new deposit into that address.

Blockaid had already verified and confirmed four EIP-7702 security incidents in the first half of 2026, with total losses amounting to approximately $1.08 million, each incident abusing different features of the delegation mechanism. Blockaid had explicitly warned in its "2026 On-Chain Security Report for the First Half of the Year" that the first case with losses reaching seven figures (in the millions) would appear before the end of this year.

The security incident that Binance encountered not only corroborated this assessment but also involved a scale that exceeded the initial prediction by three orders of magnitude.

In contrast, the direct transfer attack path is more traditional. The hacker, holding the stolen private key, signed a conventional transfer transaction, which appeared extremely routine in a hot wallet that processes thousands of withdrawals daily; only by cross-referencing the receiving target, single transaction amount, and transfer timing could 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 and cannot solely depend on known malicious signatures or contract vulnerability characteristics.

Attack Simulation: How the Hackers Succeeded Step by Step

The following timestamps are in Coordinated Universal Time (UTC) on October 29, 2026. At the time of this report's release, related on-chain activities of the event are still evolving.

Attack Preparation Phase: Mixing Funds and Deploying Sweep Contracts

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

On October 29, this address fully rehearsed the "authorization delegation and sweeping" process on its three controlled test wallets, transferring test funds ranging from $2 to $6 each time.

At 15:59 that day, the hacker officially deployed the sweep contract (address: 0x63e842B054Bd624a465454D533C33F573e9c6fAe, corresponding deployment transaction hash: 0x97408e…).

This contract was not open-source verified, set the hacker's operator address as its only authorized caller, and included a sweep function that could transfer all tokens in the list and the native ETH in the account to a designated receiving address in one go. Additionally, the contract had a forwarding function that allowed 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 EIP-7702 authorization proofs pre-signed by the Binance 14 private key, corresponding to consecutive Nonce values from 18,914,775 to 18,914,824, with each authorization delegating the wallet to the hacker's deployed sweep contract.

Since Binance 14 was still processing withdrawal requests from users across the network, the hacker could not precisely predict the real-time Nonce at that moment, so they adopted a spraying strategy across the batch-signed Nonce range window.

Ultimately, out of these 50 authorizations, 49 became invalid due to Nonce mismatches, but one hit accurately and became effective. While Binance's own routine withdrawal transactions were still continuously being sent from that wallet, the hacker's malicious delegation quietly took over that address.

Single Transaction Draining $2.5 Billion: One Transaction Cleared Hot Wallet Core Assets

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

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

After this epic heist was completed, the Binance 14 wallet, which once held assets worth billions of dollars, was left with only 1 symbolic ETH. Based on the market price at the time, the total value of this asset combination reached approximately $2.5 billion.

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

Just 24 seconds after the first massive sweep was completed, the 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's 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 conventional transaction directly signed by the actual private keys of each wallet, cleverly mixed in with the routine daily user withdrawal transaction flow.

Controlling Smart Accounts: Continuously Draining Subsequent Recharge Assets

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

The hacker withdrew 780 million USDC from this smart account to the hacker aggregation address (transaction hash: 0xdc102d…), and then subsequently withdrew another 43 million USDC.

At 21:44, the hacker executed a second sweep on Binance 14 (transaction hash: 0x55ba4d…), draining 200 million USDT and 13 other tokens that had been newly recharged into that address after the first sweep.

As of 22:00 on the same day, the malicious delegation still stubbornly resided on-chain, and any new assets injected into Binance 14 without detection could be directly swept away by the hacker without the need for the hacker to provide wallet signatures again.

Mechanism Reflection: How EIP-7702 Transformed Leaked Private Keys into Permanent Control

Before the birth of the Ethereum EIP-7702 protocol, the theft of hot wallet private keys often turned into a race against time for asset transfer. Hackers had to quickly sign each transfer to steal money, while the exchange's operation and maintenance team still had the opportunity to transfer the remaining funds by increasing Gas fees once they detected the theft; once the exchange rotated its business hot wallet to a brand new address, the stolen old private keys in the hacker's hands would become completely useless.

However, when the stolen private keys gained the ability to sign account abstract delegations, the offensive and defensive landscape underwent a fundamental reversal. With just a valid authorization proof under a specific Nonce, Binance 14 was completely transformed into a withdrawal program owned by the attacker.

After the first wave of sweeping at UTC 20:24 took away the existing assets, the delegation relationship continued to be mounted on-chain. By 21:44, the hacker easily swept away over $200 million in newly deposited assets without needing any new signatures from Binance 14.

At this point, even if the exchange rotated its internal business keys to brand new private keys, it could not eliminate this on-chain delegation, as the delegation relationship was bound to the underlying address. Only by using the leaked private key again to sign a new authorization, explicitly resetting the delegation target to a zero address, could the hacker's code control over the account be completely lifted. Until then, any assets flowing into Binance 14 were at the hacker's disposal at any time.

For teams managing large EOA accounts, this incident sounded a severe security alarm, and the specific response strategy was very clear: EIP-7702 authorization must be treated as a privileged operation, placed under the same strict policy control as cold wallet withdrawals.

Implement all-day monitoring of code status changes for all hot wallet addresses and prepare pre-signed revocation transactions in advance; avoid leaving any funds in that address until the delegation status is confirmed safe; after a private key leak incident occurs, the delegation relationship must be completely cleared on-chain before rotating keys and replenishing the wallet.

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 away, a dangerous delegated transaction may appear to be a harmless blank call to a trusted address.

Incident Review and Final Conclusion

The leakage of private keys remains the largest source of financial loss faced by the current public chain world. If public statistical data ultimately confirms this, this incident will become the largest theft tragedy in crypto history, with a scale more than three times that of the theft loss suffered by Bybit in February 2025 (approximately $1.5 billion).

The private keys of 11 hot wallets under Binance initiated transfer signatures to a hacker address that was created just a few minutes earlier, with one key wallet even signing an EIP-7702 authorization, directly turning itself into 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 successfully made off with a large 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 legitimate signature of normal authorization. In this type of private key attack, the real watershed depends on the strategic gatekeeping at the moment the signature is generated, and whether it can be accurately intercepted during the golden minutes when funds are just beginning to flow.