Blockaid's In-Depth Postmortem of the $5.5 Billion Binance Hack: EIP-7702 Attack Chain and Two Security Lines: Institutional Signing and On-Chain Monitoring

Author: Blockaid Research Team

Translation: TechFlow

TechFlow Editor's Note:On October 29, 2026, the world's largest cryptocurrency exchange, Binance, suffered the largest hacker theft in cryptocurrency history by amount involved. According to public on-chain data, the attackers drained over $5.5 billion in assets across Ethereum, Arbitrum, Avalanche, Optimism, Bitcoin, and Tron.

The core breakthrough of this attack was Binance 14, one of Binance's most critical Ethereum hot wallets. The hackers not only obtained the signing private key of the hot wallet, but also covertly and sophisticatedly exploited Ethereum's EIP-7702 account abstraction delegation mechanism, delegating what was originally a standard externally owned account (EOA) hot wallet into a malicious sweep contract under the hackers' absolute control within just a few minutes. Subsequently, the hackers further used the wallet to take control of Circle smart custody accounts and drained additional funds.

Global on-chain security firm Blockaid precisely detected the abnormal outflow less than two minutes after the funds were swept, and reconstructed the full picture of network-wide recovery efforts and attack-defense dynamics. Although Tether and Circle urgently froze about $2.4 billion in stablecoins within two hours, native assets that could not be frozen had already been transferred by the hackers. TechFlow has fully and deeply translated this authoritative incident postmortem published by Blockaid, providing exchanges, asset management firms, and developers across the industry with an in-depth analysis of the technical root causes and defensive lessons behind this historic security incident.

According to public on-chain data, on October 29, 2026, hackers stole fromBinance's multiple hot wallets on Ethereum, Arbitrum, Avalanche, Optimism, Bitcoin, and Tron at least $5.5 billion in assets, setting a record for the largest theft in crypto history.

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

At 20:24 UTC, the attacker drained about $2.5 billion in assets from Binance 14 in a single transaction. Minutes before this drain, the attacker, holding a leaked copy of the wallet private key, signed anEIP-7702authorization that delegated the hot wallet to a malicious sweep contract deployed in advance by the attacker.

Within 12 minutes after the initial drain was completed, 10 additional Binance hot wallets on four public blockchains successively initiated transfers to the same aggregation address. Subsequently, the attacker further used Binance 14, still under delegated control, to drain Binance's smart contract custody accounts.

Binance officially later published astatementsaying it was conducting a serious investigation into the incident and emphasizing that no user funds had been confirmed as affected. As of now, the total amount of assets drained has exceeded $5.5 billion, and the impact of the exploit is still unfolding.

Attack Event Overview

Blockaid's security detection system triggered an alert less than two minutes after the assets were swept, a response time far earlier than any public media or social media disclosure. Subsequently, its 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 addresses associated with the attacker as high-risk malicious addresses across its global security network, notified all customers of the incident through its Ecosystem Incidents Feed, and tracked the funds' splitting, swapping, and lending/staking in real time on-chain.

Subsequently, stablecoin issuersTetherandCircleurgently froze about $1.8 billion in funds in the attacker's core receiving addresses. Tether CEO Paolo Ardoino latersaidthat the total amount of USDT frozen by Tether had exceeded $1.5 billion.

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

This post-mortem report comprehensively covers the attacker's preparation, EIP-7702 delegation and asset sweeping, concurrent private-key signing across four public blockchains, money-laundering paths and fund freezes, and Blockaid's detection and incident response.

This report is written for exchanges, custodians, and financial institutions that hold and manage signing private keys at scale. It addresses the two core defenses that determine the outcome of such attacks: enforcing security policies before signatures are generated, and continuously monitoring on-chain activity while funds are in motion.

Background: exchange hot wallets, signing private keys, and the EIP-7702 account delegation mechanism

Exchange hot wallets are online accounts used by exchanges to pay customer withdrawals and transfer funds between their own wallets. These accounts hold large amounts of day-to-day operating liquidity and continuously sign transactions, often initiating thousands of transfers per day.

The private keys behind these signatures are the sole control barrier between large account balances and any hacker who holds 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 with no contract code. Once an on-chain signature is verified as valid, funds are transferred unconditionally, and the underlying blockchain does not perform any additional business-logic validation.

