This EIP modifies the ecRecover precompile at address 0x0000000000000000000000000000000000000001 to apply the EIP-3607 account-code restriction, except for delegation indicators specified by EIP-7702. After performing ECDSA public key recovery, the precompile returns the recovered address only if its current raw account code is empty, or exactly an EIP-7702 delegation indicator. Otherwise, it returns 32 zero bytes (the existing zero return value of ecRecover).
EOAs can use EIP-7702 as a bridge to post-quantum authorization. After migration, the account's non-empty code no longer matches the EIP-7702 delegation format 0xef0100 || delegate_address, so EIP-3607 disables its ECDSA transaction authority at the protocol level. However, ecRecover ignores account state. A quantum-capable attacker deriving the old ECDSA private key could still authorize token transfers through immutable contracts, including ERC-20 permit implementations (ERC-2612). This EIP applies the same rule to ecRecover: recovery returns zero when the account has non-empty raw code that is not a valid EIP-7702 delegation indicator. This prevents the old ECDSA private key from remaining usable through immutable contracts after the account has migrated to post-quantum authorization.
ecRecover BehaviorStarting at the activation of this EIP, the ecRecover precompile at address 0x0000000000000000000000000000000000000001 must perform the following steps:
(hash, v, r, s) as currently specified, yielding a recovered_address.3000 gas.3000 gas plus the EIP-2929 warm/cold account-access cost for recovered_address, then check whether its raw code is empty or a valid EIP-7702 delegation indicator, without following any delegation.recovered_address left-padded to 32 bytes.The check uses the raw account code stored in state for recovered_address, without following a delegation indicator. An absent account is treated as having empty code.
Thus, the recovered address is returned only when its raw code is empty or exactly 0xef0100 || delegate_address.
When ECDSA recovery fails, no state access is performed and the gas cost remains 3000.
When ECDSA recovery succeeds, the precompile must access the account of recovered_address to read its code. This access must follow the EIP-2929 warm/cold rules:
recovered_address is already in the transaction's accessed_addresses set, the additional cost is 100 gas.recovered_address must be added to the accessed_addresses set, making it warm for subsequent operations within the same transaction.Modifying ecRecover at the protocol level is chosen because many deployed contracts that rely on ecRecover for signature-based authorization (e.g., ERC-20 permit implementations) are immutable and cannot be updated to check the recovered account's code. A protocol-level change ensures these existing contracts automatically apply the same restriction without requiring redeployment.
When the recovered account does not pass the account-code check, the precompile returns 32 zero bytes rather than triggering an execution failure (success = 0). Currently, malformed v, out of range r/s, and failed recovery all return 32 zero bytes with success = 1, and ecRecover has never used execution failure to signal invalid input. Treating a disallowed recovered account as another form of "recovery failed" keeps this convention intact.
Furthermore, introducing an execution failure path would break deployed contracts that wrap ecRecover with a low level staticcall and require(success), turning a "signature not valid" result into an unexpected revert. Contracts that already check for a zero return will naturally reject disallowed accounts without any code changes.
Since the precompile now reads account state, the additional gas cost follows the existing EIP-2929 warm/cold access pattern for consistency with the rest of the protocol. This avoids introducing a new gas model. It also ensures that the cost of state access is fairly accounted for.
For addresses whose raw code is neither empty nor exactly an EIP-7702 delegation indicator, ecRecover now returns 32 zero bytes where it previously returned the recovered address.
On every successful ECDSA recovery, the precompile now performs an additional account access, adding 100 gas for a warm account or 2600 gas for a cold account to the base cost of 3000. Transactions that invoke ecRecover near their gas limit may fail with an out-of-gas error after activation. Recovery failures are unchanged.
When an account fails the account-code check, ecrecover returns the same 32 zero bytes used for an invalid signature, so contracts that already check for zero continue to behave correctly. Contracts that use ecrecover but do not verify the result is non-zero are already vulnerable to accepting invalid signatures.
This EIP only modifies the ecrecover precompile. Contracts that perform ECDSA recovery in application-level code (e.g., pure Solidity implementations) bypass the precompile and will not observe the account-code restriction.
Some systems re-execute ecrecover in a different context (different chain, different layer, or asynchronously at a later time) and assume it is a pure function of (hash, v, r, s). Because this EIP introduces a read of the recovered account's current raw code, that assumption no longer holds.
In particular, L2 fault proof systems that obtain the final ecrecover result by executing the L1 precompile may become incorrect when L1 and L2 state differ. An L2 adopting this EIP must recover the address and then apply the account-code check and EIP-2929 accounting using its own raw account code and transaction access status. Systems that need recovery to remain independent of account state must use a separate secp256k1 recovery implementation instead of this precompile.
Copyright and related rights waived via CC0.