Blockaid In-Depth Analysis of Binance's $5.5 Billion Hack: EIP-7702 Attack Chain and Two Security Defenses – Institutional Signatures and On-Chain Monitoring

Author: Blockaid Research Team

Compiled by: TechFlow

TechFlow Overview: On October 29, 2026, the world's largest cryptocurrency exchange, Binance, suffered the largest hacker theft incident by value at stake in cryptocurrency history. According to public on-chain data, the attacker looted over $5.5 billion in assets across Ethereum, Arbitrum, Avalanche, Optimism, Bitcoin, and Tron.

The core breakthrough of this attack lies in Binance 14, one of Binance's most critical Ethereum hot wallets. The hacker not only obtained the signing private key of this hot wallet but also extremely covertly and skillfully exploited the Ethereum EIP-7702 account abstraction delegation mechanism. Within minutes, they delegated the hot wallet, originally a standard external account (EOA), and upgraded it into a malicious sweep contract under absolute control by the hacker. Subsequently, the hacker even further controlled the Circle smart custodial account through this wallet and looted more funds.

Global on-chain security firm Blockaid accurately detected the abnormal fund outflow within two minutes after the drainage and reconstructed the full landscape of cross-network recovery and attack-defense measures. Although Tether and Circle urgently froze approximately $2.4 billion in stablecoins within two hours, the un-freezable native assets had already been moved by the hacker. TechFlow presents a comprehensive and in-depth translation of this authoritative post-incident report released by Blockaid, providing exchanges, asset managers, and developers across the industry with a deep analysis of the technical root causes and defensive insights behind this historic security breach.

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

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

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

Within 12 minutes after the completion of the initial fund loot, 10 additional hot wallets operated by Binance across four public chains successively initiated transfers to the same aggregation address. Subsequently, the attacker further looted Binance's smart contract custodial accounts through Binance 14, which remained under delegated takeover.

Binance officially released a statement stating that it is conducting a serious investigation, emphasizing that no user funds have been confirmed as compromised so far. To date, the cumulative scale of all drained assets has exceeded $5.5 billion, and the impact of the entire exploit attack continues to unfold.

Panoramic Overview of the Attack Incident

Blockaid's security detection system triggered an alert within two minutes after the assets were swept, a response time far earlier than any disclosure by mainstream media or social networks. Subsequently, the automated analysis engine confirmed the private key leak and the underlying EIP-7702 delegation attack mechanism within 11 minutes.

Within one hour of the incident, Blockaid had marked all associated attacker addresses as high-risk malicious addresses on its network-wide security grid and synchronized the event notification to all clients via its Ecosystem Incidents Feed, conducting real-time on-chain tracking of fund diversion, exchange, and lending staking.

Subsequently, stablecoin issuers Tether and Circle urgently froze approximately $1.8 billion in funds within the hacker's core receiving addresses. Tether CEO Paolo Ardoino subsequently stated that the total frozen USDT amount exceeds $1.5 billion.

However, the native assets stolen by the hacker, such as ETH, AVAX, OP, and ARB, which cannot be frozen centrally, remain firmly under the attacker's wallet control.

This review report comprehensively covers the attacker's preparation, 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 signing private keys on a large scale. It points directly to the two core lines of defense that determine the outcome of such attacks: enforcing security policies prior to signature generation, and conducting continuous on-chain monitoring while funds are in motion.

Background Context: Exchange Hot Wallets, Signing Private Keys, and the EIP-7702 Account Delegation Mechanism

Exchange hot wallets are online accounts used by exchanges to pay out customer withdrawals and transfer funds between their own different wallets. These accounts hold massive daily operational working capital and continuously sign transactions, often requiring thousands of transfers to be initiated daily.

The private keys behind these signatures serve as the sole 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 (EOAs).

An EOA is a pure address account without any contract code. As long as the chain validates the signature as legitimate and effective, funds will be transferred unconditionally, with the underlying blockchain executing no additional business logic checks.

The introduction of the EIP-7702 protocol allows standard EOA accounts to execute smart contract code. The account only needs to sign an authorization proof specifying a contract address. Once this authorization is packaged into a block via a Type-4 transaction, any subsequent calls targeting this account will execute the corresponding smart contract's logic and grant full dominion over the account's assets.

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

