This EIP modifies the ecRecover precompile at address 0x0000000000000000000000000000000000000001 to respect EIP-7851 ECDSA authority deactivation. After performing ECDSA public key recovery, the precompile checks whether the recovered address has deactivated ECDSA authority. If so, it returns 32 zero bytes (the existing failure sentinel of ecRecover) instead of the recovered address.
EIP-7851 enables delegated EOAs (per EIP-7702) to deactivate their ECDSA authority, preventing that authority from signing transactions or new delegation authorizations. However, the ecRecover precompile is currently a pure cryptographic function with no awareness of account state. Even after an EOA's ECDSA authority is deactivated, on-chain signature verification through ecRecover continues to succeed for that authority. This affects contracts that rely on ecRecover for signature-based authorization, such as ERC-20 contracts implementing permit (ERC-2612). Since many such contracts are immutable and cannot be updated to add deactivation checks, modifying ecRecover at the protocol level is a practical path.
| Constant | Value |
|---|---|
ECRECOVER_ADDRESS | 0x0000000000000000000000000000000000000001 |
COLD_ACCOUNT_ACCESS_COST | 2600 |
WARM_ACCOUNT_ACCESS_COST | 100 |
ecRecover BehaviorStarting at the activation of this EIP, the ecRecover precompile at address ECRECOVER_ADDRESS must perform the following steps:
(hash, v, r, s) as currently specified, yielding a recovered_address.3000 gas.recovered_address and determine whether ECDSA authority is deactivated per EIP-7851.recovered_address has deactivated ECDSA authority, return 32 zero bytes.recovered_address left-padded to 32 bytes.An address is considered to have deactivated ECDSA authority if and only if its account code is exactly 0xef0101 || delegate_address, consistent with the ECDSA-disabled delegation prefix defined in EIP-7851:
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 WARM_ACCOUNT_ACCESS_COST (100).COLD_ACCOUNT_ACCESS_COST (2600), and 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 upgraded to incorporate deactivation checks. A protocol-level change ensures these existing contracts automatically benefit from ECDSA authority deactivation without requiring redeployment.
When deactivated ECDSA authority is detected, 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 deactivated authority 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 deactivated authorities 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 and ensures that the cost of state access is fairly accounted for.
For addresses whose ECDSA authority has been deactivated under EIP-7851, 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 either WARM_ACCOUNT_ACCESS_COST (100) or COLD_ACCOUNT_ACCESS_COST (2600) to the base cost of 3000. Transactions that invoke ecRecover near their gas limit may fail with an out-of-gas error after activation.
Contracts that use ecrecover but do not verify the result is non-zero are already vulnerable to accepting invalid signatures. This EIP maps deactivated authorities to the same failure sentinel (32 zero bytes) and therefore does not introduce a new class of vulnerability.
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 deactivation.
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 state read (the recovered address's account code), that assumption no longer holds.
In particular, L2 fault proof systems that accelerate ecrecover by executing the L1 precompile and caching the result may become incorrect. Mitigations include removing such acceleration, or migrating to a pure recovery primitive (e.g., implementing secp256k1 recovery inside the fault-proof VM or via a new dedicated pure-recovery precompile in L1), so that the accelerated operation remains a pure function of its inputs.
Copyright and related rights waived via CC0.