Durable Nonce

What Is a Durable Nonce?

A durable nonce is a persistent value stored in a special Solana account that allows a transaction to remain usable beyond the normal recent-blockhash expiration period.

Standard Solana transactions include a recent blockhash that is valid for only 150 slots.

A transaction that is not processed before its recent blockhash expires generally cannot be submitted successfully with the same signed message.

A durable nonce replaces that short-lived blockhash with a stored value that remains usable until the nonce account is advanced or otherwise changed.

This makes durable nonces useful for offline signing, delayed transaction submission, multi-party approval, cold-storage operations, scheduled workflows, and organizations whose signers cannot approve a transaction within a short period.

The official Solana durable nonce documentation explains that the mechanism removes the standard 150-slot expiration window by using a nonce value stored in an on-chain account.

A durable nonce does not make a transaction permanent under every condition.

The transaction becomes invalid if the stored nonce changes, the nonce account is closed, the required authority changes, or another transaction successfully consumes the same nonce value.

Why Solana Transactions Normally Expire

A standard Solana transaction contains a field named

.

The blockhash acts as a limited-time reference that proves the transaction was created recently.

It also helps prevent an already processed transaction from being submitted repeatedly.

Validators compare the transaction’s blockhash with the network’s recent blockhash queue.

The current Solana transaction pipeline accepts a normal blockhash only when its age falls within the maximum processing age of 150 slots.

Once the blockhash becomes too old, validators reject the transaction before executing its instructions.

This expiration protects the network from indefinite replay and limits how long validators must treat an ordinary signed transaction as potentially executable.

The limitation creates a problem when signing requires more time than the blockhash remains valid.

Why Durable Nonces Are Needed

Some cryptocurrency transactions cannot be created, approved, and submitted within a short online session.

A company may require signatures from employees in several countries.

A treasury may keep its signing keys inside an air-gapped computer that never connects directly to the internet.

A high-security operation may require a transaction to pass through technical, financial, and compliance reviews before broadcast.

A multisignature workflow may require several hardware devices to sign the same transaction at different times.

A payment application may prepare transactions during one operating period and submit them later.

Using a normal recent blockhash would require the complete message to be rebuilt and signed again whenever the blockhash expires.

A durable nonce allows the parties to sign one stable transaction message and submit it after the normal blockhash window has passed.

What Is a Nonce Account?

A nonce account is a special Solana account owned by the System Program.

It stores the state needed to support durable nonce transactions.

An initialized nonce account contains an authority public key, a durable nonce value, and the lamports-per-signature fee rate recorded when the nonce was last advanced.

The authority identifies the account that is permitted to advance, reauthorize, or withdraw from the nonce account.

The durable nonce value is a hash derived from a recent blockhash and stored for later use.

The fee-related value preserves information required by the transaction-fee process.

A nonce account must hold enough SOL to satisfy its applicable rent-exemption requirement while it remains active.

Applications should query the network for the current minimum balance rather than permanently coding an estimated amount.

Durable Nonce vs. Recent Blockhash

A recent blockhash is obtained from the network shortly before a normal transaction is signed.

It expires after the network’s limited processing window.

A durable nonce is written into an on-chain account and remains available after the blockhash from which it was derived is no longer recent.

A normal transaction does not need to create or modify a nonce account.

A durable nonce transaction must reference the nonce account and include a specific instruction that advances it.

Normal transactions are simpler and should generally be used when users can sign and submit promptly.

Durable nonces add account management, signing, transaction-size, fee, and operational requirements.

Durable Nonce vs. Account Sequence Number

The word nonce is used differently across cryptocurrency systems.

Some account-based blockchains use an increasing account transaction number to order transactions and prevent replay.

A Solana durable nonce is not a continuously increasing transaction count attached to every wallet.

It is a hash stored in a dedicated System Program account.

The value is placed in a transaction’s

field and replaced when the nonce is advanced.

Developers should not apply transaction-counter assumptions from another blockchain to Solana nonce accounts.

