Durable Nonce
Transaction primitives
A durable nonce is a special account owned by the Solana System Program that stores a stored hash. Transactions can use that stored hash in place of a recent blockhash. The transaction stays valid until the nonce account is advanced, which lets you sign now and submit later without the usual 150-slot expiry.
Detailed explanation
Normal Solana transactions reference a recent blockhash. The runtime rejects them after 150 slots, roughly 60 to 90 seconds. Durable nonces relax that constraint by replacing the blockhash field with the value stored on a nonce account. The nonce account's authority controls when that stored value rotates. Until rotation, the same "blockhash" is reusable and your signed transaction stays valid.
Three System Program instructions manage the lifecycle: InitializeNonceAccount (sets the authority and the first nonce), AdvanceNonceAccount (rotates the stored nonce, must be the first instruction in any transaction using the nonce), and WithdrawNonceAccount. The System Program ID is 11111111111111111111111111111111.
The most common use case is offline signing: a hardware wallet or multisig signs a transaction days in advance, then a relayer broadcasts it when conditions are right. Without a nonce, the transaction would expire before broadcast. Treasuries, custody providers, and CCIP-style cross-chain relays all depend on this.
One opinion: durable nonces are underused by application teams who think "we just need to sign and broadcast immediately." When you run into priority-fee storms during congestion, the ability to pre- sign and fan-broadcast a nonce-anchored transaction is real insurance.
One subtle gotcha: a transaction using a durable nonce must list the nonce account as the first writable, non-signer account, and the AdvanceNonceAccount instruction must be its very first instruction. Skip either rule and the runtime falls back to treating the blockhash field as a normal recent blockhash, which means your transaction expires in 150 slots after all. Anchor and most modern wallets handle this; hand-rolled transaction code often does not.
When you'll see this
Look at any Solana custody provider, validator vote setup, or advanced trading bot. The first instruction in a durable-nonce transaction is always SystemProgram::AdvanceNonceAccount, with the nonce account passed as a writable account and the authority as a signer.
How NoLimitNodes uses this
Durable nonce flows run through the System Program, which our Solana system events stream parses end to end. You can subscribe to nonce-account creates and rotations and tie them back to the authority key. The full submission path also runs over our RPC nodes.
Related terms
- Compute Unit Budget · The CU limit and price you set with the ComputeBudget program to control how much work and priority fee a transaction uses.
- Jito Tip · A SOL transfer to a Jito tip account that pays the block engine to include and order your transaction bundle.
- Processed, Confirmed, Finalized · The three Solana commitment levels, ordered from "this validator saw it" to "supermajority will not roll it back."
- Program Derived Address · A PDA. An off-curve address derived from seeds plus a program ID, signable only by the program that owns it.
- IDL · An Anchor Interface Definition Language file. JSON describing a program’s instructions, accounts, and event layouts.