The Binance drain: delegation, freezes, and the evidence
How a compromised signing process can drain a wallet, why frozen funds are not recovered funds, and where the viral accounts go beyond the evidence.
What the evidence supports
The reported Binance theft on 29 October spans several networks and several methods of moving funds. EIP-7702 delegation explains an important Ethereum transaction path. It does not explain the Bitcoin or Tron transfers, and it does not explain how the attacker first obtained valid signatures.
Early reports put the outflow near $5.6 billion. Binance later estimated the total impact at about $6.3 billion and reported about $3 billion frozen. Those figures describe different stages of an active investigation. They should not be combined with earlier wallet balances to calculate an exact final loss. Binance’s preliminary update is the basis for the company’s figures here.
Three distinctions matter throughout this account: a valid signature is not proof of legitimate intent; a freeze is not a completed recovery; and a possible identity clue is not an arrest.
The first failure was access to signing
Binance’s initial investigation points to a compromised DevOps engineer’s laptop. It says this may have allowed access to an internal service container and the submission of unauthorized withdrawal transactions. It reports no evidence of a wallet private-key leak and has promised a technical report. The laptop’s initial compromise and the failed approval controls remain unexplained. Source: Binance.
This distinction matters. A protected key can remain inside its signing system while an attacker abuses the process that asks it to sign. Blockchain verification establishes that a signature matches a key. It does not establish that the request passed the owner’s intended business controls.
The public transaction record therefore cannot, by itself, settle whether a key was copied, a signing service was abused, or specific authorizations were obtained through another compromised process. Claims about an unrestricted hardware signing service require additional evidence.
What EIP-7702 added
EIP-7702 lets an ordinary key-controlled Ethereum account authorize a contract’s code to execute in that account’s context. The account must sign the authorization. The change persists until it is replaced or cleared. Malicious delegated code can move assets from the account when called. The caller need not be the account itself. Source: Ethereum specification.
A sweeper is code designed to transfer assets out. Delegating a hot wallet to a sweeper gives that code access to the wallet’s assets. New deposits may also be drained while that delegation remains active.
The reported batch contained 50 authorizations. A nonce is an account’s sequence number; a busy wallet keeps advancing it. Covering successive nonces can accommodate that movement. It does not defeat signature verification. Each authorization still needs a valid signature. Processing one valid entry increases the nonce, so more than one successive entry can take effect. Reported batch: Bitquery. Processing rules: EIP-7702.
The security question is how those signatures became available. EIP-7702 describes what an authorized account can do; it does not supply the attacker with authorization.
How delegation keeps the drain open
Select each stage to see how one authorization can allow repeated transfers. The model explains the mechanism; it does not reconstruct Binance’s hardware or show loss amounts.
One valid signature can install the malicious call path. Later calls can use it again. A new authorization can clear it, but that does not reverse transfers or secure a compromised signer. Source: EIP-7702.
This attack mechanism was documented before the incident
Qi and colleagues published EIP-7702 Phishing Attack on 13 December 2025. They describe how a deceptive authorization request can install persistent malicious delegation without exposing the victim’s private key. Their modified local Hardhat environment demonstrates activation by a self-call, an attacker’s call, and a call from another contract. The paper also examines ERC-4337 execution paths and public-chain activity. Source: research preprint, sections 3–6 and Appendix B.
The useful lesson is that stealing a key is not the only way to obtain a dangerous signature. The paper supplies prior research on this mechanism; it does not establish that phishing caused the Binance incident.
There is also a conditional cross-chain risk. An authorization with chainId = 0 can be accepted on multiple compatible networks, but the signed nonce must match on each network. Draining assets also requires suitable code at the delegated address. Reusing a wallet address alone does not make every chain compromised. Source: EIP-7702 validation rules.
The paper needs careful use. Its experiments emulate the protocol in a patched local environment. Section 2.2 describes delegation as temporary per transaction, contradicting its persistent-delegation account elsewhere. The official specification makes persistence clear. We use the paper as supporting research, not proof of every claimed effect or of this incident’s root cause. Source: sections 2.1, 2.2 and 5.1.
The reported transaction sequence
Blockaid describes attacker preparation, delegation of Binance 14 to a sweeper, and a major Ethereum drain at 20:24 UTC on 29 October. Its initial report put the first sweep near $2.5 billion. It also records a transfer from Binance 16 about 24 seconds later, including 28,005.6 ETH and several tokens. Source: Blockaid’s incident analysis.
Bitquery’s wider investigation reports outflows from 17 hot wallets across nine chains over several hours. It describes ordinary signed transfers on most affected wallets, alongside the Ethereum delegation path. This is why describing the entire theft as one EVM exploit is incomplete. Source: Bitquery.
Two popular explanations need care. First, the transfer from Binance 16 does not establish that an automatic refill script fed Binance 14. Second, valid-looking execution does not establish that internal alerts failed to fire. Both explanations require internal records. The public chain shows transfers and authorization changes, not the state of Binance’s monitoring systems.
Binance later said it revoked authorization for the affected address. A claim that the sweeper is “still” installed must name the wallet, chain and observation time. This article does not claim an independent live-state check. Source: Binance.
What the stablecoin freezes achieved
Tether and Circle reported freezing more than $1.5 billion in USDT and $800 million in USDC during the initial response. These were parts of the wider incident, not the amount deposited into Aave. Source: AP’s report of issuer statements.
Issuer controls can block transfers of their tokens at selected addresses. They do not give the issuer equivalent control over native ETH or BTC. Moving value into another asset can therefore change which controls are available to stop it.
But frozen assets are not automatically returned assets. A final accounting must separate gross outflows, blocked balances, funds returned to the rightful owner, and funds still under attacker control. It must also avoid counting a stolen token and the asset bought with that token as two separate losses.
The response demonstrates the power of centralized token controls. The same power that can restrict a legitimate holder can also interrupt a theft. Whether that control is acceptable is a design and trust decision; the freeze itself does not settle that debate.
The Aave loan was not a proven free loan
LlamaRisk’s 01:00 UTC update reports that an attacker-linked wallet supplied 60 million USDT to Aave and borrowed 19,762 WETH, worth about $44.6 million at the time. WETH is a token representation of ETH. The loan gave the attacker another asset while leaving collateral behind. Source: Aave governance incident report.
The same update valued the position at $59.9 million of collateral against $43.8 million of debt. It said the position remained overcollateralized and subject to normal liquidation. That contradicts the viral claim that Aave was necessarily left with unusable collateral and a loss.
Aave’s market freeze stopped new deposits and borrowing. Repayment, withdrawal and liquidation remained available. That operational restriction is different from an issuer blocking token transfers.
Abandoning a loan does not erase its debt or release its collateral. If collateral becomes genuinely unusable or insufficient, losses can arise. The report did not establish that outcome for this position. These are the report’s findings at its stated time, not a guarantee about later market conditions. Source: LlamaRisk.
A possible server trace is not a captured attacker
A later report, citing protocol engineer Justin Kalland, describes an attacker-linked wallet using MetaMask’s Gas Station despite already holding 2 ETH. It reports 175 million USDT in the wallet, not the 1.75 billion stated in some retellings, and a payment of 127.67 USDT for gas. The report presents a possible IP trail, not a confirmed identification or arrest. Source: BlockTempo.
The chain can show the gas funding and token payment. It cannot show whether the operator panicked, which option the interface selected, or what a server retained. Those claims require different evidence.
Consensys says some services process IP addresses and wallet-related request data. That establishes a possible privacy exposure. It does not prove that a raw request was stored in this incident, that the retained address identified the operator, or that investigators obtained it. Source: Consensys privacy notice.
Self-custody means control of signing keys. It does not mean that every service used by the wallet is private or decentralized. A transaction interface, network provider, or fee service can introduce a separate information boundary.
What should change after this incident
The following are engineering conclusions from the reported failure modes, not claims about Binance’s current implementation.
- Authorize the meaning of a signature. A signing system needs to distinguish a payment from a persistent change in account behavior. Protecting key material alone does not establish safe use of that key.
- Monitor account changes as well as transfers. A new delegation is a security event. Large outflows, unfamiliar destinations, and repeated drains also need independent review.
- Bound automated treasury movement. If refill automation exists, it should have loss limits and an independent stop condition. The presence of such automation in this incident is not established.
- Separate custody risk from network privacy. Holding your keys and limiting disclosure to service providers are different tasks.
- Keep an evidence ledger. Record the source, time, chain, asset and status for each figure. Mark assumptions explicitly.
A chain without this delegation feature removes this particular mechanism. It does not remove the danger of compromised keys or unauthorized signing. The reported BTC outflow is a direct reason not to treat “non-delegated” as a complete security guarantee.
The unresolved questions are specific: how the laptop was compromised; how withdrawal and delegation requests passed signing controls; what monitoring detected and when; whether any treasury automation contributed; how much value was actually recovered; and whether the MetaMask lead produced usable identity evidence.
Sources and reporting limits
This article synthesizes the sources below. It is not an independent audit of every transaction. Company statements, security-provider analysis, and secondary reporting are identified separately. The source timestamps matter because the incident was still developing.
- Binance: preliminary security update — official account; access hypothesis, impact estimate, and response.
- EIP-7702: Set Code for EOAs — primary technical specification.
- Qi et al.: EIP-7702 Phishing Attack — research preprint, version 1, 13 December 2025; prior mechanism research with experimental and technical limits described above.
- Blockaid: Binance incident analysis — security-provider transaction analysis; initial publication on 29 October.
- Bitquery: Binance hot-wallet investigation — blockchain-provider analysis; changing totals and delegation batch.
- AP: Binance flags potential security issue — secondary reporting of Binance and issuer statements.
- LlamaRisk: Binance Hot Wallet Exploit — Aave’s Response — protocol risk-provider report, updated 01:00 UTC on 30 October.
- BlockTempo: possible MetaMask Gas Station IP trail — secondary reporting of Kalland’s analysis; no confirmed arrest.
- Consensys privacy notice — provider policy; not evidence of incident-specific logs.