How a Durable Nonce Transaction Works

The process begins by creating and initializing a nonce account.

The creator assigns a nonce authority that will control future nonce operations.

The application reads the durable nonce value stored in the account.

It builds a transaction using that value in the transaction message’s

field.

The transaction places an

instruction first in its instruction list.

The required accounts sign the complete serialized transaction message.

The signatures may be produced offline because the stored nonce does not expire after 150 slots.

The signed transaction is transferred to an online system and submitted when the organization is ready.

A validator checks that the nonce account is valid, the stored value matches the transaction, and the nonce authority signed.

The nonce is advanced before the remaining transaction instructions execute.

The AdvanceNonceAccount Instruction

The

instruction tells the System Program to replace the stored nonce with a new value.

This instruction is essential to durable nonce replay protection.

The transaction runtime recognizes a durable nonce transaction only when

is the first instruction.

The nonce account must be provided in the required account position and must be writable.

The nonce authority must sign the transaction.

If the instruction is placed later in the transaction, the runtime may treat the transaction as an expired standard transaction instead of a valid durable nonce transaction.

The official nonce detection rules describe this first-instruction requirement.

Why the Nonce Must Advance

A durable nonce value must be usable only once.

Without advancement, an attacker or accidental process could submit the same signed transaction repeatedly.

Advancing the account replaces the old nonce with a new value derived from the current network state.

Any other pending transaction using the previous value then becomes invalid.

This means several signed transactions should not normally depend on one shared nonce value when all of them are expected to execute.

The first accepted transaction advances the account and invalidates the other transactions built with that old value.

Parallel delayed workflows should generally use separate nonce accounts.

Nonce Authority

The nonce authority is the public key authorized to control important operations involving the nonce account.

The authority must sign a transaction that advances the nonce.

It must also authorize a change to the nonce authority.

The authority is required when withdrawing funds from the nonce account.

The current System Program nonce account interface documents these authority requirements.

The authority does not need to be the same account as the transaction fee payer.

Separating these responsibilities can support organizational security policies.

The nonce authority should be protected because an unauthorized advance can invalidate a transaction that has already been signed offline.

Fee Payer vs. Nonce Authority

The fee payer is the account that pays the transaction’s base fee and any prioritization fee.

The nonce authority authorizes the consumption of the stored durable nonce.

One account can perform both roles, but the roles are logically separate.

A transaction can also require signatures from asset owners, token authorities, program administrators, or other accounts.

Every required signer signs the same transaction message.

Changing the fee payer normally changes the message and therefore invalidates existing signatures unless the workflow uses a future format specifically designed to separate these steps.

Offline Signing

Offline signing keeps private keys away from an internet-connected device.

An online system can gather account information and construct an unsigned durable nonce transaction.

The serialized message is transferred to an offline signing device through controlled media or another audited process.

The offline device verifies the transaction and produces the required signature.

The signed transaction is transferred back to an online system for submission.

The nonce remains valid during this process as long as the nonce account is not advanced or changed.

Offline signing reduces direct network exposure but does not protect against a maliciously constructed transaction.

The signer must verify the destination, amount, program addresses, token mint, authorities, fees, and every important instruction before signing.

Multisignature and Multi-Party Approval

Durable nonces are useful when several parties must sign one transaction.

A normal blockhash might expire while the message moves between signers.

Using a stored nonce gives each signer more time to inspect and approve the exact same message.

The final signature set can be assembled and broadcast after every required approval is present.

The process must preserve the exact serialized message because changing one instruction, address, fee parameter, or account flag invalidates the signatures.

The nonce account must also remain unchanged throughout the approval process.

Organizations should monitor the nonce account so they can detect an unexpected advance or authority change before submission.

Delayed Execution

A durable nonce permits delayed submission, but it does not schedule a transaction by itself.

The blockchain does not automatically execute the transaction at a selected future date simply because it uses a durable nonce.

A user, server, automation system, or relayer must still submit the signed transaction.