The introduction of theEIP-7702protocol allows ordinary EOA accounts to execute smart contract code. The account only needs to sign an authorization specifying a contract address. Once the authorization is included in a block via a Type-4 transaction, any subsequent call to the account executes the corresponding smart contract logic and has full control over the account's assets.

The 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, the delegation remains effective long-term.

For ordinary retail users, this feature enables conveniences such as transaction batching and sponsored gas fees. However, for exchange hot wallets, a single leaked signature at the correct Nonce can hand attackers long-term code-level control of the account, including every new deposit that later enters the address.

Blockaid had already investigated and confirmed four EIP-7702 security incidents in H1 2026, with cumulative losses of approximately $1.08 million, each incident abusing a different aspect of the delegation mechanism. Blockaid, in its2026 H1 On-Chain Security Report, had explicitly warned that the first seven-figure (million-dollar) loss incident would occur by the end of this year.

The security incident that Binance experienced not only validated this assessment, but the scale of the incident was a full three orders of magnitude above the initial forecast.

By contrast, the direct-transfer attack path is more traditional. Using stolen private keys, the hacker signs routine transfer transactions. In a hot wallet that processes thousands of withdrawals per day, such transfers appear extremely routine; anomalies can only be detected by comprehensively cross-checking recipient targets, individual amounts, and transfer timing.

Both attack paths ultimately originate from private-key theft. Therefore, defensive detection for such risks must rely on dynamic awareness of behavioral patterns and cannot depend solely on known malicious signatures or contract vulnerability indicators.

Attack walkthrough: how the hacker succeeded step by step

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

Attack preparation phase: mixer-funded inflow and deployment of the sweeping contract

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

On October 29, the address fully rehearsed the 'authorize delegation and sweep' workflow on three test wallets under its control, transferring test funds ranging from $2 to $6 each time.

