---
eip: 8425
title: Quantum Freeze and Account Recovery
description: Disables legacy ECDSA authorization and provides recovery paths for unmigrated accounts.
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
---

## Abstract

This EIP defines a freeze of legacy ECDSA authorization and two recovery paths for unmigrated accounts: 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.

The `ecRecover` precompile is removed from the same time.

### 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

An unmigrated account is an account with empty code or an EIP-7702 delegation indicator. After the freeze, it 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.

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.

## Backwards Compatibility

This EIP requires a hard fork. Existing ECDSA-signed transactions and precompile-based signature authorizations stop working, including signatures created before activation. Quantum-resistant transaction submission and wallet support are prerequisites for activation.

## Test Cases

TBD.

## Reference Implementation

TBD.

## Security Considerations

Owners who retain only the ECDSA private key and have no eligible recovery commitment cannot recover their accounts through this EIP.

In an extreme case, an attacker may have quantum key-recovery capability before it becomes publicly known. This would require social coordination for validators to agree on an earlier `SAFE_RECOVERY_TIME` before recovery is enabled.

Contracts implementing ECDSA verification without `ecRecover`, including delegated wallet code, are not secured by the precompile change

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).