EIP-8425 tightens who can recover after Ethereum drops `ecRecover`

Two commits to EIP-8425 landed on October 24 and narrowed the proposal’s recovery criteria. Which accounts qualify for post-ECDSA recovery, which don’t, and why the distinction matters for anyone building wallet software.

The proposal dates to September 27 and still needs a future hard fork before any of this takes effect. It defines two recovery paths, commitment-based and ownership-proof, and neither works for everyone. Accounts must have either empty code or an EIP-7702 delegation indicator to be eligible. Anything carrying regular deployed code — including accounts that came in through EIP-8298 — is explicitly excluded. Clear those requirements, and the original address ends up holding a quantum-resistant wallet.

Accounts with regular deployed code are excluded from the recovery paths described in the EIP. There’s no recovery path for that category.

The fork acts as the cutoff. EIP-8425’s language doesn’t hedge: for every block whereblock.timestamp >= QUANTUM_FREEZE_TIME, transactions authenticated by a secp256k1 ECDSA sender signature are invalid. Existing ECDSA-signed transactions stop working. So do precompile-based signature authorizations.

The second commit specifies that the precompile at0x0000000000000000000000000000000000000001 is removed at the same moment the ECDSA freeze kicks in. According to the EIP, leaving the precompile alive after the freeze would expose contracts that useecRecover for authorization to forged signatures, and preventing unauthorized asset transfers through that path takes priority over preserving functionality whose authentication assumptions no longer hold.

After the fork, contract-level signature checks that rely on this precompile can no longer authorize calls through that path.

No established connection to the EIP.