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.
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.
| 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.
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 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 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.
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 is limited to accounts with empty code or an EIP-7702 delegation indicator. Accounts with regular deployed code, including those migrated through EIP-8298, are excluded.
After the freeze, an account within this scope can recover through either of two paths:
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.
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.
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.
TBD.
TBD.
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.
ecRecoverRetaining 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 and related rights waived via CC0.