A mempool dependency that EIP-8151 adds to ecrecover. It came up as Q6 of a pre-ERC on adopting code via SETCODEFROM (Pre-ERC: Adoption Profile and Reference Kernel for EOAs Adopting Code via SETCODEFROM), and @colinlyguo agreed it needs the EIP-8141 authors (Pre-ERC: Adoption Profile and Reference Kernel for EOAs Adopting Code via SETCODEFROM - #4 by colinlyguo), so I’m bringing it here.
The dependency. Under EIP-8151 (CFI for Hegotá), ecrecover reads the raw code of the recovered address and returns empty output when that code is regular code, i.e. neither empty nor a 7702 delegation indicator. So a validation prefix that calls ecrecover now depends on the code of a third-party account, the recovered address. With EIP-8298, that account can adopt regular code, after which the same call returns empty output and the validation result flips.
Where the current text stands. The policy summary allows dependencies on transaction fields, the expiry timestamp, the sender’s nonce, code and storage, the factory, the paymaster, and the code of contracts reached via CALL*/EXTCODE*, and says any other dependency on third-party mutable state must be rejected. The ecrecover read is none of those: it happens inside the precompile, and the recovered address is usually an EOA. Read literally, the rule rejects every prefix that recovers a non-sender address once EIP-8151 and EIP-8298 are both active. Read as intended, the dependency is simply untracked: Revalidation names code changes for the sender, the payer and canonical paymaster instances, and a recovered address is not among them.
Two properties that shape a fix.
- The address is known only when the precompile returns, so it can’t be derived from the frame structure or from the trace’s
CALL*/EXTCODE*targets. It would have to be recorded from the trace, as sender storage slots are. - The canonical paymaster authorizes with a single secp256k1 signer via
ecrecover, and it is admitted by code match and exempt from the trace rules, so trace recording alone wouldn’t cover it. Its signer’s code would need to be added to the paymaster-specific revalidation list explicitly.
Bounding. One adoption at a signer address invalidates every pending transaction whose validation recovered that address, e.g. everything sponsored by a canonical paymaster instance whose signer migrates. EIP-8298’s rule bounds the adopter’s own pending transactions, not those of others that recovered it. The closest precedent seems to be EIP-8298’s rule for DELEGATECALL code (track the code hash as a dependency, cap the pending transactions that depend on it), with the recovered address in place of the code hash.
Question. Should the mempool section (a) record recovered addresses as a tracked dependency, revalidate when their code changes, and cap pending transactions per recovered address, and/or (b) say that signature verifiers used in validation must not depend on account state, which under EIP-8151 rules out ecrecover for anything but the sender? The pre-ERC takes (b) for its own verifiers (ERC-7913 only says SHOULD), but the canonical paymaster needs (a) either way.