Applications that offer scheduled payments therefore require an off-chain scheduler or an on-chain scheduling design in addition to the durable nonce.

The submitting system should verify that the nonce remains current immediately before broadcast.

It should also verify that the intended business conditions still apply.

Transaction State Can Change Before Submission

A durable nonce transaction can remain signed while blockchain state changes around it.

Account balances may increase or decrease.

A token account may be frozen or closed.

A smart contract may be upgraded.

An oracle price may change.

A governance decision may alter program parameters.

A recipient account may no longer have the expected status.

The transaction’s signatures prove approval of the serialized message, but they do not freeze every external account or program state used during future execution.

Delayed transactions should include appropriate limits, expected values, deadlines, or program-level checks when the application supports them.

Replay Protection

Replay protection prevents the same signed instruction set from being executed repeatedly.

A normal Solana transaction relies partly on recent-blockhash expiration and the network’s processed-transaction tracking.

A durable nonce transaction relies on the nonce account’s one-time stored value.

Once a validator accepts and advances that value, the old signed message no longer matches the account.

Resubmitting the same transaction will therefore fail nonce validation.

This protection depends on placing the advance instruction correctly and requiring the proper nonce-authority signature.

What Happens When a Durable Nonce Transaction Succeeds?

The validator confirms that the stored nonce matches the transaction’s

.

It verifies that the nonce account is initialized and owned by the System Program.

It verifies that the nonce authority signed the transaction.

The runtime advances the nonce to a new value.

The remaining instructions execute in order.

If all required instructions succeed, their state changes and the advanced nonce are committed.

The transaction fee is deducted from the fee payer.

The old signed transaction cannot be executed again because its nonce has been consumed.

What Happens When Execution Fails?

Durable nonce failure behavior has an important difference from the simplified rule that every state change in a failed transaction is reverted.

If the transaction passes nonce and fee-payer validation but a later instruction fails, the ordinary instruction changes are rolled back.

The nonce advancement is still committed.

The transaction fee is also still collected.

The official Solana failure behavior documentation explains that this prevents the same signed transaction from being replayed until it eventually succeeds.

A failed durable nonce transaction therefore consumes its nonce.

The user must fetch the new nonce, rebuild the transaction, and collect new signatures before trying again.

What Happens When Validation Fails?

A transaction can fail before the nonce is considered valid.

Possible causes include a missing nonce account, an already consumed nonce, a stored value that does not match the transaction, or a missing authority signature.

When nonce validation fails at this stage, the transaction is dropped without executing its instructions.

Under the current documented behavior, no fee is collected and no state change is committed for this validation failure.

The application should identify the exact error rather than repeatedly broadcasting the same unusable transaction.

Confirmation and Retry Risks

A submitting application must determine whether the durable nonce transaction was processed successfully, processed with an execution error, or never accepted.

Blindly rebuilding and submitting a replacement can create an unintended duplicate business action when the original transaction actually succeeded.

Blindly resending the original transaction is also ineffective after its nonce has been consumed.

Applications should query transaction status and inspect the nonce account.

The system should distinguish transaction finality from successful instruction execution.

A finalized transaction record can contain an execution error.

Operational systems should reconcile expected balance and account changes instead of relying only on the existence of a transaction signature.

Transaction Fees

Every Solana transaction requires a fee paid in SOL.

The current Solana fee documentation describes a base fee of 5,000 lamports per signature plus an optional prioritization fee.

A durable nonce transaction requires the nonce-advance instruction and relevant account references, but it does not avoid ordinary signature fees.

Additional signers increase the base fee.

A failed transaction may still consume the nonce and charge its fee after it passes the relevant validation stage.

Applications should maintain enough SOL in the fee-payer account and enough rent-exempt funding in the nonce account.

Prioritization Fees

A prioritization fee can improve a transaction’s chance of being scheduled during high network demand.

It does not guarantee inclusion or successful execution.

