Discussion topic for EIP-8151
Update Log
- 2026-02-09: initial draft
External Reviews
None as of 2026-02-09.
Outstanding Issues
None as of 2026-02-09.
2 Likes
EIP-7851 lets delegated EOAs (per EIP-7702) deactivate their private keys. However, the ecRecover precompile is a stateless function. This means even after a key is deactivated, on-chain signature verification via ecRecover still succeeds for that key.
Some immutable contracts rely on ecRecover for signature-based authorization. Examples include ERC-20 contracts implementing ERC-2612 permit (e.g., DAI) and Uniswap Permit2. These contracts cannot be upgraded to add deactivation checks.
EIP-8151 addresses this by modifying ecRecover at the protocol level: after recovering a public key, the precompile checks whether the recovered address has a deactivated key per EIP-7851. If so, it returns the zero address instead of the recovered address.
Limitation: This does not cover contracts that implement ECDSA signature verification in application-level code (e.g., pure-Solidity recovery), as those bypass the precompile entirely.
Thanks to @nicocsgy for the discussions on EIP-7851 modifications, sharing context on the post-quantum roadmap, and suggesting splitting this out as a standalone EIP. Thus this is proposed as a standalone EIP rather than folded into EIP-7851 to keep the two concerns cleanly separated.
Feedback welcome!
2 Likes
This would badly break existing deployments of the OP stack. In order to support ecrecover on the L2, the fault proof game executes the precompile on L1 and stores the result. See Fault Proof - OP Stack Specification. Since this happens asynchronously, you can do the following attack: take an EOA and call ecrecover on a signature made by that EOA on L2. After this transaction has been posted on L1 but before the batch is proven, deactivate the EOA on L1. Now ecrecover on L1 returns the zero address. Now you can challenge the batch with your transaction, and since ecrecover does not return what it did on L2, you will win the challenge and get paid.
I donât think there is a good way to fix this. Itâs possible to fix the OP stack, you would just need to not accelerate the precompile anymore. Thatâs awkward though. âUpgradingâ immutable smart contracts that use ecrecover is a noble pursuit, but unfortunately it looks like changing precompile behavior (beyond gas) in-place is a huge no-go.
2 Likes
Thanks for sharing, this is interesting. However, if L1 migrates to post-quantum address schemes, ecrecover effectively becomes redundant. In that case, wouldnât the OP Stack need to revisit or refactor this mechanism regardless?
On a long enough timeline, yes: weâre eventually all going to drop ecrecover at least in its current form. In the meantime, we have to be mindful deciding in what order we do things. This is a scenario where a backwards-incompatible change to the L1 EVM could force multiple L2s to upgrade in anticipation and add a lot of complexity to their codebase just so their bridge doesnât blow up. Most likely, even if we go down that route they would be able to upgrade and it would be fine, but itâs not very elegant in my opinion. With some probability there are other projects still.
Note that disabling on L1 does not disable on L2s as they are designed currently, because they have distinct EVM states. In my humble opinion, it would be better cost-benefit-wise to do EIP-7851 which doesnât have this issue, migrate off of ERC-2612 at the application/token level, and replace permit2. The result would be the same with less breakage and complexity. (Although some breakage is inevitable! As Vitalik said we are not going to put Ethereum up on the cross for absolute backwards compatibility)
I might be wrong, but it seems less doable to migrate off of ERC-2612 than to upgrade optimistic rollups. And arenât many OP stack chains expected to migrate to zk in the near future anyway?
1 Like
We should also consider disabling ecrecover entirely if quantum computing reaches the level where it can break ecdsa.
1 Like
Agree. Itâs a matter of timing. If itâs too early, it will DoS many current applications and cause backward-compatibility issues. If itâs too late, funds would be taken anyway by breaking ECDSA. This is exactly why EIP-8151 takes an account-level opt-in approach.
More broadly, a social edge case I can think of is the account of historical âdisappearedâ whales with public keys exposed, e.g., wallets whose private keys are not known to anyone (or rather, plausibly lost) but have signatures on-chain (think âSatoshi coinsâ as a rough analogy, though not on Ethereum). There are some wild and aggressive methods for globally disabling these accounts (both EOA and ecRecover) if these accounts donât take action to upgrade after a timed schedule, but such approaches are hard to justify. Or any better ideas on this?
1 Like
Once we have a new account scheme we should deprecate ECDSA by making it impossible to create new ECDSA accounts. The upgrade after that, we can disable all ECDSA signatures except ones that send all ether to quantum safe accounts. Some time after the quantum advent, we could prune these accounts from the state.
Related problems:
- secp256r1, used by WebAuthn passkeys
- BLS, used by Ethereumâs Proof of Stake
1 Like
I agree that this could be an endgame solution once a new account scheme is widely deployed.
My main concern is the social/legitimacy aspect of a protocol-level freeze of inactive / non-upgraded accounts.
That said, itâs a trade-off weâll likely have to face: after a quantum break, funds in legacy ECDSA accounts are either stolen by an attacker or frozen by the protocol (if the community reaches consensus to do so).
1 Like
Letâs assume the following situation:
(1) A person has approval orders through a permit.
(2) This person also has some funds that need to be withdrawn using the ECDSA key on the chain.
If we do not prevent ecrecover from recovering the address, the userâs funds may be threatened by (1). Conversely, the user cannot withdraw funds by (2). This requires specifying the level of detail of the prohibition in the ecrecover.
I know this is often impractical because the signature is usually a secondary access point alongside the main method based on msg.sender but itâs also worth considering.