Durable Nonces on Solana: Pre-Signing Bot Txns That Never Expire

A recent blockhash on Solana is valid for exactly 150 blocks — roughly 60 to 90 seconds of wall-clock time depending on slot times. Sign a transaction with one, sit on it for two minutes, and the network rejects it with a BlockhashNotFound error the moment you try to submit. For most bots that's fine; you build, sign, and fire in the same tick. But the instant you want to pre-sign something and hold it — a scheduled exit, a hot-standby failover transaction, an offline signing ceremony — that 150-block ceiling becomes the wall you keep hitting. Durable nonces are the way through it.

Why the blockhash exists at all

The recent blockhash isn't decoration. It does two jobs: it gives every transaction a rough position in time so validators can reject stale submissions, and it acts as a replay guard. Because the blockhash is part of the signed message, the same signed bytes can't be replayed indefinitely — once the referenced hash ages out of the 150-block cache, that exact transaction is dead forever.

That replay protection is exactly what you lose if you naively "solve" expiry by just reusing an old blockhash. You can't. The validator won't find it. So Solana provides a purpose-built alternative that preserves the replay guarantee while removing the time limit: the durable nonce account.

What a durable nonce actually is

A nonce account is a small on-chain account (owned by the System Program) that stores a stored nonce value — which is itself a blockhash captured at the moment the account was last advanced. When a transaction's first instruction is AdvanceNonceAccount and it references that account's stored value in place of a recent blockhash, the runtime validates against the stored nonce instead of the 150-block cache.

The mechanics that make it safe:

• The transaction's recentBlockhash field is set to the current nonce value stored in the account, not a real recent blockhash.
• The mandatory first instruction advances the nonce, replacing the stored value with a new one derived from the current slot.
• Because advancing changes the stored value, the next durable transaction must reference the new value. That's the replay guard: each nonce value is single-use, in strict sequence.

So a durable-nonce transaction never expires on a clock. It expires only when someone advances the nonce — which invalidates every pre-signed transaction still pointing at the old value. That sequencing is the whole ballgame, and it's where teams get burned.

Setting one up

Creating a nonce account is a two-step ceremony. You need rent (~0.0015 SOL for the 80-byte account) and a designated nonce authority — the keypair allowed to advance or withdraw.

import {
  SystemProgram, Keypair, Transaction, Connection,
  NONCE_ACCOUNT_LENGTH,
} from "@solana/web3.js";

const nonceKp = Keypair.generate();
const rent = await conn.getMinimumBalanceForRentExemption(NONCE_ACCOUNT_LENGTH);

const tx = new Transaction().add(
  SystemProgram.createAccount({
    fromPubkey: payer.publicKey,
    newAccountPubkey: nonceKp.publicKey,
    lamports: rent,
    space: NONCE_ACCOUNT_LENGTH,
    programId: SystemProgram.programId,
  }),
  SystemProgram.nonceInitialize({
    noncePubkey: nonceKp.publicKey,
    authorizedPubkey: authority.publicKey,
  }),
);

To build a durable transaction later, fetch the account, read its stored nonce, and wire it up:

const info = await conn.getNonce(nonceKp.publicKey);   // stored blockhash + authority
const tx = new Transaction();
tx.add(SystemProgram.nonceAdvance({
  noncePubkey: nonceKp.publicKey,
  authorizedPubkey: authority.publicKey,
}));
tx.add(/* your actual swap / transfer instruction */);
tx.recentBlockhash = info.nonce;    // NOT a recent blockhash
tx.feePayer = payer.publicKey;
tx.sign(authority, payer);          // sign now, submit whenever

That signed blob is now valid until someone advances the nonce. Store it, ship it to a standby host, sit on it for an hour — it still lands.

Where durable nonces earn their keep in a bot

Three patterns come up constantly in production trading systems.

Failover execution. You run a primary executor and a hot standby. The standby holds a pre-signed emergency exit — say, a market sell that dumps a position if the primary goes dark. Without durable nonces you'd have to re-sign every 60 seconds, which means keeping signing keys hot on the standby. With a durable nonce, sign once and let the standby fire only if a heartbeat fails. This pairs naturally with the connection-resilience concerns covered in our write-up on how QUIC throttling causes silent transaction drops — a failover transaction is worthless if the standby can't get it onto a leader.

Scheduled and time-locked orders. Cron-style exits, TWAP legs that fire on a wall-clock schedule, or a stop that must execute at a specific slot range. You pre-sign the whole batch and dispatch on a timer. The same idea underpins a lot of automated exit logic in a Solana copy-trading bot, where you mirror a leader's position and want a guaranteed unwind path.

Offline / air-gapped signing. For strategies holding real size, the treasury key lives on a machine that never touches the internet. Durable nonces let that machine sign a transaction that a separate, online relay submits minutes or hours later. This is standard practice for the settlement leg of a Solana market-making operation.

The gotchas nobody warns you about

One nonce, one in-flight transaction. Because advancing invalidates the old value, you cannot have two pre-signed transactions racing on the same nonce account — the first to land kills the second. If you need N concurrent pre-signed txns, you need N nonce accounts. Bots that pre-sign a fan-out of exits routinely maintain a small pool of nonce accounts and round-robin through them.

Fee-payer and nonce-authority can differ, and usually should. Keep the authority key cold; let a cheap, rotatable fee-payer cover lamports. Just remember both signatures are baked in at sign time, so a fee-payer whose balance later drops to zero produces a transaction that fails at submission, not at build.

Priority fees are frozen at sign time. This is the big one for anything latency-sensitive. A durable transaction you signed an hour ago carries whatever compute-unit price you set then. If the network heated up in the meantime, your pre-signed txn is underpriced and won't land. For sniper or MEV and arbitrage flows this is disqualifying — durable nonces are for scheduled certainty, not for winning a fee auction. If landing priority matters, you also want to understand stake-weighted QoS and how it gates transaction priority before relying on any pre-signed fee.

The advance instruction must be first. Not second, not after a compute-budget instruction. If you're used to putting SetComputeUnitPrice at index 0, that ordering breaks durable nonces. The runtime specifically checks position zero.

When to reach for it

Use durable nonces when the value is survivability over time: failover safety nets, scheduled unwinds, cold-key settlement. Skip them when the value is speed right now — for that you want fresh blockhashes, aggressive fee bidding, and direct leader delivery, ideally on the kind of dedicated routing described in our low-latency infrastructure work. The two approaches aren't competitors; a mature bot uses fresh-blockhash paths for entries and keeps a durable-nonce safety layer underneath for the exits it can't afford to miss.

If you're building an execution stack that needs a guaranteed failover path, our team at TierZero designs exactly this kind of resilience into every Solana market-making system we ship.