Durable nonce transactions have a special instruction-ordering requirement when compute-budget instructions are included.

The

instruction must remain first.

Compute-unit price and limit instructions must not be placed before it.

The official Solana integration guidance warns that placing compute-budget instructions first can prevent the runtime from detecting the durable nonce transaction correctly.

Nonce Account Funding and Rent Exemption

A nonce account contains data and must maintain the network’s required rent-exempt balance while active.

The exact minimum should be obtained through the appropriate network query for the nonce account’s data size.

Partially withdrawing funds cannot leave the nonce account with a positive balance below the required rent-exempt minimum.

A transaction attempting to create that condition will fail.

Withdrawing the complete balance successfully closes the nonce account.

The current nonce withdrawal interface documents these balance rules.

Closing a Nonce Account

A nonce account can be closed by withdrawing its complete SOL balance through an authorized instruction.

The nonce authority must approve the withdrawal.

Closing the account invalidates every unsubmitted transaction that depends on its stored nonce.

Organizations should therefore check for pending signed transactions before withdrawing the full balance.

Records should identify which nonce accounts are active, which transactions use them, and which accounts are safe to close.

Changing the Nonce Authority

The current nonce authority can assign a new authority through an authorized System Program instruction.

Authority rotation can be useful after an employee departure, key migration, custody-policy change, or security incident.

A pending transaction requiring the old authority may become invalid after the authority is changed.

The new authority should be verified carefully before the change is submitted.

Assigning an incorrect or inaccessible public key can disrupt future use of the nonce account.

Authority changes should be documented and coordinated with every pending offline-signing workflow.

One Pending Transaction per Nonce Value

Several transactions can technically be prepared with the same stored nonce value.

Only one of those conflicting transactions can successfully consume that value.

The first accepted transaction advances the nonce and makes the others invalid.

A workflow that expects several delayed transactions to execute independently should create several nonce accounts.

Using one account for many pending transactions creates competition among those transactions rather than a queue.

A nonce account does not store a list of future transactions.

Durable Nonces and Cold Storage

Cold storage keeps important private keys away from normal internet-connected systems.

A durable nonce allows a cold signer to approve a transaction without racing against standard blockhash expiration.

The online construction system should be treated as untrusted because it can prepare a transaction that sends assets or changes authorities.

The cold environment must decode and display the complete transaction meaning before signing.

Organizations should verify program addresses, account permissions, fee settings, token mints, recipient addresses, and transaction amounts.

Transferring serialized transactions through removable media also requires malware controls and file-integrity procedures.

Durable Nonces and Treasury Operations

Crypto treasuries may use durable nonces for withdrawals that require several levels of approval.

A transaction can be prepared after an internal request and signed by authorized personnel in separate locations.

The final operator can submit it after confirming that every approval is complete.

Strong treasury procedures should connect each nonce account with one documented transaction request.

The organization should prevent one department from advancing or closing the nonce account unexpectedly.

It should also define what to do when the transaction fails after consuming the nonce.

Durable Nonces and Scheduled Payments

A durable nonce can support a scheduled payment by preserving a signed transaction until the selected submission time.

It does not enforce the schedule on-chain by itself.

A relayer could submit the transaction earlier than intended unless another mechanism prevents early execution.

Signers should not give a fully authorized durable nonce transaction to an untrusted party when execution timing is sensitive.

An on-chain program can provide stronger time conditions when it checks the network clock or another approved condition before releasing funds.

The chosen design should consider what happens if the scheduler becomes unavailable.

Durable Nonces and Smart Contract Transactions

A durable nonce can be used for transactions that call Solana programs, not only simple SOL transfers.

Delayed smart contract execution introduces additional state risk.

A swap price may change between signing and submission.

A lending position may become unsafe.

An account expected by the program may be modified or closed.

An upgradeable program may run different code by the time the transaction executes.

Applications should use explicit minimum outputs, maximum inputs, expected account states, and other protections where available.

Users should avoid signing an open-ended durable transaction supplied by an untrusted application.