At 15:59 that day, the hacker formally deployed the sweeping contract later used to drain Binance (address:0x63e842B054Bd624a465454D533C33F573e9c6fAe, corresponding deployment transaction hash:0x97408e...）。

The contract was completely unverified as open source, set the hacker operator address as its only authorized caller, and included a Sweep function that could transfer all tokens on the list and the native ETH in the account to a designated recipient address in one go. In addition, the contract included a forwarding function that allowed delegated accounts to call other external contracts.

Nonce spray collision: 50 authorization signatures, one precise hit

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

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

Because Binance 14 was still processing withdrawal requests for users across the network at the time, the hacker could not precisely predict the real-time Nonce value at the moment of the call, and therefore adopted a spray strategy by batch-signing a Nonce range window.

Ultimately, 49 of the 50 authorizations failed due to Nonce mismatches, but one precisely hit and took effect. While Binance's own routine withdrawal transactions continued to be sent from the wallet, the hacker's malicious delegation quietly took over the address.

Single $2.5 billion drain: one transaction emptied the hot wallet's core assets

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

This transaction transferred in one go to a hacker collection address with no prior transaction history (0x5227f603C1eE34CE3C06eFe6477003BDfCCB2f8c) 167,464 ETH, 1.615 billion USDT, and approximately 60 other tokens.

After this large-scale theft, the once multi-billion-dollar Binance 14 wallet was left with only 1 symbolic ETH. Based on market prices at the time, the total value of this single asset basket was approximately $2.5 billion.

Across four public blockchains: private keys of more than ten hot wallets stolen concurrently

Just 24 seconds after the first massive sweep was completed, the Binance 16 wallet (address:0xDFd529...) initiated a transfer to the same collection address (transaction hash:0x51f263...), draining a total of 28,005.6 ETH, 55.7 million USDT, 25.9 million RLUSD, 84.5 WBTC, and 5 other tokens.

Within the following 12 minutes, Binance'sOptimism-based Binance 55 wallet transferred out 44.2 million OP;

onArbitrum, four hot wallets transferred out 74.6 million ARB and 8,426 ETH;

onAvalanche, another four hot wallets transferred out 1.81 million AVAX and 8.41 million USDT.

Notably, none of these subsequently compromised wallets themselves contained any smart contract code. Each fund transfer was a regular transaction directly signed by the wallet's own actual private key and was cunningly mixed into the normal flow of daily user withdrawal transactions.

Controlling smart accounts: maintaining residency to drain subsequent deposits

At 20:41:23, the hacker operator used Binance 14, which remained under delegated takeover, to call the Circle smart custody account owned by it, Binance Hot Wallet 34, address:0xEe7aE8...）。

The hacker drained 780 million USDC from this smart account to the hacker collection address (transaction hash:0xdc102d...），随后又追平转走了另外 4300 万枚 USDC。

21:44，黑客再次对 Binance 14 执行了二次清扫（交易哈希：0x55ba4d...），将首轮清扫后外部用户新充值进入该地址的 2 亿枚 USDT 及 13 种其他代币再度搜刮一空。

截至当天 22:00，该恶意委托依然顽固驻留在链上，任何未经察觉打入 Binance 14 的新资产，都无需黑客再次提供钱包签名，便可直接被黑客清扫提走。

为什么 Cosigner 防线对规模化管理私钥的机构生死攸关

黑客最初发起委托交易的那个时间节点，原本是完全可以拦截整场浩劫的关键防线。Blockaid 的交易安全引擎在初次检测到委托 Binance 14 的 Type-4 交易时，便在第一瞬间将其判定为高危恶意操作，拦截原因极为明确：一个普通的 EOA 正在通过 EIP-7702 升级并委托给一个完全不受信任的外部地址。

早在 2026 年 5 月 EIP-7702 正式上线之际，Blockaid 便已在其漏洞检测引擎中内嵌了此类防护逻辑，并在实际生产环境中多次成功拦截同类攻击。

Blockaid Cosigner 是一个独立部署在钱包签名链路上的联合签名安全层，它能够实时利用漏洞检测引擎的威胁信号，直接拒绝恶意交易。

它卡位在机构原有的签名基础设施与公链底层之间，无论机构底层采用的是多方计算（MPC）、多签合约，还是 Fireblocks、Fordefi、Safe、Utila 等托管服务商平台。

在最终签名生成之前，包括 Type-4 交易内部授权列表在内的每一笔交易，都会先经过完整的沙箱模拟与安全审查。在 Cosigner 的默认策略保护下，只要引擎将某笔交易定性为恶意，即便机构内部所有审批人均已签字批准，该交易也会被强制驳回。

如果热钱包的签名路径受到 Cosigner 的前置防护，其私钥根本无法签署将自身委托给此类恶意合约的授权，因为该授权在策略控制层就会被彻底阻断，绝不可能流出至区块链网络。

此外，Cosigner 还支持配置白名单目标地址、单笔及时间窗口转账额度硬顶，以及针对全新的、无标签的或与混币器资金关联的交易对手方进行严格准入校验。

虽然被盗的私钥依然能产生数学上合法的密码学签名，但在签名前强制执行安全策略的机制下，单凭私钥本身绝不可能将高达九位数的巨款转入一个毫无历史记录的全新地址，定义这场浩劫的异常转账在被提议的那一刻就会被直接否决。

对于大规模运行热钱包的交易所和金融机构而言，在每一次签名动作上强制执行策略检查的 Cosigner 架构，是防御此类私钥失窃攻击的决定性预防手段。

被盗资金流转期间：链上实时监控与风险敞口穿透的决定性作用

任何机构都可以掌控自己的私钥与签名工作流，但它无法掌控资金被盗后流经的外部交易场所、向自身平台充值的外部对手方，更无法掌控黑客已经在四条公链上肆意转移 $30 亿美元巨资的现实。

而这片外部攻击面，正是链上资产安全监控（Onchain Monitoring）与风险敞口穿透（Risk Exposure）所覆盖的核心战场。在本次事件中，这两套系统在第一笔转账发生后的数秒内便全部投入运转。

链上监控识别的是链上行为模式，而非密码学签名是否有效。本次事件中触发的威胁信号极为显著：一个原本代码为空的热钱包突然转变为指向外部委托的指针；一个核心资金库地址向一个毫无历史的全新地址汇出体量惊人的天量资金；同一个新地址在短短 12 分钟内，从四条公链上的 11 个带标签的交易所热钱包中集中收款。

Capturing these anomalous characteristics requires no known attack signature library or existing contract vulnerability code. This is also why Blockaid's detection engine could issue precise alerts 1 minute and 55 seconds after the first sweep and within 7 seconds of the cross-chain transfer being initiated.

In fact, the attacker's delegation authorization had already been exposed on Ethereum's public chain for 3 minutes and 24 seconds before the sweep was formally executed. Any institution monitoring state changes to its own core addresses originally had an opportunity to respond urgently during this golden window.

Once monitoring triggered an alert, Blockaid's automated emergency response workflow could directly generate emergency defensive transactions on the institution's custody platform to move balances or revoke delegations, enabling incident response to begin in the same minute as threat detection.

The Risk Exposure system addressed the other side of this incident: all external ecosystem participants about to receive the stolen funds.

Within 90 minutes after the first assets were swept, the stolen funds rapidly permeated and flowed through Permit2, LI.FI, Uniswap, UniswapX, and Aave, followed by cross-chain bridging and aggregated swaps across multiple chains.

At that point, every liquidity pool, lending market, cross-chain bridge, market maker, and centralized exchange on this money-laundering path had already held or processed the stolen funds, and AML compliance risk had shifted to them the moment the funds were injected. The risk exposure system can provide these institutions with second-level real-time risk warning signals.

Mechanism Reflection: How EIP-7702 Turns a Leaked Private Key into Persistent Control

Before the emergence of Ethereum's EIP-7702 protocol, theft of a hot wallet private key often turned into a race against the clock to move assets. Hackers had to sign transfers one by one as quickly as possible to steal funds, while exchange operations teams, after detecting the theft, still had a chance to preemptively move the remaining funds by raising Gas fees; once the exchange rotated its operational hot wallet to a brand-new address, the old leaked private key in the hacker's hands became completely worthless.

However, once a stolen private key gained the ability to sign account abstraction delegations, the offense-defense dynamic fundamentally reversed. With only one authorization proof valid under a specific Nonce, Binance 14 was completely converted into a personal ATM program owned by the attacker.

After the first wave of sweeping drained existing assets at UTC 20:24, the delegation relationship remained attached on-chain. By 21:44, without requiring Binance 14 to provide any new signatures, the attacker again easily drained over $200 million in newly deposited assets.

At this point, even if the exchange rotated its internal operational keys to brand-new private keys, it could not clear this on-chain delegation at all, because the delegation relationship was tied to the underlying address. Only by using the leaked private key again to sign a new authorization that explicitly resets the delegation target to the zero address could the hacker's code control over the account be completely removed. Until then, any assets flowing into Binance 14 were instantly available to the hacker.

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

Implement 24/7 monitoring of code-state changes for all hot-wallet addresses and prepare pre-signed revocation transactions in advance; firmly avoid leaving any funds or asset inventory at the address until the delegation state is confirmed safe; after a private-key leak incident, fully clear the delegation relationship on-chain before rotating keys and replenishing the wallet.

At the same time, when initiating any delegation transaction, the full authorization list must be passed through to the transaction review layer. If that list is stripped away, a dangerous delegation transaction can formally appear to be a harmless blank call to a trusted address. Blockaid's security engine now supports deep evaluation of this list, and Cosigner has also implemented full pass-through; the biggest weakness exposed by this historic security incident lies precisely in traditional signing workflows that lack such pre-transaction review.

Incident Review and Final Conclusion

Private key leaks remain the largest source of fund losses in today's public blockchain ecosystem. If publicly available statistics are ultimately confirmed, this incident will become the largest theft in crypto history, with losses more than three times those from the Bybit hack in February 2025 (approximately $1.5 billion).

Private keys for 11 Binance hot wallets signed transfer transactions within a short period to a hacker address created only minutes earlier, and one key wallet even signed an EIP-7702 authorization, effectively turning it into a persistent tool for the attacker's fund draining.

Although compliant stablecoin issuers urgently froze approximately $2.4 billion in assets within two hours of the incident, the attacker still managed to drain a large amount of Ethereum and other native assets.

From the perspective of the underlying blockchain, a valid signature generated by a compromised private key is indistinguishable from a valid signature authorized under normal conditions. In private key attacks of this kind, the real dividing line depends on policy controls at the moment the signature is generated and on whether sharp on-chain monitoring can precisely intercept funds during the golden minutes when they first begin moving.

Source: TechFlow