Ethereum draft proposes permanent EOA opt-out from EIP-7702 delegation

An unnumbered Core Ethereum proposal filed on October 30 would let an externally owned account permanently disable EIP-7702 delegation while retaining ordinary transaction origination. Pull request 12600 was open and unmerged when checked. Its specification is marked Draft, and adopting it would require a consensus change through a network upgrade.

The author, nicolashw, opened a discussion thread seeking feedback on the transaction format, account-code marker and integration details. The filing establishes a proposed mechanism, rather than an available wallet feature.

A restricted set-code transaction

The draft would reuse Ethereum's type-4 set-code transaction envelope. An empty authorization list would become valid only for a self-addressed transaction with zero value, empty data and an empty access list. Other empty-list forms would remain invalid.

That operation would install the candidate three-byte marker 0xef0200 without executing the account's previous delegate. Later delegation authorizations for the marked account, including authorizations that clear delegation, would be skipped. The proposal describes this state as permanent under its proposed consensus rules.

An accompanying change to EIP-3607 would let a marked account continue originating otherwise valid transactions. Calls to it would use empty executable code, while code-inspection operations would still expose the stored marker. Those are separate behaviors: an application checking raw code size would see three bytes, rather than an account with no stored code.

Encoding and compatibility remain open

The marker has not been assigned. The draft identifies a namespace overlap with EIP-8141's discussion of possible future key aliases. Its proposed fixed charge of 33,500 gas also remains subject to feedback and benchmarks.

The compatibility section identifies work for wallets, signers, RPC validation and account-classification logic. Ordinary transaction capabilities would remain, and existing token approvals and application-level permissions would not be revoked by the proposed operation. The document includes expected state-transition cases, expressly distinguished from results produced by an implemented client.