For ordinary retail investors, this feature enables convenient functions such as batch transaction packaging and gas sponsorship. However, for exchange hot wallets, leaking a signature even once on the correct Nonce hands over long-term code-level control of the account to the attacker, including every subsequent deposit that flows into that address.

In the first half of 2026, Blockaid examined and confirmed four EIP-7702 security incidents, with cumulative losses of approximately $1.08 million, each abusing different characteristics of the delegation mechanism. In its H1 2026 On-Chain Security Report, Blockaid had explicitly warned that the first case reaching seven digits (million-dollar level) would occur by the end of this year.

This security incident involving Binance not only corroborates this assessment, but its scale at stake is fully three orders of magnitude higher than the original prediction.

In comparison, direct transfer attack paths are more traditional. With a stolen private key, the hacker signs conventional transfer transactions. Within a hot wallet processing thousands of withdrawals daily, such transfers appear highly routine; anomalies can only be detected through comprehensive cross-comparison of the recipient target, individual transaction amounts, and transfer timing.

Both attack paths ultimately originate from private key compromise. Therefore, defensive detection against such risks must rely on dynamic perception of behavioral patterns, and absolutely cannot depend solely on known malicious signatures or contract vulnerability signatures.

Attack Deduction: How the Hacker Gained Ground Step by Step

All timestamps below follow the Coordinated Universal Time (UTC) of October 29, 2026. At the time of this report's publication, related on-chain activity surrounding this incident continues to evolve.

Attack Preparation Phase: Mixing Deposits and Sweep Contract Deployment

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

On October 29, this address completely rehearsed the full workflow of "authorization delegation and sweeping" across three test wallets under its own control, transferring test funds ranging from $2 to $6 per instance.

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

This contract is completely unverified and open-source. It sets the hacker's operator address as its sole authorized caller and includes a Sweep function capable of transferring all tokens in a list and the account's native ETH to a designated receiving address in one go. Additionally, the contract incorporates a built-in forwarder function, allowing delegated accounts to call other external contracts.

Nonce Spray Collision: 50 Authorized Signatures, One Precise Hit

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

This transaction carried 50 EIP-7702 authorization proofs pre-signed by the Binance 14 private key, corresponding sequentially to Nonce values from 18,914,775 to 18,914,824. Each authorization delegates the wallet to the sweep contract deployed by the hacker.

Since Binance 14 was still normally processing withdrawal requests from users across the network at the time, the hacker could not precisely predict the exact real-time Nonce at the moment of execution, thus adopting a spray strategy that batch-signs a window of Nonce intervals.

Ultimately, out of these 50 authorizations, 49 expired due to Nonce mismatches, but one hit perfectly and took effect. While Binance's own routine withdrawal transactions continued to pour out from this wallet, the hacker's malicious delegation quietly took over the address.

Sweeping $2.5 Billion in a Single Transaction: Clearing a Hot Wallet's Core Assets

Three minutes and 24 seconds after the delegation took effect, at 20:24:23, the hacker operator triggered a sweep call on Binance 14 (transaction hash: 0x53bd38...).

This transaction instantly transferred 167,464 ETH, 1.615 billion USDT, and approximately 60 other types of tokens to a previously non-existent hacker aggregation address (0x5227f603C1eE34CE3C06eFe6477003BDfCCB2f8c).

After completing this epic loot, the Binance 14 wallet, which once held billions of dollars in assets, was left with only a symbolic 1 ETH. Based on the market price at the time, the total value of this single asset portfolio reached approximately $2.5 billion.

Spanning Four Public Chains: Concurrent Theft of Over a Dozen Hot Wallet Private Keys

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...), draining a total of 28,005.6 ETH, 55.7 million USDT, 25.9 million RLUSD, 84.5 WBTC, and five additional token types.

Within 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.

Notably, none of these subsequently stolen wallets carried any smart contract code themselves. Every fund transfer was executed as a routine transaction directly signed by each wallet's actual private key, cunningly blended into the stream of regular daily user withdrawal transactions.

Controlling Smart Accounts: Persistent Residency Draining Subsequent Deposit Assets

At 20:41:23, the hacker operator utilized the still-delegated-takeover state of Binance 14 to invoke its owned Circle smart custodial account, Binance Hot Wallet 34 (address: 0xEe7aE8...).

