Ethereum Draft Would Let Wallets Permanently Disable EIP-7702 Delegation

Developer nicolashw has proposed an Ethereum protocol change that would let key-controlled wallets permanently disable EIP-7702 delegation, giving owners a way to reject smart-contract execution at their existing addresses.

The proposal, called **Permanent EOA Delegation Opt-Out**, was submitted Oct. 30 as a draft Core Ethereum Improvement Proposal in pull request #12600. It remains open and unmerged, with no EIP number assigned. Activation would require a network upgrade.

Under the existing EIP-7702 standard, an externally owned account, or EOA, can authorize a smart contract’s code to run as the account itself. Delegation persists until changed or cleared. Clearing it restores an account’s empty code but leaves the ability to delegate again.

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.