Durable Nonces and Transaction Simulation

Simulation estimates how a transaction would behave against a particular observed blockchain state.

A successful simulation does not guarantee that a durable nonce transaction will succeed later.

The relevant accounts and program logic may change before submission.

The nonce may also be consumed between simulation and execution.

Applications should simulate near the intended submission time when practical and still rely on program-level safety limits.

Simulation results should not replace verification of the actual signed message.

Security Risks

The main durable nonce risks are key compromise, unauthorized nonce advancement, incorrect instruction ordering, stale account state, unsafe delayed execution, and poor transaction-status handling.

A stolen nonce-authority key can invalidate pending transactions or authorize account changes.

A malicious transaction builder can use the long validity period to obtain a signature for an action that will be executed under different future conditions.

An operator can accidentally consume a nonce through a failed transaction.

A retry system can create duplicate business operations when it does not confirm the original result correctly.

Security depends on both cryptography and the surrounding operational process.

Monitoring a Nonce Account

An application should read the nonce account before constructing a transaction.

It should record the account address, authority, stored nonce, intended transaction, and approval state.

The nonce should be checked again before submission.

An unexpected value indicates that the pending transaction is no longer valid.

An unexpected authority indicates a potentially serious operational or security event.

Organizations should alert on nonce advancement, authority changes, balance withdrawals, and account closure.

Monitoring should use an appropriate commitment level and should account for finality.

Current Protocol Status

Durable nonces remain documented and supported within the current Solana transaction system.

However, the official durable nonce page warns that the mechanism may be deprecated in a future release.

A Solana improvement discussion has explored a replacement transaction format that could preserve offline nonce workflows while reducing special validator processing.

A discussion or proposal is not the same as an activated network change.

Developers using durable nonces should monitor official specifications, client releases, activation notices, and migration guidance.

Long-lived institutional systems should avoid assuming that today’s transaction format will remain unchanged forever.

How Developers Should Implement Durable Nonces

Developers should use maintained Solana SDK and System Program interfaces rather than manually encoding nonce account state.

The application should query the nonce account and verify its owner, initialized state, authority, and current nonce.

The stored nonce must be placed in the transaction’s

field.

must be the first instruction.

The nonce authority and every other required signer must sign the exact message.

The system should store the serialized transaction and signatures without modifying them.

Before submission, the application should confirm that the account still contains the expected nonce and authority.

After submission, it should inspect transaction status, execution errors, nonce advancement, fees, and expected account changes.

How Users Can Use Durable Nonces Safely

Users should prefer a normal recent-blockhash transaction when delayed signing is unnecessary.

A durable nonce should be used through software that clearly identifies the nonce account and authority.

Offline signers should verify every instruction rather than approving an unreadable serialized message.

Pending transactions should be canceled by intentionally advancing the nonce when cancellation is required.

Users should understand that cancellation consumes the old value and invalidates every transaction built with it.

Nonce authority keys should be backed up and protected according to the value and operational role of the account.

Users should verify successful execution rather than assuming that nonce advancement means the intended transfer succeeded.

Common Durable Nonce Mistakes

One common mistake is treating a durable nonce as an increasing wallet transaction number.

Another mistake is placing a compute-budget instruction before

.

A third mistake is preparing several transactions with one nonce and expecting all of them to execute.

A fourth mistake is assuming that a durable nonce automatically schedules future execution.

A fifth mistake is ignoring blockchain state changes between signing and submission.

A sixth mistake is assuming that a failed transaction leaves the nonce available for another attempt.

A seventh mistake is closing or reauthorizing a nonce account while signed transactions remain pending.

An eighth mistake is resubmitting or rebuilding transactions without checking the original transaction status.

A ninth mistake is hard-coding the nonce account’s required rent-exempt balance.

A tenth mistake is assuming that current durable nonce behavior will never change in future Solana releases.

FAQ

What is a durable nonce in Solana?

A durable nonce is a persistent hash stored in a System Program account and used instead of a short-lived recent blockhash.

