EIP-8476: Permanent EOA Delegation Opt-Out

EIPs EIPs core
1

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.

2

Reusing the 7702 envelope keeps this small, and the test cases already cover the ordering races I’d have asked about.

The marker only exists on the chain where the opt-out ran, while a 7702 authorization signed with chain_id 0 is valid anywhere its nonce matches. For a hot wallet that has only ever transacted on mainnet, an authorization at chain_id 0 and nonce 0 still works on every 7702 chain where that address never sent a transaction, whatever mainnet says. Security Considerations could say the guarantee is per chain, and that an owner who wants it has to opt out on every chain the key could be used on, including ones it never touched, which means funding gas there first.

On open question 4, a concrete case for Backwards Compatibility: OpenZeppelin’s ERC1155 calls onERC1155Received on any recipient with code, on every transfer and mint, and its ERC721 does the same in safeTransferFrom and _safeMint. A call to the marker succeeds with empty return data, that can’t be decoded as the expected selector, and the transfer reverts. So a marked account can’t receive ERC1155 tokens or safe ERC721 transfers from those contracts any more, and unlike a delegated account it can never add the hooks later. A treasury holding NFTs or 1155 positions would want to know that before taking an irreversible step.