Binance hack: what Ethereum code delegation reveals

An authorization adds functions to an account

Analysis of the Binance hack highlights an Ethereum feature: EIP-7702 lets an ordinary account designate code whose instructions it will execute. This delegation depends on an authorization signed by the account concerned. It can add programmable functions to a wallet, but its effect depends on the selected program. In the case studied by Hacken and other analysts, the account identified as Binance 14 was linked to a program designed to move its assets to the attacker.

The specification explains that delegation can persist beyond the transaction that installs it. The wallet therefore does not automatically return to its original behavior after the first execution. This gives revoking or replacing an authorization particular significance. It does not mean that every application using the feature is compromised: the risk depends on the authorized code and how the signature is obtained. EIP-7702 should not be described as simply a multisignature protocol.

The counter explains the authorization series

Hacken reports 50 authorizations prepared for consecutive values of the wallet’s counter. This counter, commonly called a nonce, helps order an account’s operations. An authorization applies only if its conditions match the expected state. For a frequently used operational wallet, that state can change between preparation and execution. A series of successive values therefore increases the opportunities to encounter the right value, without establishing that the network’s validation rules were bypassed or signatures forged.

That sequence does not, however, explain every transfer in the incident. The analyses distinguish the delegation observed on Ethereum from ordinary signed movements on other networks and from other wallets. Reducing the entire hack to this feature would leave out the multichain dimension. Public observations show what was authorized and executed; they do not directly reveal the internal organization of Binance’s systems, the access obtained beforehand, or every approval that should have stopped malicious instructions.

A valid signature does not reveal the entire intrusion

An extracted key and a hijacked legitimate signing system can both produce transactions carrying valid signatures. The blockchain allows that validity to be checked, but does not automatically distinguish those scenarios. Binance says its investigation has found no evidence of private-key leakage at this stage. That wording must retain its limited scope: it describes the operator’s provisional findings, without turning the absence of published evidence into definitive proof of what happened inside its systems.

A full technical report will need to connect public observations with internal evidence: the origin of access, privileges obtained, signing process, and withdrawal controls. Until then, the delegation used and the risks of a program authorized to act on an account can be explained without attributing an unestablished flaw to Ethereum. Obtaining the necessary authorizations remains the central question. Understanding their use helps reconstruct execution; it does not replace identifying the initial cause or checking every investigative hypothesis.