Why do normal Solana transactions expire?

They contain a recent blockhash that is accepted only within the network’s 150-slot processing-age window.

Does a durable nonce expire after 150 slots?

No, it remains usable beyond that window until the nonce account is advanced, closed, or changed in a way that invalidates the transaction.

Does a durable nonce make a transaction valid forever?

No, the transaction becomes invalid when its stored nonce is consumed or when required account and authority conditions no longer match.

What is a nonce account?

It is a System Program-owned account that stores the nonce authority, durable nonce value, and fee-related state.

Who controls a nonce account?

The designated nonce authority approves advancement, authority changes, and withdrawals.

Must the nonce authority pay the transaction fee?

No, the nonce authority and fee payer can be different signing accounts.

What instruction must appear first?

The

instruction must be the first instruction in a durable nonce transaction.

Can compute-budget instructions appear first?

No, they must not be placed before

in a durable nonce transaction.

Can a durable nonce transaction be signed offline?

Yes, offline signing is one of the mechanism’s main uses.

Does a durable nonce schedule a payment?

No, another system must submit the signed transaction at the intended time.

Can several transactions use one nonce?

Several can be prepared, but only the first accepted transaction can consume that nonce successfully.

How can several delayed transactions execute independently?

They should generally use separate nonce accounts and separate stored nonce values.

What happens after the nonce is used?

The nonce account stores a new value, and transactions signed with the old value become invalid.

What happens if a later instruction fails?

The ordinary state changes are reverted, but the nonce is still advanced and the transaction fee is still charged.

Can a failed durable nonce transaction be resubmitted?

Not after its nonce has been consumed, because the transaction must be rebuilt and signed with the new value.

How can a pending durable nonce transaction be canceled?

The authority can advance the nonce through another valid transaction, making the old signed transaction unusable.

Can changing the authority invalidate a pending transaction?

Yes, a transaction signed under the previous authority may fail after the account’s authority changes.

Does a nonce account need SOL?

Yes, it must maintain the applicable rent-exempt balance while it remains active.

Can funds be withdrawn from a nonce account?

Yes, but a partial withdrawal must preserve rent exemption, while withdrawing the complete balance closes the account.

Is a durable nonce a cryptocurrency token?

No, it is transaction state stored in a Solana System Program account.

Is a durable nonce secret?

No, the nonce account and its stored value are publicly readable on-chain.

Does knowing the nonce allow someone to steal funds?

No, the transaction still requires valid signatures from the nonce authority and every other required signer.

Can an attacker invalidate a signed transaction?

An attacker who controls the nonce authority could advance or alter the nonce account and invalidate pending transactions.

Does successful simulation guarantee later execution?

No, account state, programs, balances, prices, and the nonce itself may change before submission.

Are durable nonces more expensive than normal transactions?

They require additional account state and an advance instruction, while ordinary signature and prioritization fees still apply.

Are durable nonces currently supported?

Yes, but official documentation warns that the current mechanism may be deprecated in a future release.

Conclusion

A durable nonce allows a Solana transaction to remain usable beyond the standard 150-slot recent-blockhash window.

It works through a System Program-owned nonce account containing an authority, a stored hash, and fee-related state.

The stored nonce replaces the ordinary recent blockhash in the signed transaction message.

The transaction must place

first and must include the nonce authority’s signature.

Once the transaction is accepted, the nonce advances and the old signed message cannot be replayed.

If a later instruction fails, the intended state changes are reverted, but the nonce is still consumed and the fee is still charged.

Durable nonces are especially useful for air-gapped signing, treasury approvals, multi-party authorization, and delayed submission.

They do not automatically schedule transactions or protect signers from malicious instructions and changing blockchain state.

Safe implementation requires nonce monitoring, exact message preservation, clear transaction display, reliable status checks, and careful authority management.

Because the current design may change in a future Solana release, developers should monitor official protocol guidance and prepare operational systems for migration when necessary.