Binance hot wallets drained across multiple networks
Attackers stole at least $6.3 billion from multiple Binance hot wallets on Ethereum, Arbitrum, Avalanche, Optimism, Bitcoin and Tron on Oct. 29, 2026, according to public on-chain statistics cited in a review by Blockaid’s research team. If the figures are confirmed, the incident would rank as the largest cryptocurrency theft by value.
The operation focused on Binance 14, an Ethereum address identified as 0x28C6c06298d514Db089934071355E5743bf21d60. The wallet was one of Binance’s largest and most active Ethereum hot wallets. At 20:24 UTC, the attackers drained roughly $2.5 billion in one transaction.
Minutes before that transfer, the attackers used a copy of the wallet’s leaked private key to sign an EIP-7702 authorization. The authorization delegated Binance 14 to a malicious sweeping contract deployed in advance. Within 12 minutes of the first drain, another 10 Binance hot wallets on four networks sent funds to the same collection address. The attackers later used Binance 14, which remained under delegation, to drain a Binance smart custody account.
Blockaid detected the drain within minutes
Blockaid said its security detection system raised an alert less than two minutes after the assets were swept, before any public media or social network disclosure. Its automated analysis engine confirmed the private-key compromise and the EIP-7702 delegation mechanism behind the attack within 11 minutes.
Tether and Circle then froze about $1.8 billion held at the attacker’s main receiving address. Tether CEO Paolo Ardoino later said Tether had frozen more than $1.5 billion in USDT. Native assets including ETH, AVAX, OP and ARB could not be frozen by centralized issuers and remained under the attackers’ control.
Blockaid’s review covers the attacker’s preparation, the EIP-7702 authorization and sweeping process, concurrent private-key signatures across four networks, the movement and freezing of funds, and the company’s detection and response. The report is aimed at exchanges, custodians and financial institutions that hold and manage large amounts of signing keys. It identifies two key control points: enforce security policy before a signature is produced, and monitor on-chain activity while funds remain in motion.
Why EIP-7702 matters for hot wallets
Exchange hot wallets are online accounts used to process customer withdrawals and move funds between the exchange’s own wallets. They hold large pools of operating liquidity and may sign thousands of transfers in a day.
The private key behind each wallet is the main control barrier between its balance and anyone holding a copy of that key. On Ethereum and other EVM-compatible networks, these wallets have historically been externally owned accounts, or EOAs. An EOA has no contract code. Once the chain verifies a valid signature, the transfer proceeds without an additional business-logic check at the blockchain layer.
EIP-7702 allows an ordinary EOA to run smart-contract code. The account signs an authorization naming a contract address. Once that authorization is included in a Type-4 transaction, subsequent calls involving the account execute the delegated contract logic and can exercise full control over the account’s assets.
The authorization is tied closely to the account’s nonce. The delegation remains active unless the account signs and broadcasts another authorization that replaces or clears it. For individual users, this can support bundled transactions and sponsored gas payments. For an exchange hot wallet, one signature at the correct nonce can give an attacker long-term code-level control, including over deposits that arrive after the initial compromise.
Blockaid said it identified four EIP-7702 security incidents during the first half of 2026, with combined losses of about $1.08 million. Each incident abused a different feature of the delegation mechanism. In its first-half 2026 on-chain security report, Blockaid warned that the first million-dollar-scale loss would occur before the end of the year. The Binance incident matched that warning, but its reported value was three orders of magnitude larger.
A conventional direct-transfer attack follows a different path. The attacker uses a stolen key to sign ordinary transfers. Because a hot wallet may process thousands of withdrawals, malicious transactions can blend into normal activity. The destination, amount and timing have to be assessed together to reveal the anomaly.
Both paths begin with a stolen private key. That is why defenses need dynamic behavior detection rather than relying only on known malicious signatures or contract-vulnerability patterns.
The preparation: tests, funding and a sweeping contract
The timeline below uses UTC on Oct. 29, 2026. Blockaid said related on-chain activity was still developing when its report was published.
The attacker-controlled operator address was 0x7C8601d4645b93cea45F71e118A729332e6B5CA0. Starting on Oct. 28, it received initial test funds through three withdrawals from Tornado Cash.
On Oct. 29, the operator ran the full “delegate and sweep” process on three test wallets under its control. Each test moved between $2 and $6. At 15:59, the operator deployed the sweeping contract later used against Binance. The contract address was 0x63e842B054Bd624a465454D533C33F573e9c6fAe, and the deployment transaction hash was 0x97408e….
The contract had not been verified through open-source publication. It set the operator address as the only authorized caller and included a Sweep function that could move every token in a list, as well as the account’s native ETH, to a designated recipient. It also included a forwarding function that allowed the delegated account to call other external contracts.
Fifty authorizations, one matching nonce
At 20:20:59, the operator sent a Type-4 transaction to Binance 14. The transaction hash was 0xad9926…. It carried 50 EIP-7702 authorization messages pre-signed by the Binance 14 private key. The signatures covered consecutive nonce values from 18,914,775 through 18,914,824, and each delegated the wallet to the attacker’s sweeping contract.
Binance 14 was still processing customer withdrawals, so the attacker could not know the exact live nonce at the time of execution. The operator therefore sprayed signatures across a nonce window. Forty-nine of the 50 authorizations failed because their nonces did not match. One matched and took effect.
Normal Binance withdrawal transactions were still being sent from the wallet when the malicious delegation quietly took control of the address.
A single transaction drained about $2.5 billion
Three minutes and 24 seconds after the delegation became active, at 20:24:23, the operator triggered the sweeping call against Binance 14. The transaction hash was 0x53bd38….
The transaction moved 167,464 ETH, 1.615 billion USDT and roughly 60 other tokens to the attacker’s collection address, 0x5227f603C1eE34CE3C06eFe6477003BDfCCB2f8c. The address had no prior transaction history. After the sweep, Binance 14, which had held assets worth billions of dollars, retained only one ETH. Based on market prices at the time, the asset package was valued at about $2.5 billion.
Additional wallets signed transfers on four chains
Only 24 seconds after the first sweep, Binance 16 sent funds to the same collection address. The transaction hash was 0x51f263…. It transferred 28,005.6 ETH, 55.7 million USDT, 25.9 million RLUSD, 84.5 WBTC and five other tokens.
Over the following 12 minutes, Binance 55 on Optimism transferred 44.2 million OP. Four Binance hot wallets on Arbitrum transferred 74.6 million ARB and 8,426 ETH. Four more hot wallets on Avalanche transferred 1.81 million AVAX and 8.41 million USDT.
Those wallets did not contain smart-contract code. Each transfer was signed directly with the relevant wallet’s genuine private key and was mixed into the normal flow of customer withdrawals.
The delegation stayed active and drained later deposits
At 20:41:23, the operator used Binance 14, which was still delegated, to call Binance Hot Wallet 34, a Circle smart custody account controlled by Binance. The account address was 0xEe7aE8…. The attacker moved 780 million USDC from that account to the collection address in a transaction with hash 0xdc102d…. Another 43 million USDC was transferred afterward.
At 21:44, the attacker ran a second sweep against Binance 14. The transaction hash was 0x55ba4d…. It drained 200 million USDT and 13 other tokens that outside users had deposited into the address after the first sweep.
At 22:00, the malicious delegation was still present on-chain. Any new asset sent to Binance 14 without detection could be swept to the attacker’s address without another signature from the wallet.
How one leaked key became persistent control
Before EIP-7702, a stolen hot-wallet key generally created a race to move assets. The attacker had to sign transfers one by one. Once an exchange operations team noticed the activity, it could try to move the remaining funds by paying higher gas fees. Moving business operations to a new address would also leave the old stolen key with little practical value.
EIP-7702 changes that sequence. A single authorization valid at the target nonce can turn an EOA into a withdrawal program controlled by the attacker. The first sweep at 20:24 removed the existing balance, but the delegation remained attached to the address. At 21:44, the attacker drained more than $200 million in later deposits without obtaining a new signature from Binance 14.
Rotating the exchange’s internal business keys would not by itself remove the delegation, because the delegation was tied to the underlying address. The leaked key had to sign a new authorization explicitly resetting the delegation target to the zero address. Until that happened, assets entering Binance 14 remained exposed to the delegated code.
Blockaid said teams operating large EOA accounts should treat EIP-7702 authorization as a privileged action and place it under controls as strict as those used for cold-wallet withdrawals. They should monitor code-state changes at every hot-wallet address around the clock and prepare pre-signed revocation transactions. They should avoid keeping inventory at an address until its delegation status is confirmed safe. After a key compromise, they should clear the delegation on-chain before rotating keys or replenishing the wallet.
Any delegation transaction should also pass its full authorization list to the transaction review layer. If that list is stripped away, a dangerous delegation can look like a harmless blank call to a trusted address.
The broader security lesson
Private-key compromise remains a major source of losses in the public-chain ecosystem. If the public figures are confirmed, this incident would become the largest cryptocurrency theft on record, with reported losses more than three times the roughly $1.5 billion stolen from Bybit in February 2025.
Private keys from 11 Binance hot wallets signed transfers to an attacker address created only minutes earlier. One critical wallet also signed an EIP-7702 authorization, turning itself into a tool for long-term delegated draining.
Compliant stablecoin issuers froze about $2.4 billion in assets within two hours of the incident, according to the review, but the attackers still retained large amounts of ETH and other native assets that centralized issuers could not freeze.
At the blockchain level, a valid signature made with a stolen key is indistinguishable from a valid signature made with proper authority. The decisive controls are the policy checks applied when a signature is produced and the on-chain monitoring that can identify and stop abnormal fund movement during the first few minutes.
