--- eip: 8425 title: Quantum Freeze and Account Recovery description: Disables legacy ECDSA authorization and provides account recovery paths. author: Liyi Guo (@colinlyguo) discussions-to: https://ethereum-magicians.org/t/preparing-for-q-day-should-ethereum-standardize-account-freezing-and-recovery/29770 status: Draft type: Standards Track category: Core created: 2026-09-27 requires: 2929, 7702 --- ## Abstract This EIP defines a freeze of legacy ECDSA authorization and two account recovery paths: a recovery commitment registered before a trusted cutoff, or stronger ownership evidence such as a proof of knowledge of the original seed. Recovery installs successor authorization without restoring the legacy ECDSA path. Recovery algorithms are TBD. ## Motivation A practical quantum break of ECDSA could expose accounts that have not migrated, including accounts whose owners have lost access. Preparing freeze and recovery rules in advance reduces the implementation work needed during an emergency and gives owners a recovery path where suitable evidence remains available. ## Specification ### Parameters | Parameter | Value | Description | | --------- | ----- | ----------- | | `SAFE_RECOVERY_TIME` | TBD | Exclusive timestamp cutoff for eligible recovery commitments | | `QUANTUM_FREEZE_TIME` | TBD | Global Unix timestamp at which the freeze rules take effect | `SAFE_RECOVERY_TIME` is a consensus parameter selected before recovery is enabled. It is distinct from `QUANTUM_FREEZE_TIME` and must be no later than it, including if the freeze is brought forward. An unset cutoff disables commitment-based recovery. `QUANTUM_FREEZE_TIME` can be set in advance as a scheduled migration deadline. In an emergency, such as a demonstrated practical quantum break of ECDSA, validators and node operators may coordinate to bring this timestamp forward. The revised timestamp must be adopted consistently across the network before it takes effect. ### Freeze For every block with `block.timestamp >= QUANTUM_FREEZE_TIME`, transactions authenticated by a secp256k1 ECDSA sender signature are invalid. ECDSA authorization tuples from [EIP-7702](./eip-7702.md) can no longer install, replace, or clear delegation. Existing EIP-7702 delegation indicators are retained, and delegated code remains callable under the applicable execution rules. The `ecRecover` precompile is removed at the same time. This removal affects only the precompile behavior at `0x0000000000000000000000000000000000000001`. The account remains in the state with its balance, nonce, code, and storage unchanged. Calls to this address via `CALL`, `CALLCODE`, `DELEGATECALL`, or `STATICCALL` follow the ordinary account call rules, including those for gas, call depth, balance checks, static context, and reverts. Since the account has no code, a successful call returns empty return data. A successful `CALL` transfers any forwarded value, and a revert restores the balances to their values before the transfer. The address is removed from the set of precompiles that [EIP-2929](./eip-2929.md) adds to `accessed_addresses` at the start of transaction execution. Accesses and calls to the address are metered under the ordinary account rules of the active fork. ### Recovery Commitments Before the freeze, an owner can register a recovery commitment authenticated by the account's existing authority. Recovery commitment mechanisms are TBD. Commitment-based recovery uses the effective, unrevoked commitment for the account in the canonical state immediately before `SAFE_RECOVERY_TIME`. ### Recovery Recovery is limited to accounts with empty code or an EIP-7702 delegation indicator. Accounts with regular deployed code, including those migrated through [EIP-8298](./eip-8298.md), are excluded. After the freeze, an account within this scope can recover through either of two paths: 1. Commitment-based recovery: prove authorization under an eligible recovery commitment without relying on the legacy ECDSA private key. 2. Ownership-proof recovery: prove knowledge of the original seed, without revealing it, that binds to the account and cannot be obtained merely by recovering its ECDSA private key. This path does not require a prior commitment. Within this scope, a valid original-seed proof authorizes recovery even after key rotation or authorization changes. Verification algorithms and proof systems are TBD. Successful recovery installs a quantum-resistant wallet at the same account address. The owner must configure its signing keys as part of recovery. ## Rationale A separate commitment cutoff allows an earlier trust boundary than freeze activation. Evidence of an earlier compromise can inform selection of an earlier cutoff before recovery is enabled. Reports and offline evidence inform that coordination; clients do not adjudicate them or choose cutoffs independently. A scheduled migration deadline and an emergency response need the same freeze rules. This EIP therefore defines one freeze mechanism controlled by `QUANTUM_FREEZE_TIME`, which can be scheduled in advance or brought forward through network coordination. Recovery uses account code form and valid proofs because clients can evaluate these conditions consistently across wallet implementations and signature schemes. Existing delegations are retained so wallets that already support quantum-resistant authorization can be used through transaction types with quantum-resistant sender authorization. Disabling ECDSA-signed transactions alone leaves contracts that use `ecRecover` for authorization exposed to forged signatures. After a practical quantum break, preventing unauthorized asset transfers through this path takes priority over preserving functionality whose authentication assumptions no longer hold. ## Backwards Compatibility This EIP requires a hard fork. Existing ECDSA-signed transactions and precompile-based signature authorizations stop working, including signatures created before activation. Calls to the former `ecRecover` address follow the rules in the Freeze section: the account and its balance are preserved, and successful calls return empty return data. Quantum-resistant transaction submission and wallet support are prerequisites for activation. ## Test Cases TBD. ## Reference Implementation TBD. ## Security Considerations ### Account Recovery Owners who retain only the ECDSA private key and have no eligible recovery commitment cannot recover through this EIP. If a practical quantum break predates public disclosure, network participants may need to coordinate on an earlier `SAFE_RECOVERY_TIME` before enabling recovery. ### Removal of `ecRecover` Retaining `ecRecover` preserves compatibility with existing uses, but leaves contract-level ECDSA authorization exposed to quantum forgery. Applications that rely on it for authorization need alternative authorization or recovery paths. Assets whose only withdrawal path depends on the precompile may otherwise become inaccessible. Uses of `ecRecover` solely for computation, such as recovering an address from a signature, also require an alternative. Empty return data leaves the caller's output memory unchanged. Contracts that check only call success or read output without validating its length may therefore still accept unauthorized calls. Removing the precompile does not protect contracts that implement ECDSA verification independently. ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md).