The hacker drained 780 million USDC from this smart account to the hacker aggregation address (transaction hash: 0xdc102d...), followed by draining an additional 43 million USDC.

At 21:44, the hacker executed a second sweep on Binance 14 (transaction hash: 0x55ba4d...), completely ransacking 200 million USDT and 13 other token types newly deposited into this address by external users after the first round of sweeps.

By 22:00 that day, the malicious delegation remained stubbornly resident on-chain. Any new assets inadvertently deposited into Binance 14 could be directly swept and withdrawn by the hacker without requiring the hacker to provide another wallet signature.

Why the Cosigner Defense Line is a Matter of Life and Death for Institutions Managing Keys at Scale

The exact moment the hacker initially initiated the delegation transaction could have been the critical line of defense capable of intercepting the entire disaster. Blockaid's transaction security engine immediately flagged the Type-4 transaction delegating to Binance 14 as high-risk malicious upon first detection, with an extremely clear reason for blocking: a standard EOA was upgrading and delegating via EIP-7702 to a completely untrusted external address.

As early as May 2026 when EIP-7702 officially went live, Blockaid had embedded such protective logic into its vulnerability detection engine, successfully intercepting similar attacks multiple times in live production environments.

Blockaid Cosigner is a co-signing security layer independently deployed on the wallet signing pipeline, capable of leveraging threat signals from the vulnerability detection engine in real-time to directly reject malicious transactions.

It sits between the institution's existing signing infrastructure and the underlying public chain, regardless of whether the institution's base utilizes Multi-Party Computation (MPC), multi-signature contracts, or custodian platforms like Fireblocks, Fordefi, Safe, and Utila.

Prior to final signature generation, every transaction, including the authorization lists contained within Type-4 transactions, undergoes complete sandbox simulation and security review. Under Cosigner's default policy protection, if the engine classifies a transaction as malicious, it will be forcibly rejected even if all internal approvers have already signed off.

If a hot wallet's signing path is protected by Cosigner at the front end, its private key could never sign an authorization delegating itself to such a malicious contract, because that authorization would be completely blocked at the policy control layer and absolutely never propagate to the blockchain network.

Furthermore, Cosigner supports configuring whitelisted target addresses, hard caps on single-transaction and time-window transfer limits, and strict access validation for counterparties that are brand new, untagged, or linked to mixer funds.

Although the stolen private key could still generate mathematically valid cryptographic signatures, under the mechanism of enforcing security policies prior to signing, relying solely on the private key alone makes it absolutely impossible to funnel a nine-figure sum into a completely unlisted new address. Anomalous transfers defining this disaster would be directly vetoed at the moment they are proposed.

For exchanges and financial institutions running hot wallets at scale, the Cosigner architecture that enforces policy checks on every signing action is the decisive preventive measure against such private key theft attacks.

During the Flow of Stolen Funds: The Decisive Role of Real-Time On-Chain Monitoring and Risk Exposure Tracing

Any institution can control its own private keys and signing workflows, but it cannot control the external trading venues where funds flow after being stolen, the external counterparties depositing into its platform, nor can it control the reality that the hacker has already recklessly moved nearly $3 billion in massive funds across four public chains.

And this external attack surface is precisely the core battlefield covered by On-Chain Asset Security Monitoring and Risk Exposure tracing. During this incident, both systems were fully activated within seconds of the first transfer.

On-chain monitoring identifies on-chain behavioral patterns, not merely whether cryptographic signatures are valid. The threat signals triggered in this incident were extremely prominent: a hot wallet originally devoid of code suddenly transformed into a pointer directing to an external delegation; a core treasury address pumped staggering volumes of capital into a completely unlisted new address; the same new address centrally received funds from 11 tagged exchange hot wallets across four public chains within just 12 minutes.

Capturing these anomalous traits requires absolutely no known attack signature databases or existing contract vulnerability code. This is the fundamental reason why the Blockaid detection engine could issue precise alerts 1 minute and 55 seconds after the first sweep and within 7 seconds of initiating cross-chain transfers.

In fact, the hacker's delegation authorization had been exposed on the Ethereum public chain for 3 minutes and 24 seconds before formally executing the sweep. Any institution monitoring status changes to its own core addresses inherently possessed the opportunity to respond urgently within this golden window.

