I think the draft is close enough now that the recovery semantics can be specified more concretely.
The main point I would change is the role of SAFE_RECOVERY_TIME. It is useful as an admissibility boundary for recovery commitments, but I do not think it should function as the authority boundary itself.
Sergeev’s example still survives any fixed cutoff if the attacker obtained the ECDSA key before that cutoff. Moving the timestamp earlier can reduce exposure, but it cannot change what the timestamp proves. It establishes when a commitment entered canonical state, not whether that commitment represents the legitimate successor authority.
I would make the recovery path explicitly:
FROZEN → CLAIMED → RESOLVED | CONTESTED | UNRESOLVED → SUCCESSOR
where only RESOLVED may transition the account into successor authority.
A frozen account should have a protocol-derived recoveryEpoch. A recovery claim should commit to at least:
chainId
account
recoveryEpoch
recoveryPolicy
evidenceRoot
successorAuthority
claimNonce
The important property is that the claimant cannot choose a replay domain that makes stale evidence valid again. The recovery epoch belongs to the account state and changes when the authority state changes.
I would define something equivalent to:
claimHash = H(chainId, account, recoveryEpoch, recoveryPolicy, evidenceRoot, successorAuthority, claimNonce)
Every recovery proof or commitment should be bound to that exact claim.
The draft’s two current recovery paths then become evidence classes rather than separate definitions of authority.
A pre-cutoff recovery commitment establishes that a particular commitment existed in canonical state before SAFE_RECOVERY_TIME.
A seed or derivation proof establishes knowledge of material that derives the affected account and is not recoverable merely from the exposed ECDSA key.
Additional recovery mechanisms can be added later, but each should specify exactly what predicate it establishes. None should implicitly mean “therefore this claimant owns the account.”
Resolution is the operation that decides whether the admitted evidence is sufficient to authorize the proposed successor.
I think the minimum outcomes should be:
SUCCESSOR(successorAuthority) — exactly one successor satisfies the recovery policy.
CONTESTED — two or more mutually incompatible admissible successor claims satisfy enough of the policy that the protocol cannot safely select one.
UNRESOLVED — no claim satisfies the recovery policy.
Both CONTESTED and UNRESOLVED should leave the account frozen. They should not fall back to first-seen, oldest commitment, largest evidence set, or legacy ECDSA possession.
Successful recovery should then perform one atomic authority transition:
A_n → A_(n+1)
with the following properties:
- A_n is the exact frozen predecessor authority state.
- The accepted claim is bound to the current recoveryEpoch.
- The installed wallet or native key is exactly the successorAuthority committed by the accepted claim.
- Legacy ECDSA authority remains permanently disabled.
- The recovery epoch advances.
- Claims bound to the prior epoch can never execute afterward.
I would also avoid making evidence mutable underneath a claim. If the evidence set changes, that should produce a new evidenceRoot and therefore a new claim identity. A corrected or expanded evidence state should not rewrite the old one.
SAFE_RECOVERY_TIME can then be specified narrowly:
it determines whether the recovery-commitment evidence class is admissible;
it does not determine which claimant is authoritative.
This also gives us a clean answer to the case where later evidence suggests compromise began before the selected cutoff. We do not need to pretend the cutoff was the exact moment of compromise. The cutoff remains a containment/admissibility parameter, while successor authority is resolved from the admitted recovery state.
I would add explicit consensus tests for at least the following cases:
- attacker obtains ECDSA before SAFE_RECOVERY_TIME, registers a recovery commitment, then legitimate claimant presents independent derivation evidence;
- two eligible pre-cutoff recovery commitments propose different successors;
- valid seed proof and eligible commitment agree on the same successor;
- valid seed proof and eligible commitment disagree;
- claim uses the wrong recoveryEpoch;
- claim is replayed after successful recovery;
- claim changes only successorAuthority;
- claim changes only evidenceRoot;
- evidence is valid but insufficient under the selected recovery policy;
- account has only the compromised ECDSA key and no independent recovery evidence;
- recovery succeeds and an old ECDSA signature is subsequently presented;
- recovery succeeds and an old recovery claim is subsequently replayed.
The invariant I would make normative is:
Once legacy ECDSA authority can be reproduced by a quantum adversary, no capability derived from that compromised authority can, by itself, establish successor authority.
A second useful invariant follows from it:
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.
With those two invariants, the concrete ZK proof system, aggregation mechanism, and future recovery evidence classes can remain modular. We already have active work on alternative signature schemes and recursive STARK aggregation, so I would keep those as replaceable verification mechanisms rather than baking one proof construction into the authority semantics. EIP-7932 is designed around algorithm agility, and EIP-8288 is explicitly aimed at aggregating large PQ signatures and STARK proofs.
That would leave the EIP with a clean separation:
freeze = containment
evidence = what a claim can establish
resolution = whether the evidence authorizes this exact successor
successor transition = the only operation that restores execution authority
I think that closes the pre-cutoff attacker case without requiring us to know the exact moment at which quantum compromise first became possible.