EIP-7851 Code-controlled EOA delegation
Hegota Declined for Inclusion · Account abstraction · EIP status Draft · created 2024-12-27
Lets an EOA delegated through EIP-7702 change its delegation target directly from wallet code and permanently disable the authority of its original private key (ECDSA). Adds a new delegation prefix 0xef0101 and the SETSELFDELEGATE instruction.
Why it is needed
EIP-7702 starts a delegation, in which a regular account (EOA) behaves like a smart contract, with a signature from the original private key (ECDSA). But once control passes to wallet code, the user operates the account through wallet-code means such as passkeys, multisig, or social recovery. Even then, the original private key stays alive and remains as residual authority: it can still sign transactions or change the delegation at will. In the current design, changing the delegation also requires a signature from the original key again, so wallet code cannot manage the delegation lifecycle on its own. This EIP lets wallet code update the delegation directly and opens a path to permanently burn (disable) the original key's residual authority.
What changes
Today
- Both starting and changing a delegation are authorized only by an ECDSA signature from the original EOA private key.
- Even when the account is operated through a passkey or multisig, the original private key's authority remains.
- There is no way to turn off the remaining original key authority.
After EIP-7851
- Wallet code changes its own account's delegation target directly with the SETSELFDELEGATE instruction.
- On the first call, the account code changes to the 0xef0101 prefix and the original key's ECDSA authority is permanently turned off.
- After the authority is turned off, wallet code can still keep updating the delegation.
Who is affected
- Users: You can operate the account using only wallet-code means such as passkeys, multisig, and social recovery while burning the original private key's residual authority. Once turned off, it cannot be undone.
- Wallet developers: SETSELFDELEGATE should be exposed only after explicit user confirmation and treated as a top-privilege operation.
- Client teams: Implementations must recognize 0xef0101 code as a delegation identical to 0xef0100 during execution, and as an ECDSA-disabled marker during validation.
- Node operators (transaction pool): The transaction pool must reject ECDSA-signed transactions when the sender account's code starts with 0xef0101, so an extra read of the sender account code may be added.
In depth
Two delegation prefixes: 0xef0100 and 0xef0101
The existing delegation indicator in EIP-7702 is 0xef0100 || delegate_address, and the 0xef0101 || delegate_address added by this EIP is an ECDSA-disabled delegation. ECDSA-disabled means the original ECDSA key can no longer authorize transactions or EIP-7702 delegation changes. It does not mean the delegation target is frozen forever. Wallet code can update the delegation target while keeping the ECDSA-disabled state. There is one irreversible invariant: once ECDSA authority is turned off, it is never restored. In delegated code execution, clients must treat 0xef0101 the same as 0xef0100, so the execution path itself does not change.
How the SETSELFDELEGATE instruction works
SETSELFDELEGATE(delegate_address) is self-only. The authority is defined as the current execution context address, and this instruction updates only the authority. It takes one item from the stack, interprets the low 160 bits as delegate_address, and pushes 1 on success or 0 if there is no state change. The execution logic has three steps. First, if delegate_address is address(0), it pushes 0 and does not change state. Second, if the raw code stored in the authority's state (not the code obtained by following the current frame's delegation indicator) is exactly 23 bytes and starts with 0xef0100 or 0xef0101, it writes code(authority) as 0xef0101 || delegate_address and pushes 1. Third, in all other cases it pushes 0. Each attempt consumes SETSELFDELEGATE_GAS (9500) gas, and execution in a static context must abort with an exception. State changes follow normal EVM revert semantics, so they are undone together if the frame or transaction reverts. The opcode value (SETSELFDELEGATE_OPCODE) is still TBD.
The update takes effect per frame
After a successful update, subsequent code-execution operations targeting the authority obtain the code to run by following the updated delegation indicator. The effect is frame-local. A frame that has already obtained its code and is executing keeps running that code, and if the authority is called again later in the same transaction (reentrancy), that call is a subsequent code-execution operation, so it loads code through the updated delegation indicator. Also, calling from an ECDSA-active delegation (0xef0100) sets the delegation while turning off ECDSA authority, and calling from an already disabled delegation (0xef0101) re-delegates while keeping the disabled state.
Validation rules: blocking signatures from disabled accounts
During EIP-7702 authorization processing, if the authority's current code is exactly 23 bytes and starts with 0xef0101, every authorization signed by that authority is treated as invalid and skipped. Also, an ECDSA-authenticated transaction whose recovered sender's code in the current state is exactly 23 bytes and starts with 0xef0101 is invalid and cannot be included in a block. The transaction pool must reject such transactions as well. The change in execution load is small. Execution paths that already resolve delegated code can reuse the existing delegation code lookup, and the transaction pool may need one additional read of the sender account code.
Rationale for 9500 gas
SETSELFDELEGATE_GAS is 9500, equal to EIP-7702's PER_AUTH_BASE_COST minus the 3000 gas allocated to recovering the authority address. This is because the instruction only writes one 23-byte delegation indicator to the current execution context account after the delegation has already been resolved. It does not verify a signature, does not process an authorization tuple, does not increment an account nonce, and does not touch any other account.
Security scope: blocks protocol signatures but not contract signature verification
This EIP invalidates only protocol-level ECDSA-authenticated transactions and EIP-7702 authorizations. When a contract verifies an ECDSA signature directly, as with a token's permit function, signatures from an ECDSA-disabled account are not automatically rejected. How the ecrecover precompile treats ECDSA-disabled accounts is addressed in the companion proposal, EIP-8151. Also, because entering the ECDSA-disabled state is irreversible, wallets should expose SETSELFDELEGATE only after explicit user confirmation and treat it as a top-privilege operation. Existing 0xef0100 delegations remain unchanged, so there is no backward compatibility issue.
Status: Draft, excluded from Hegotá candidates
This EIP is in Draft status, so the specification may still change and the opcode value is TBD. On the ACDE #245 call on September 10, 2026, it was declined for inclusion (DFI) in the Hegotá fork together with EIP-7819 (set delegate instruction). Both EIPs had client ratings below 1.0 and had no champion.