The distinction matters for exchange hot wallets and treasuries whose controls assume they only sign ordinary transactions. As The Defiant previously reported, Binance co-CEO Richard Teng said the attacker in its breach used EIP-7702 to obtain execution approval over a hot wallet. “That delegation did not pass through our normal approval controls,” he said.
An onchain transaction recorded by Etherscan shows a single call to Binance 14 moving roughly 167,464 ETH and 1.615 billion USDT, alongside other tokens, to the attacker.
A One-Way Switch
The draft specification would repurpose a currently invalid form of EIP-7702’s type-4 transaction: a self-addressed transaction with zero value, no data and empty access and authorization lists. It would install a non-executable, three-byte marker, provisionally `0xef0200`, without running any existing delegated code.
Once installed, the marker would cause future delegation authorizations—including attempts to clear it—to be skipped. The account would retain its address, ordinary transfers and contract calls, while incoming calls would execute no code. The proposed fixed charge is 33,500 gas, which the author says has not been benchmarked.
The protection stops at delegation. A compromised private key could still transfer funds, grant token approvals or sign contract authorizations. Existing approvals would not be revoked. The draft also warns that opting out could disable delegation-dependent recovery or make assets requiring the old delegate’s code inaccessible.
Expiry Addresses a Different Risk
A separate draft from Joseph Delong, in PR #12601, would require each authorization to sign a block reference that is among the inclusion block’s preceding 256 ancestors. That would bound the window for applying unused authorizations, without expiring delegation already installed.
Another draft, EIP-7851, takes a different approach: permanently disabling the original signing key’s protocol-level authority while leaving wallet code able to update delegation. The new opt-out instead preserves the key’s ordinary transaction powers and removes delegation capability.
The opt-out’s design still needs compatibility work. Its marker encoding is provisional, and contracts or wallets that identify ordinary accounts by their lack of code could reject marked accounts. Wallets and hardware signers would also need to recognize the new transaction form and present it as irreversible.
Leave a Reply