EIP Draft: Permanent EOA Delegation Opt-Out (disable EIP-7702)

Discussion thread for the draft Core EIP Permanent EOA Delegation Opt-Out.

PR: Add EIP: Permanent EOA Delegation Opt-Out by nicolashw · Pull Request #12600 · ethereum/EIPs · GitHub

Abstract

Allow an externally owned account (EOA) to permanently disable EIP-7702 delegation by installing a non-executable account-code marker. A narrowly defined, previously invalid form of a set-code transaction performs the opt-out. The account keeps its address and ordinary transaction capabilities, but no subsequent delegation authorization can replace or clear the marker.

Motivation

Some accounts (institutional wallets, exchange hot wallets, treasuries) do not need delegated execution, and their operational controls may assume it is unavailable. This proposal lets an owner remove that capability explicitly. It does not protect against ordinary private-key compromise: a key holder can still sign ordinary transactions and transfer funds.

Summary of the mechanism

  • Opt-out is a type-4 (set-code) transaction with an empty authorization list, destination == sender, value == 0, empty data and empty access list. This form is invalid today; every other empty-list form stays invalid.
  • It sets the sender’s code to the candidate marker 0xef0200 (exact 3-byte match), charges a fixed 33500 gas, and executes no EVM code.
  • The EIP-3607 exception is extended so a sender with exactly this code can still originate transactions.
  • EIP-7702 authorizations whose authority has the marker fail the code-eligibility check and are skipped (including clearing to the zero address).
  • Calls to a marked account execute as empty code; EXTCODESIZE/EXTCODECOPY/EXTCODEHASH see the raw marker.

Open questions

  1. 0xef0200 is provisional. EIP-8141’s rationale discusses a 0xef02 prefix for future key aliases, and EIP-7851 / EIP-8164 use adjacent 0xef0101 formats. Which prefix should this use?
  2. Is reusing the constrained empty-list type-4 form preferable to a dedicated transaction type?
  3. Is 33500 gas (21000 + 12500) a reasonable charge, pending benchmarks?
  4. Interaction with EIP-8151 and with contracts or wallets that classify accounts by empty code.

Feedback on the specification and the security framing is welcome.