Offline signing and durable nonces solve different problems. Offline signing keeps a private key away from the network while a transaction is authorized. A recent blockhash or a durable nonce determines how long that signed transaction can remain usable. You can sign an ordinary Solana transaction offline, but it still expires when its recent blockhash ages out. A durable nonce is useful when signing, approval, or transport may take longer than that window.
For most wallet users, nothing needs to change right now. The Solana Foundation says durable-nonce deprecation is still in development as of October 2026, with no mainnet removal date; ordinary transactions are unaffected. Only people and services that actually use durable nonces need to track the migration.
As an Amazon Associate I earn from qualifying purchases.
Offline signing and a durable nonce answer different questions
Think of a Solana transaction as a set of exact bytes that every required signer approves. Offline signing describes where the signature is created: a hardware device, air-gapped computer, or other signer can authorize those bytes without connecting to the internet. It does not change the transaction’s lifetime.
Recommended Free Tools
The transaction’s lifetime comes from the value in its recent_blockhash field. In a normal transaction, that value is a recent blockhash held in the validators’ processing queue. In a durable-nonce transaction, it is a value stored in a nonce account. The signer can be offline in either case.
#1 Best Overall
- Effortlessly build your crypto portfolio via the all in one Ledger Wallet app: buy, sell, send, receive, swap, stake and more across popular blockchains. 15,000+ coins & tokens in a single dashboard. Keep a close eye on the market. Compare service providers. Track performance. Get timely alerts. Build your portfolio with confidence.
- Enjoy Bluetooth connectivity, iOS access, and hours of battery use with this mobile-first, secure backup signer. Freedom you can depend on.
- Genuine Check: confirm your signer is authentic during setup with the Ledger Wallet app.
- Protect your signer: keep it in mint condition at all times with a bespoke Pod or Case to avoid scratches and everyday wear and tear.
Solana’s documentation puts the practical distinction plainly: For workflows that may take longer or include offline signers, use a durable nonce.
Read the full explanation in Partial Signing. The wording means a nonce is an option for long or coordinated workflows, not a requirement for every offline signature.
Can I sign a Solana transaction offline without using a durable nonce?
Yes. A connected coordinator can construct a normal transaction, obtain a recent blockhash, pass the unsigned message to an offline signer, and later transmit the signed bytes to the network. The coordinator and signer must preserve the message exactly and complete all signatures before the blockhash expires.
What the offline signer actually approves
Each signer approves the serialized message, not an editable draft. That message includes the fee payer, recent blockhash or durable nonce, account addresses, account permissions, instruction order, instruction data, and every other field covered by the Solana message format. A device may display a human-readable interpretation, but the signature is over the exact bytes.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →If anyone changes the fee payer, blockhash, nonce, destination, amount, instruction, account list, or ordering after a signature is collected, the old signature no longer matches. The transaction must be serialized again and every affected signer must sign the new bytes.
What an offline setup must provide
- A way to move the unsigned message to the offline signer and return the signature or signed transaction without exposing the private key.
- A connected coordinator that can fetch a current blockhash, submit the final bytes, and report confirmation or rejection.
- A signer or wallet that understands the exact Solana transaction type being used and shows enough information for the operator to verify it.
- A plan for expiry: normal transactions must be submitted while their recent blockhash remains processable.
Solana documentation confirms that a hardware device or offline signer can sign the same frozen message bytes, but it does not certify compatibility for every retail wallet, device, SDK, or transaction instruction. Verify the specific combination before relying on it for a high-value or operationally critical workflow.
How long does an offline-signed Solana transaction remain valid?
An ordinary offline-signed transaction remains valid only while its recent blockhash is accepted by the network. The current transaction-pipeline documentation describes a 150-slot processing-age limit. Slots are a protocol unit; do not treat 150 slots as a fixed number of seconds because slot timing and network conditions can vary.
The expiry clock starts with the blockhash used when the message was built, not when an offline device finishes signing. Time spent waiting for multiple approvals, transporting a QR payload, or resolving an internal review therefore consumes the same validity window.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsWhat happens when the blockhash expires?
If the transaction reaches a validator after its blockhash has aged out, it cannot be processed as that transaction. You cannot repair it by editing the old signed bytes or replacing only the blockhash: the blockhash is part of the signed message. Fetch a new blockhash, rebuild the message, and collect all required signatures again.
Rank #2
- Simply & securely take control of your digital assets and identity with the all-in-one Ledger Wallet crypto app and Ledger Flex touchscreen signer.
- Digital asset control at your fingertips: manage 15,000+ crypto across multiple chains. Earn rewards. Top up & share with ease. Explore DeFi with confidence. Collect and showcase NFTs. Make informed choices with clarity.
- Connect effortlessly with Ledger Wallet: pair your secure Ledger signer with the all in one Ledger Wallet crypto app to manage thousands of digital assets across multiple devices and accounts with Ledger Sync from a single, secure dashboard.
- Cutting-edge design: monitor the market, compare rates, and Clear Sign transactions on the secure, high resolution, 2.8'' E Ink touchscreen.
- This is what security feels like: Ledger touchscreen signers all come with a private, offline, PIN-protected backup, Ledger Recovery Key, to never lose access to your assets.
When a recent blockhash is the right choice
- The signer and submitter can coordinate within the current blockhash window.
- The workflow has few signers and little chance of network or approval delay.
- You want the standard transaction path and do not need a nonce account or nonce authority.
- A transaction is generated and submitted immediately after signing.
For these cases, a durable nonce adds state and coordination without solving a problem you have.
What is a Solana durable nonce?
A durable nonce is a stored lifetime value held in a nonce account. The account is owned by the System Program and, when initialized, contains an authority public key, a durable nonce value, and the lamports-per-signature fee rate recorded when that nonce was last advanced. A transaction uses the stored value in place of a recent blockhash.
The special transaction format is important. The first instruction must be AdvanceNonceAccount. The transaction’s recent_blockhash field is set to the nonce value read from the account. The nonce authority must sign, and the account must be initialized, match the value in the message, and be able to advance.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Durable-nonce processing, step by step
- Create and initialize a nonce account. Assign an authority public key and fund the account as required by the current Solana tooling and account rules. The official Solana CLI reference follows Agave v4.2.1 and documents the available nonce-account commands.
- Read the current stored nonce. Treat it as shared state. Another authorized transaction can advance it before your transaction is submitted.
- Build the message. Put
AdvanceNonceAccountfirst, use the stored nonce asrecent_blockhash, set the fee payer, and add the application instructions. - Freeze and distribute the exact bytes. Send that message to each offline or remote signer. Every signer must approve the same serialization.
- Submit the fully signed transaction. The validator recognizes the nonce format from the first instruction and checks the nonce account, stored value, authority signature, and advance conditions.
- Advance before executing the rest. Once nonce validation succeeds, the validator advances the nonce before instruction execution. The application instructions then run against that new state.
The nonce lets the transaction wait longer than a recent-blockhash transaction, but it is not an unlimited reservation. It remains usable only until the account is advanced or otherwise no longer matches the signed value.
Recent blockhash versus durable nonce for offline signing
| Question | Recent blockhash | Durable nonce |
|---|---|---|
| What does “offline” describe? | The signer creates a signature away from the network; a connected device or coordinator later submits the bytes. | The same separation applies. The signer can remain offline while a coordinator handles submission. |
| What sets lifetime? | The validator recent-blockhash queue; current pipeline documentation describes a 150-slot processing-age limit. | The stored nonce remains usable until it is advanced, consumed, or no longer matches the transaction. |
| What must be coordinated? | All signatures and submission must finish before the blockhash expires. | The nonce account, its authority, and the unconsumed nonce value must remain valid while the transaction is pending. |
| What is signed? | The exact message, including fee payer and recent blockhash. | The exact message, including fee payer and durable nonce. |
| What invalidates saved signatures? | An expired blockhash or any change to the signed message. | An advanced or consumed nonce or any change to the signed message. |
| What happens after failure? | An expired message needs a new blockhash and a new signing round. | A validation failure is dropped without a fee; an execution failure after nonce validation still advances the nonce and charges fees. |
The mechanics and failure rules are documented in Durable Nonces, Partial Signing, and the Transaction Pipeline.
What happens if a Solana durable-nonce transaction fails?
The result depends on when it fails. Solana distinguishes validation, which happens before the transaction is accepted, from instruction execution after the nonce has been validated.
Validation failure: no fee and no nonce advance
If the nonce account is not initialized, the stored value does not match the message, the nonce cannot advance, or the required nonce authority signature is missing, the transaction fails validation. It is dropped without changing account state and without collecting the transaction fee. The saved bytes are still unusable until the underlying problem is corrected; for example, a mismatched value requires rebuilding and signing with the current nonce.
Free tools Windows power users keep installed
One-click scans. No signup required.
Execution failure: nonce advances and fees are charged
If nonce validation succeeds but a later instruction fails, the nonce has already advanced. The transaction fee is still collected, and the old signed transaction cannot be submitted again. This protects the nonce from replay even when an application instruction rejects, runs out of compute, or otherwise returns an execution error.
Rank #3
- More than just crypto: confirm your device is authentic with Genuine Check, manage all your logins with Ledger Security Key, detect common scams with Transaction Check and more.
- Industry-defining security: battle-tested by the Donjon's white hat hackers, protected by the Secure Element, and powered by Ledger OS.
- Connect effortlessly with Ledger Wallet: pair your secure Ledger signer with the all in one Ledger Wallet crypto app to manage thousands of digital assets across multiple devices and accounts with Ledger Sync from a single, secure dashboard.
- Playful, user-friendly design: monitor the market, compare rates and Clear Sign all transactions on the secure 2.8'' anti-glare, scratch-resistant touchscreen.
- This is what security feels like: Ledger touchscreen signers all come with a private, offline, PIN-protected backup, Ledger Recovery Key, to never lose access to your assets.
How to recover
- Inspect the confirmed result and determine whether the failure was validation or execution.
- Read the nonce account again; do not assume the previous value is still current.
- Fix the instruction, account permissions, balance, compute budget, or other cause of execution failure.
- Construct a new message with the current nonce and the same intended signers where appropriate.
- Collect signatures over the new serialized bytes and submit once.
Never retry by resubmitting a signed transaction whose nonce was already advanced. It is tied to the old value and cannot become valid again.
Why every signer must keep the message frozen
Partial signing is useful when several people, devices, or services hold different keys. It also creates a common operational mistake: treating a partially signed transaction as a draft that can be edited later. It cannot.
Fields that commonly change by accident
- The fee payer, especially when a coordinator substitutes its own account.
- The recent blockhash or durable nonce.
- Instruction order, account metas, writable flags, or signer flags.
- Amounts, recipients, program arguments, or compute-budget instructions.
- Address lookup information and message version details.
Any such change produces different message bytes. Collect signatures only after the final fee payer, lifetime value, instruction set, and account permissions are known. Keep an auditable hash or serialized copy of the message so each signer and the submitter can verify they are handling the same transaction.
A practical offline-signing workflow for ordinary transactions
This procedure is appropriate when the operation can finish inside the recent-blockhash window.
- Connect the coordinator. Fetch a recent blockhash and gather the current account and program data needed to build the transaction.
- Finalize the message. Set the fee payer, all instructions, account metadata, and the fetched blockhash. Do not send a mutable transaction object to the signer.
- Transfer the unsigned message. Use the transport supported by your wallet or device, such as a QR payload or removable-media handoff, while keeping the private key offline.
- Verify on the signer. Check the destination, amount, program, fee payer, and any human-readable transaction details your device provides.
- Collect every signature. Return the signatures or signed bytes without modifying the message.
- Submit promptly. The connected coordinator sends the fully signed transaction and monitors its confirmation and expiry information.
- Rebuild if it expires. Fetch a new blockhash and repeat the signing process; do not patch the expired message.
This workflow gives key isolation without claiming that the transaction is valid indefinitely.
When a durable nonce is worth the extra coordination
A nonce is most useful when the signing process can outlast a recent blockhash: a treasury approval that waits for several people, a custodian that batches requests, an air-gapped facility with scheduled transfer windows, or a controlled process in which the signer and submitter are separated by policy.
Questions to answer before choosing a nonce
- Who controls the nonce authority, and how is that authority protected?
- Which process is allowed to advance the nonce?
- How will operators detect that another transaction consumed the value?
- How will the system fetch the current nonce and trigger a complete re-signing cycle?
- Can the application tolerate nonce advancement and fee payment when an instruction later fails?
- Does the wallet or signing device display and sign this nonce transaction format correctly?
A nonce improves the lifetime problem but introduces shared mutable state. Two teams cannot safely hold independent signed transactions based on the same nonce and expect both to work. Once one valid transaction advances it, the other old transaction is unusable.
What ordinary wallet users need to do in 2026
The Solana Foundation’s Durable Nonce Deprecation page, dated October 2026, says wallets and applications continue to work as before. Its guidance is that action is needed only if you personally use durable nonces. If a custodian or service uses them on your behalf, that operator is responsible for its migration.
Rank #4
- All your digital assets in one place. You can manage thousands of crypto including Bitcoin, Ethereum, Solana, Tether and more.
- Connectivity: USB-C cable connection only. No Bluetooth.Compatible with the Ledger Wallet crypto app, both desktop (Windows, macOS, Linux) and mobile (Android only). Not compatible with iOS.
- Protect your digital assets with the industry's best security: keep your private keys offline in your private signer, battle-tested by the Donjon's white hat hackers, CC EAL 6+ certified Secure Element, constantly updated Ledger OS.
- Effortlessly build your crypto portfolio via the all in one Ledger Wallet app: buy, sell, send, receive, swap, stake and more across popular blockchains. 15,000+ coins & tokens in a single dashboard. Keep a close eye on the market. Compare service providers. Track performance. Get timely alerts. Build your portfolio with confidence.
- Choose the colors that match your style: express your personality and your crypto management mood, color code your signers, one for each use (trading, staking, HOLDing...).
Do not migrate merely because you sign offline. An ordinary offline transaction uses the normal recent-blockhash path unless your wallet or workflow explicitly creates a nonce transaction. Check the transaction details or ask the service that operates your signing flow which lifetime mechanism it uses.
What to verify in an air-gapped setup
- Whether the wallet supports the Solana message version and instruction types you intend to sign.
- Whether the device shows the recipient, amount, fee payer, and program information clearly enough for manual verification.
- Whether the transport preserves the serialized bytes without silently rebuilding the transaction.
- Whether the coordinator reports blockhash expiry, nonce mismatch, simulation errors, and final confirmation separately.
- Whether there is a recovery procedure for a consumed nonce or an expired blockhash.
No general compatibility guarantee covers every hardware model or transaction type. Confirm the exact wallet, firmware, SDK, and application combination before moving production funds.
Are Solana durable nonces being deprecated?
They are planned for deprecation, but they have not been removed. In October 2026 the Foundation labels the work In Development; it gives no final replacement decision and no scheduled mainnet activation date. The stated plan is to keep current nonce transactions valid until a suitable replacement is audited and live on mainnet, with removal expected roughly six months after that replacement is ready. This is a plan, not a calendar commitment.
The Foundation says normal transactions are unaffected. Its summary for users who do not use durable nonces is, in context, Only if you use durable nonces.
Why the Foundation is pursuing a replacement
The Foundation page reports figures attributed to SIMD Discussion #564: durable nonces represented 3.1% of transactions in one June 2026 epoch but accounted for 30% of priority fees paid. It also reports that 555 fee payers sent 97.5% of those durable-nonce transactions. These are figures presented by the Foundation as part of its rationale about spam and fee concentration, not a universal usage rate for every epoch.
The two approaches under discussion
The page identifies Anza Programmatic Signer and Blueshift Vector as candidate approaches. Both move offline-signature checking and replay protection into on-chain programs rather than relying on validator-runtime special cases. Their execution paths use cross-program invocation (CPI) and a signer program-derived address (PDA).
These are not finished, audited mainnet replacements in the status described. The Foundation reports an Anza implementation on Devnet, says the interfaces and implementations are still developing, and says audits precede an Anza v1 release. It does not state Vector’s audit status.
Implementation differences that matter to teams
- Anza uses a standard v1 message payload and allows multiple authorities.
- Vector’s signature covers every top-level instruction and supports additional signature schemes listed on the Foundation page.
- The approaches differ in nonce-account structure, what an offline signature covers, whether a relayer can add instructions around the signed payload, and CPI stack-depth implications.
- Both require authorized instructions to execute through CPI, which can affect applications that require top-level instructions or use CPI guards.
Teams should evaluate the final audited design, interface, and migration tooling before changing production signing infrastructure. A current durable-nonce workflow remains valid during the stated transition period.
Production signing and custody considerations
Organizations that sign at scale may separate key custody from transaction construction and submission. Solana’s Signing in Production documentation discusses production signer models and keychain backends. Whether the key is held in a hardware device, a KMS or HSM, or a managed or multi-party service, the protocol rules remain the same: sign the exact message, protect the key, and select the correct lifetime mechanism.
A production system should log the message identity, signer set, lifetime value, nonce-account state when applicable, submission result, and confirmation status. It should distinguish an expired blockhash from a consumed nonce and an instruction-level execution error. Those cases require different recovery paths and different audit records.
Quick Recap
Decision checklist
- Need key isolation only? Use offline signing with a recent blockhash if the workflow finishes promptly.
- Could approvals or transport exceed the recent-blockhash window? Evaluate a durable nonce, with an explicit nonce-authority and recovery process.
- Will anyone edit the transaction after the first signature? Stop and finalize the message first; edits require new signatures.
- Did a nonce transaction fail? Determine whether validation or execution failed, then read the current nonce before rebuilding.
- Are you planning for deprecation? Track the Foundation’s status and test any replacement only after its interfaces, audits, and mainnet availability are established.
- Are you an ordinary wallet user? No migration is required unless your wallet, custodian, or application actually uses durable nonces.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →
