‍Dan Caspi, Hypernative co-founder and CTO, is running a live briefing on this attack on Weds, 4th November: Register here.

On October 29, 2026, wallets publicly labelled as Binance hot wallets began sending funds to fresh attacker addresses. Hypernative detected the attack from its preparatory stages through to the drains, outflows and movements, across multiple chains. Binance has since put the total impact around $6.3B, with approximately $3B frozen onchain through issuers and partners. 

On Ethereum, the largest single movement came from a hot wallet that the attacker had delegated to their own contract using EIP-7702, a feature of the Pectra upgrade that lets an externally owned account (EOA) temporarily run contract code. For anyone holding customer funds, every outflow was authorized with the hot wallets' own keys. The attack abused signing access rather than a flawed contract.

At a glance

• Loss: ~$6.3B with around $3B frozen
• Networks:  Ethereum, Arbitrum, Optimism, Base, Avalanche and Polygon, Solana, Bitcoin, Tron, and XRP Ledger.
• Drain window: Bulk of outflows within ~1h  from ~20:10 UTC on 29 October 2026.
• Root cause (as understood onchain): Valid signatures from Binance-controlled keys across multiple chains (EVM and non-EVM); on Ethereum, an EIP-7702 delegation of a hot wallet to attacker-controlled code. No contract exploit.
• Funds as of 30 October: part of the stolen USDT and USDC frozen by their issuers; ETH, SOL, BTC and most other tokens unfrozen, some already moving.

Timeline (UTC)

• ~36h before: Attacker’s wallet funded through Tornado Cash
• ~18h before: Attacker deploys a test sweeper contract
• ~4h before: Attacker deploys the live sweeper used in the attack
• 20:05 - 20:10: Attack begins on XRP and Solana
• 20:16 - 20:18: Outflows from Binance hot wallets on Base and Optimism
• 20:20 to 20:22: Bitcoin and Tron hot wallets drained
• 20:20: Binance 14 delegated to the sweeper
• 20:24: Binance 14 swept, outflows from Binance 16 on Ethereum
• 20:30 - 20:36: Outflows on Arbitrum and Avalanche
• 20:41: USDC pulled from a Binance smart account through Binance 14’s delegation
• 20:59 : A second USDC pull from a Binance smart account through Binance 14’s delegation
• 21:04 - 23:56: Binance 14 swept 4 more times while still delegated
• 23:04 - 23:05: Outflows from Avalanche and Polygon hot wallets
• 00:10 (30 Oct): Binance revokes the Binance 14 delegation

Hypernative detected the malicious activity in real-time and issued Alerts to the subscribed customers, as well as incident notifications to our Threat Intelligence community.

How the attack worked

An EIP-7702 takeover has three moving parts: a contract that can drain a wallet, a signature that points the wallet at that contract, and a call that fires the drain. If an attacker already holds a wallet's signing key, these three parts can be combined into complete, repeatable control.

Funding the operator (28 October)

About 36 hours before the drain, the operator wallet was funded from Tornado Cash in small amounts. Hypernative flagged the mixer funding at 07:39 UTC, its first detection tied to this attacker.

Building the sweeper (02:28 to 15:59)

The attacker prepared the first part well ahead of time. At 02:28 UTC they deployed a sweeper contract, funded through Tornado Cash, and tested it on disposable wallets. At 15:59 UTC they deployed the version used in the attack, 0x63e842b054bd624a465454d533c33f573e9c6fae. Its bytecode allows only the attacker's own address to call it, and it exposes functions to sweep every token balance from a wallet, withdraw its ETH, and make arbitrary calls on the wallet's behalf.

Binance 14 takeover (20:20 to 20:24)

Binance 14 is one of Binance's main Ethereum hot wallets, a high-throughput address (0x28c6c06298d514db089934071355e5743bf21d60) that processes customer withdrawals. The takeover itself happened at 20:20:59 UTC. A single EIP-7702 transaction (0xad99264d…) carried 50 authorizations covering consecutive nonces of Binance 14 (0x28c6c06298d514db089934071355e5743bf21d60), each one delegating the wallet to the sweeper contract. Spreading the authorizations across 50 nonces is how the attacker made sure one would still match the wallet’s nonce while it kept processing normal withdrawals; in the event, exactly one of the 50 matched and took effect. An EIP-7702 authorization has to be signed by the delegating wallet's own key, which is the clearest onchain sign that the attacker already could get Binance 14’s key to sign.

With the delegation in place, the drain was one transaction. At 20:24:23 UTC a single call (0x53bd38b8…) ran the sweeper's code in Binance 14's context and moved 167,464 ETH and 63 ERC-20 tokens out of the wallet, the largest being about 1.61B USDT. 

Between 20:41 and 20:59 UTC the same permissions pulled about $823M USDC out of a separate Binance-labelled contract. That contract was a Circle smart account whose only owner was Binance 14, so once the attacker controlled Binance 14 they could call it too: a 7702 delegation inherits every permission the delegating address holds on other contracts, not just its own token balance. 

The delegation also belongs to the address rather than to any single key, so it persists until explicitly replaced, and rotating the key would not have removed it. It was left in place and customer deposits kept arriving, so the attacker swept Binance 14 four more times, at 21:04, 21:44, 22:39 and 23:56 UTC, until Binance revoked the delegation at 00:10 UTC on 30 October.

The multichain drain

Ethereum carried the most elaborate version of the attack. Across the same window, a second Ethereum hot wallet (Binance 16) and Binance-labelled wallets on the seven other chains signed ordinary transfers straight to the attacker, with no delegation involved. Those transfers came from separate wallets and keys on every chain. A compromise that reaches that many wallets and keys at once points at Binance’s signing infrastructure rather than any single leaked key.

Binance's initial investigation, published on 30 October ,appears to corroborate this evidence, attributing the incident to a compromised DevOps engineer's laptop that gave an attacker access to a service container used to submit withdrawals, and says it has found no evidence of a wallet private-key leak. Access to the signing service produces authentic signatures, including the EIP-7702 authorization that required Binance 14's key, without the raw key ever leaving Binance. Binance says it has revoked the affected authorization and will publish a full post-mortem once its investigation is complete.

Public reporting has linked the operation to North Korea's TraderTraitor group, the cluster tied to the 2025 Bybit theft. Hypernative has not independently confirmed attribution. The tradecraft, a compromise of the signing path rather than a contract bug, matches the pattern we documented across 2025's signer-compromise incidents.

What Hypernative saw

Hypernative's monitoring fired throughout the attack, in real-time and before any funds moved. We continue to trace the funds as they move to new addresses.

Where the funds went

The stolen assets are split by whether they can be frozen. Tether and Circle froze part of the stolen USDT and USDC, and Binance puts the total frozen so far at around $3B. Everything else is still moving. The 167,464 ETH and the Solana and Bitcoin holdings have no issuer and cannot be frozen; some of the swept stablecoins are freezable but have not been frozen yet. 

Part of the USDT was swapped to ETH ahead of the freezes, and the stolen BTC is being split into chunks of about 1,000 BTC each, a common step before laundering through mixers or cross-chain routes. As of 30 October, the attacker still holds unfrozen tokens including PAXG, USD1 and FDUSD at 0x5227f603c1ee34ce3c06efe6477003bdfccb2f8c.

How Hypernative Transaction Guard Can Mitigate the Risks

The Hypernative Transaction Guard is an out-of-band control that inspects, simulates and analyzes every initiated transaction and message, providing risk assessment, enforcing policies and securing against internal systems compromises, user errors, malicious insiders and multiple other risks. For an exchange or custodian whose signing routes through a MPC/Safe and Transaction Guard integration, two points in this attack were screenable before any signature was given:

1. The direct withdrawals. Transaction Guard simulates each withdrawal before signing, so a balance-sized transfer to a brand-new address is flagged or denied.
2. The delegation (20:20). Transaction Guard screens the EIP-7702 authorization before it is signed. A deny-on-malicious policy blocks the delegation to the sweeper Hypernative had flagged at 15:59, which prevents the $2.57B sweep, the $823M USDC pull and every repeat sweep.
   

Each checkpoint maps to one of the controls below.

The withdrawal itself.

The gap. A single call moved 167,464 ETH and 63 tokens. By the time a transfer of that size and shape reaches the mempool, there is no time for a human to intervene.

Policy. Put signed outflows behind automated checks: simulate every withdrawal, block transfers above size or velocity thresholds or to unknown recipients, and wire a circuit breaker that can pause a wallet whose behavior changes.

Transaction Guard: Transaction Guard evaluates a transaction against these policies before it settles, so an anomalous mass withdrawal can be stopped rather than merely recorded.

None of these controls depends on knowing in advance how the keys were compromised. They act on the behavior the compromise produces onchain, which is observable to anyone watching for it.

Delegation of a hot wallet.

The gap: EIP-7702 lets a wallet’s own key hand full control to contract code in one transaction. Most custody stacks do not watch for their own wallets acquiring delegated code, so the takeover looks like routine signing activity until the drain lands.

Policy: Screen every delegation before it is signed. A delegation policy can deny any delegation to a contract flagged as malicious and warn on a wallet’s first-ever delegation. A deny list is only as good as the intelligence behind it. Here the target was a sweeper contract that only its deployer could call, built to drain arbitrary wallets. Hypernative flagged it at deployment at 15:59 UTC, more than four hours before Binance 14 delegated to it, so a deny-on-malicious policy would have refused the signature at 20:20.

Transaction Guard: For wallets whose signing runs through Transaction Guard, a delegation like this is evaluated offchain before signing and can be denied, so the attacker never receives a valid authorization to submit.

Monitoring and response. Onchain, the set-code transaction and its delegation target are visible the moment they confirm. That is the last point where a drain can still be pre-empted.

What to do now

This attack left signals at every stage: before, during and after the theft. Which signals matter, and which controls cover them, depends on how you operate.

Protocols and treasuries

Any team that signs from hot or treasury wallets is exposed to the same pattern Binance faced:

• A single signature hands over a wallet. One EIP-7702 delegation gave the attacker full, lasting control of Binance 14, and every sweep that followed needed no further signature. The sweeper had been flagged as malicious more than four hours earlier. Transaction Guard screens every delegation before it’s signed and is designed to deny delegations to known malicious contracts.
• Balance-sized withdrawals to brand-new addresses. On the other chains, hot wallets signed ordinary transfers straight to the attacker. Transaction Guard simulates every transaction before signing and flags transfers like these as anomalies.
• The attack is prepared in plain sight. The attacker funded an operator wallet through Tornado Cash about 36 hours before the theft and deployed the sweeper hours ahead. Onchain Monitoring flagged both, as well as the outflows in real-time, and automated response can trigger a defensive action within seconds of an alert.
• Stolen funds reach your flows. Laundered funds can arrive as deposits or through counterparties. Address Screener traces every address the attacker uses, so you can avoid receiving, processing or interacting with them.

Asset managers

Your exposure doesn’t stop at your own wallets:

• The venues you rely on are affected. The exchanges and protocols where you hold funds or collateral can be drained the way Binance was. Onchain Monitoring watches those venues and alerts you as soon as unusual outflows start.
• The attacker sells what they still hold. The attacker still holds tokens including PAXG, USD1 and FDUSD, and a large sale could push prices down sharply against your positions. Onchain Monitoring alerts on the attacker’s transfers, and automated response can reduce or exit a position when the price falls past your threshold.
• Your own signing is compromised. A compromised key or signing service can hand control of your wallets to an attacker in one signature. Transaction Guard screens your transactions and delegations before they’re signed.
• Attacker-linked funds reach your counterparties. Address Screener traces every address the attacker uses, so those funds stay out of your flows.

For Hypernative customers

Already using all three? Your setup is designed to protect you against this type of attack. Transaction Guard’s default settings deny delegations to known malicious addresses before signing. As a precaution, the Hypernative team has already contacted every customer to verify that their setup is configured as intended, and to help set up alerts specific to this incident.

Join the live briefing

Join Dan Caspi for a live security briefing: what our systems saw as it unfolded and what security, risk and ops teams can do now to check exposure across your signing systems and third-party dependencies.

About Hypernative

Hypernative is the proactive onchain security platform for enterprises and institutions. We predict and neutralize digital asset threats before they materialize, unifying real-time monitoring, transaction security, fraud prevention, compliance screening, and automated response in a single, institutional-grade platform. 

Powered by the most battle-tested machine learning engine in digital asset security, Hypernative has actively prevented over $3 billion in losses across 75+ blockchains, all verifiable onchain. 

Trusted by 350+ leading organizations including top financial institutions, exchanges, asset managers, protocols, and chains, Hypernative provides the security infrastructure that gives enterprises and institutions the confidence to operate and scale in the onchain economy. Learn more at hypernative.io.