Once monitoring triggers an alert, Blockaid's automated emergency response workflow can directly generate emergency defense transactions to transfer balances or revoke delegations within the institution's custodial platform, enabling emergency handling and threat discovery to launch concurrently within the same minute.

The Risk Exposure tracing system addresses the other side of this incident: all external ecosystem participants poised to receive this illicit cash.

Within 90 minutes of the first asset loot, the stolen funds rapidly permeated through Permit2, LI.FI, Uniswap, UniswapX, and Aave, subsequently expanding into multi-chain cross-chain bridging and aggregated swaps.

Every liquidity pool, lending market, cross-chain bridge, market maker, and centralized exchange along this money laundering pathway now holds or has processed the stolen funds, meaning anti-money laundering (AML) compliance risk instantly transferred to themselves at the moment of capital injection. The risk exposure system provides these institutions with second-level real-time risk warning signals.

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

Before the birth of the Ethereum EIP-7702 protocol, hot wallet private key theft often devolved into a race against time to transfer assets. Hackers had to hurry to sign transfers bit by bit to steal money, while exchange operations teams, upon detection, still had opportunities to preemptively transfer remaining funds by boosting Gas fees; once an exchange rotated its operational hot wallet to a brand-new address, the old stolen private key in the hacker's hand would be rendered completely obsolete scrap metal.

However, once the stolen private key gained the ability to sign account abstraction delegations, the attack-defense landscape underwent a fundamental reversal. Relying solely on an authorization proof valid under a specific Nonce, Binance 14 was thoroughly converted into a privately owned ATM program for the attacker.

After the first wave of sweeping plundered existing assets at UTC 20:24, the delegation relationship remained persistently mounted on-chain. By 21:44, the hacker, without needing Binance 14 to provide any new signatures whatsoever, once again effortlessly plundered over $200 million in subsequently newly deposited assets.

At this point, even if the exchange rotated its internal operational keys to brand-new private keys, it fundamentally could not clear this on-chain delegation, because the delegation relationship is bound to the base address. Only by using the leaked private key again to sign a new authorization, explicitly resetting the delegation target to the zero address, can the hacker's code control over this account be completely severed. Until then, any assets flowing into Binance 14 are prey at the hacker's fingertips to be taken at any moment.

For teams managing large EOA accounts, this incident sounded a bone-chilling safety alarm; specific response strategies are quite clear: EIP-7702 authorizations must be treated as privileged operations, subjected to the exact same strict policy controls applied to cold wallet withdrawals.

Implement round-the-clock monitoring for code status changes across all hot wallet addresses, and prepare pre-signed revocation transactions in advance; before the delegation status is confirmed safe, resolutely avoid leaving any fund inventory at that address; after a private key leak incident, before rotating keys and refilling wallets with capital, the delegation relationship must be thoroughly cleared on-chain first.

Furthermore, when initiating any delegation transaction, the authorization list must be fully passed through to the transaction review layer. Because if stripped of this list, a dangerous delegation transaction superficially resembles a harmless blank call to a trusted address. Blockaid's security engine currently supports deep evaluation of this list, and Cosigner has also achieved full passthrough. The biggest vulnerability exposed by this historic security incident precisely lies in traditional signing workflows that lack this type of advance review.

Incident Review and Final Conclusions

Private key leakage remains the largest source of fund loss facing the current public chain world. If public statistical data is ultimately confirmed, this incident will become the largest-scale theft tragedy in cryptographic history, with a value at stake more than triple the theft losses suffered by Bybit in February 2025 (approximately $1.5 billion).

Private keys from 11 hot wallets under Binance initiated transfer signatures in a short timeframe to a hacker address created just minutes prior. One key wallet even signed an EIP-7702 authorization, directly reducing itself to a long-resident plundering 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 absconded with massive amounts of Ethereum and other native assets.

From the perspective of the underlying blockchain, a legally valid signature issued by a stolen private key is indistinguishable from a legally valid signature from normal authorization. In this type of private key attack, the true watershed moment depends on policy gatekeeping at the exact instant a signature is generated, and whether sharp on-chain monitoring can precisely intercept the funds mid-flight during the golden few minutes after they first begin moving.