Published reporting says the Ethereum-side attack on Binance 14 used signed EIP-7702 authorizations that let the wallet delegate code execution. A transaction carried 50 variants with consecutive nonces, and the network applied the one matching the account’s current counter. This highlights the importance of signing controls; it does not, on its own, establish a vulnerability in Ethereum or EIP-7702.
What does EIP-7702 let an Ethereum wallet do?
EIP-7702 lets an externally owned account (EOA) sign an authorization for delegated code to execute in the context of that account.
Introduced as part of the Pectra upgrade, EIP-7702 adds a transaction type containing an authorization list. A signed authorization specifies code that may execute on behalf of an EOA. This expands what a conventional wallet can do, while making it especially important to verify what is being signed and to protect the systems that produce signatures.
The distinction matters: EIP-7702 does not mean an account can be switched to delegated code without an authorization signed by its controller.
How were EIP-7702 authorizations involved in the Binance 14 drain?
CoinDesk reported that a transaction contained 50 signed authorizations for consecutive Binance 14 nonces, and Ethereum applied the one matching the account’s current nonce.
A nonce is an account’s transaction counter. Because the counter changes as an account sends transactions, the prepared authorizations covered a sequence of possible values. That allowed the attacker’s transaction to include an authorization that matched when it was processed.
CoinDesk reported that delegated code was then called through Binance 14 and redirected assets. It also said the permission remained active for nearly four hours before it was revoked. This is a published account of the Ethereum portion of the incident, not a final technical report from Binance.
Was Ethereum or EIP-7702 itself vulnerable?
The available reporting describes the use of EIP-7702 delegation, but does not establish a vulnerability in the Ethereum protocol or the specification.
The specification requires an authorization’s signature and parameters—including its nonce—to be checked. The reported transaction therefore points to the use of valid authorizations, but it does not explain how the attacker obtained the ability to use them.
Binance said its investigation was ongoing and that it had identified additional compromise points. It characterized a possible connection to an employee laptop as an initial line of inquiry, not a final conclusion. Until a complete technical reconstruction is published, observed on-chain mechanics should be kept separate from unconfirmed theories about initial access.
What should exchanges review in their signing systems?
Exchanges should review not only private-key protection but also authorization policies, delegated code, nonce monitoring, and how permissions are revoked.
- Constrain what can be signed: use policies that check an authorization’s purpose, delegate address, and parameters before signing.
- Monitor authorizations: separately log the creation, use, and revocation of delegations, and look for unusual sequences of signatures.
- Verify account state: check active account permissions after transactions and promptly revoke unexpected delegations.
- Separate duties: restrict access to signing systems and treat their compromise as a distinct risk scenario.
These are general controls to consider when reviewing wallet architecture; they are not claims about which safeguards Binance did or did not have. The incident remains under investigation.
FAQ
What is EIP-7702 in simple terms?
It is an Ethereum feature that lets a key-controlled account sign an authorization for delegated code to execute in the account’s context.
Why were 50 authorizations included?
CoinDesk reported that they covered consecutive nonces so one could match the account’s current nonce when the transaction was included.
Does this incident prove EIP-7702 is unsafe?
No. It shows how a signed authorization can be used to delegate execution. The available evidence does not establish a vulnerability in Ethereum or the EIP-7702 specification.
Do we know how the attacker obtained the signatures?
Not from the cited material. Binance said its investigation was ongoing and that it had found additional compromise points; the full path to the authorizations remains unestablished in the available reports.