Skip to content

Back to the catalog

EIP-8425: Quantum Freeze and Account Recovery
ethereum-magicians.orgthread

EIP-8425: Quantum Freeze and Account Recovery

A detailed reply on the Ethereum Magicians forum thread for EIP-8425 ("Quantum Freeze and Account Recovery"), which specifies how Ethereum accounts should transition authority when their legacy ECDSA key could be broken by a quantum adversary. The author formalizes a FROZEN/CLAIMED/RESOLVED-CONTESTED-UNRESOLVED/SUCCESSOR recovery state machine, replay-resistant claim hashes bound to a per-account recoveryEpoch, and two core invariants preventing a compromised ECDSA key from unilaterally establishing successor authority, closing an attack case where a quantum adversary obtains the key before the protocol's SAFE_RECOVERY_TIME cutoff. It also references related EIPs on signature-algorithm agility (EIP-7932) and PQ/STARK signature aggregation (EIP-8288).

TL;DR Ethereum Magicians thread hardens EIP-8425's quantum-account-recovery protocol with a formal claim/resolution state machine and anti-replay invariants against pre-cutoff ECDSA key compromise.
Document

What it is

A design-critique reply proposing that EIP-8425 restructure its quantum-recovery semantics around one distinction: **SAFE_RECOVERY_TIME should be an admissibility boundary, not an authority boundary.** The author's core objection is that Sergeev's attack — where an adversary obtains the legacy ECDSA key before the cutoff — survives any fixed timestamp. A timestamp proves only when a commitment entered canonical state, never whether that commitment is the legitimate successor. So the cutoff cannot be the thing that decides who owns the account.

How it works

The proposal separates four concerns that the current draft conflates:

  • freeze = containment
  • evidence = what a claim can establish
  • **resolution = whether evidence authorizes this exact successor**
  • successor transition = the only operation that restores execution authority

The draft's two "recovery paths" are demoted to evidence classes — each must state exactly what predicate it proves, and none may implicitly mean "therefore this claimant owns the account." A pre-cutoff commitment proves only that a commitment existed before SAFE_RECOVERY_TIME; a seed/derivation proof proves knowledge of material that derives the account and is not recoverable from the exposed ECDSA key alone.

Every claim commits to a fixed hash so a claimant cannot pick a replay domain that revalidates stale evidence:

claimHash = H(chainId, account, recoveryEpoch, recoveryPolicy,
              evidenceRoot, successorAuthority, claimNonce)

The recoveryEpoch belongs to account state and advances on every authority change; claims bound to a prior epoch can never execute afterward. Mutating an evidence set must produce a new evidenceRoot (new claim identity) rather than rewriting the old one.

Resolution has exactly three outcomes:

flowchart TD
    F[FROZEN] --> C[CLAIMED]
    C --> R[RESOLVED: one successor satisfies policy]
    C --> CO[CONTESTED: two+ incompatible admissible claims]
    C --> U[UNRESOLVED: no claim satisfies policy]
    R --> S[SUCCESSOR authority installed]
    CO --> F
    U --> F

Only RESOLVED transitions to successor authority. CONTESTED and UNRESOLVED both leave the account frozen — critically, they must not fall back to first-seen, oldest commitment, largest evidence set, or legacy ECDSA possession.

The successful transition A_n → A_(n+1) is atomic: it binds to the exact frozen predecessor state and current epoch, installs exactly the committed successorAuthority, permanently disables legacy ECDSA authority, and advances the epoch.

The two normative invariants

  1. Once legacy ECDSA authority can be reproduced by a quantum adversary, no capability derived from that compromised authority can, by itself, establish successor authority.
  2. Every value capable of changing the successor-authority decision must either be committed by the recovery claim or explicitly defined as external to the consensus decision.

These keep the ZK proof system, signature scheme (EIP-7932 algorithm agility), and STARK aggregation (EIP-8288) modular — replaceable verification mechanisms rather than semantics baked into authority.

What to do

If you are implementing or reviewing this EIP, add consensus tests for the enumerated cases the author flags as the hard ones — notably:

  • attacker obtains ECDSA before the cutoff and registers a commitment, then the legitimate claimant presents independent derivation evidence;
  • two eligible pre-cutoff commitments proposing different successors;
  • valid seed proof and eligible commitment that disagree;
  • claim using the wrong recoveryEpoch;
  • claim replayed after successful recovery;
  • claim mutating only successorAuthority, or only evidenceRoot;
  • evidence valid but insufficient under policy;
  • account with only the compromised ECDSA key and no independent evidence;
  • old ECDSA signature or old recovery claim presented after recovery succeeds.

Caveats

This is a forum proposal, not merged spec text — it argues the draft is "close enough" to specify concretely but is explicitly changing the role of an existing parameter. The author does not claim to have solved which proof construction or policy predicate to use; those are deliberately left modular. The value of the approach is that it "closes the pre-cutoff attacker case without requiring us to know the exact moment at which quantum compromise first became possible" — it does not detect compromise timing, only refuses to let compromised authority self-authorize.

Organisations named here

  • EIP-8425

Technologies named here

  • EIP-7932
  • Legacy ECDSA account authority
  • EIP-8288
  • Recursive STARK aggregation
  • Ethereum

Techniques named here

  • Quantum compromise of ECDSA key
  • Claim replay attack
  • Evidence mutation / evidence substitution
  • Pre-cutoff attacker registers recovery commitment