Binance's Hack: Why Pausing Withdrawals Wasn't Enough
Binance paused withdrawals during its October 29 hack, but the attacker could still move assets. The exchange’s withdrawal system and the permissions already granted on Ethereum were separate things to shut down.
Binance’s November 3 initial report puts the impact at about $6.34 billion. It says an attacker accessed an internal wallet signing service and initiated transfers outside the normal withdrawal process.
On Ethereum, the attacker used EIP-7702 authorizations to delegate execution to malicious code. Binance says stopping its withdrawal and hot-wallet services didn’t invalidate that authority; additional onchain transactions were needed. It reports clearing one affected wallet’s delegation early on October 30.
The exchange says it is absorbing the loss. Its report described 98% of affected token assets as replenished by October 31, with less liquid assets still being purchased. Those are dated company statements, not a fresh audit of its reserves or a check of today’s withdrawal availability.
What an EIP-7702 authorization changes
An ordinary Ethereum account is controlled by its signing key. EIP-7702 lets that account authorize a pointer to code that runs in the account’s context. That can support useful features such as batching several operations or having someone else pay transaction fees.
The delegation persists beyond the transaction that installs it. Its safety depends on the code selected and the permissions that code enforces. Authorizing hostile code can therefore create an ongoing route to move assets.
The specification provides a way to clear delegation through a valid authorization targeting the zero address. That is a change to the account’s code, not an ordinary transfer of ETH to the zero address. Sending funds there isn’t a revocation procedure.
This mechanism needs a valid account authorization. It doesn’t mean anyone can take over an arbitrary Ethereum wallet just by calling a contract.
The missing question in a withdrawal pause
A pause tells you that one route has stopped accepting requests. The question is whether any other route still has permission to spend.
TRM’s investigation describes ordinary signed transfers on other chains as well as the Ethereum delegation. So blaming the whole theft on EIP-7702 would miss the wider signing-system compromise.
For a customer evaluating an exchange’s response, useful disclosures would answer:
- Which signing systems were compromised, and how were they isolated?
- Which outstanding permissions or signed instructions remained usable?
- What evidence shows those routes were disabled and replacement assets are available?
Those questions are separate from whether the company promises to cover the loss. Our earlier FTX lesson raised the limits of trusting a reserve claim. Here, even adequate assets would leave another question: can the systems controlling them prevent unauthorized spending?
A reassuring balance and a working emergency stop solve different problems.
