A withdrawal pause closes an exchange’s usual route for sending customer funds. It does not automatically cancel permissions already recorded on a blockchain. That distinction helps explain the Ethereum portion of the October 29, 2026 Binance theft.
Information checked on November 7, 2026. The intrusion timeline below is Binance’s preliminary account.
Internal accounts and blockchain observations answer different questions
Binance’s preliminary report links a malicious recruitment assignment to compromised workstations and access to wallet-signing operations.
Chainalysis describes on-chain Ethereum authorizations that let a Binance wallet execute attacker-deployed code. Other affected wallets appeared to make ordinary signed transfers. Blockchain observations can illuminate what accounts did; they cannot independently reconstruct an interview or everything that happened on a laptop.
Keeping these boundaries visible avoids turning two partial accounts into an apparently complete investigation.
A valid signature answers a narrower question
Ethereum’s transaction documentation explains how a signed instruction requests a change to network state. A signature lets the network authenticate the instruction under its rules. It does not give validators access to an exchange’s personnel records, internal approvals, or reasons for creating that instruction.
Consider an ordinary custodial withdrawal. A customer requests a transfer through the exchange. The exchange decides whether to approve it, and its infrastructure produces the blockchain instruction. The customer-facing decision and the network’s validation are separate stages. Our custodial versus self-custody explanation follows that distinction in more detail.
An illustrative failure is a signer receiving a malicious request through a route it trusts. The resulting signature can satisfy cryptographic verification even though the institution never intended the transfer. That example explains an authorization problem; it does not establish the undisclosed configuration of Binance’s signing systems.
MPC protects secret material; policy protects its use
Coinbase’s MPC library documentation separates cryptographic operations on key shares from the application’s responsibilities. The library can produce MPC signatures; it does not decide when signing should be allowed. Authentication, authorization, and incident handling belong to the surrounding system.
These are different protections. Distributing secret material makes extracting a complete key harder. Deciding which instructions the participants will sign requires controls over requests and permissions too.
Imagine a secure stamping machine. Preventing someone from removing the stamp is useful. It does not settle whether the paperwork entering the machine is legitimate. The analogy is limited—cryptographic participants do more than operate a physical stamp—but it separates theft of a secret from abuse of a signing process.
Coinbase’s description establishes a general design principle. It is not evidence that Binance used Coinbase’s library or the same policies.
Delegation changes what later calls can do
EIP-7702 lets a key-controlled Ethereum account authorize code at another address to execute in its context. The specification makes delegation persistent and provides a way to clear it through a valid authorization pointing to the zero address.
The authorized code matters. Delegating to code is a change in account behavior, not simply an instruction to send one specified payment. What a later caller can accomplish depends on the code and its checks.
Think of the difference between approving one delivery and authorizing a dispatcher to arrange later deliveries. Closing the original ordering desk does not itself remove the dispatcher’s authority. This is an analogy for persistence, not a description of Ethereum’s implementation.
In the incident, Chainalysis observed signed authorizations followed by calls that swept assets. That supports the on-chain part of the explanation. It does not make EIP-7702 the mechanism behind transfers on Bitcoin, Solana, or every other affected network.
Four responses address different problems
Binance reports that clearing the malicious Ethereum delegation required additional on-chain transactions.
| Response | What it addresses |
|---|---|
| Pause withdrawals | The exchange’s normal customer transfer route |
| Revoke delegation | Authority recorded in the Ethereum account’s state |
| Freeze affected tokens | Transfer restrictions available through particular token issuers |
| Replenish backing | The institution’s capacity to cover customer claims |
Chainalysis describes a race to freeze stablecoins before conversion into assets outside the issuers’ freeze controls. This is not a universal blockchain reversal mechanism.
Binance reported approximately $6.34 billion affected and $2.85 billion frozen or intercepted, subject to reconciliation and prices. Coverage, freezing, and recovery are separate outcomes; subtracting the frozen figure does not establish a final loss.
For a related example of controls acting at different boundaries, see how a bridge incident spread across several tokens. Here, the key reading question is specific: when a service says it has stopped transfers, which route or permission has actually been disabled?
