What Are Solana Durable Nonces and Why Do Custodians Use Them?
A normal Solana transaction carries a recent blockhash, which expires after a short time.
That is a problem for a custodian whose cold wallet signs offline. Approvals can take hours, and the blockhash would be stale before anyone submits the transaction.
Solana Durable Nonce Migration solves this, the signer builds the transaction around a value stored in a Solana nonce account, not a recent blockhash, so the transaction stays valid until the nonce is used. A nonce authority controls the account. The technical details are in the official Solana durable nonce documentation.
Custodians and exchanges rely on this for offline signing, air-gapped approval flows and multi-party review.
For a plain-language view of why custody matters at all, the explainer on Can You Buy Solana Without a Wallet covers the difference between holding keys and trusting a platform.
The Solana Foundation's deprecation page gives several reasons. Durable nonces skip the usual blockhash check, so validators need special-case rules for them, and each special case is another place for a replay bug.
Nonce transactions can also land twice, which conflicts with asynchronous execution and with tools that assume every signature is unique.
There are cost and fee concerns too. Nonce transactions never expire, so resending them is free, and they were reported to take a large share of priority fees during busy periods.
Validating them also costs more than rejecting a stale blockhash. These points explain the Solana durable nonce deprecation plan in the project's own words, which is available on the Solana durable nonce deprecation page.
This Solana upgrade changes Solana transaction signing most for crypto custodians, because Solana transactions signed offline were the main use. For the Solana network, the aim is simpler runtime rules and stronger transaction security.
A related draft proposal sets a minimum migration window. Reports say it would not activate before a date in 2027, but it is still a draft without final approvals, so no one should treat any date as settled.
The replacement moves signature checks and replay protection into on-chain programs. In the described flow, a cold key signs a message that lists the instructions. The message carries no blockhash, so it does not expire. A hot fee payer then submits it inside a normal transaction.
The signer program verifies the cold key's signature, advances its own nonce and runs the instructions through a cross-program invocation, signing as a program-derived address, or PDA.
A PDA is an account controlled by a program, not by a private key. Replay protection stays on-chain, and the validator no longer needs special rules.
The model keeps the cold wallet offline and the hot wallet limited to paying fees, which is the same security split custodians use today. A broader map of how these pieces fit into the network appears in the Solana Ecosystem Map.
Two implementations are under development, and the final choice has not been made.
| Feature | Anza's Programmatic Signer | Blueshift's Vector |
| Status | Deployed on Devnet, not yet audited | Program addresses published, audit status not stated |
| Signed payload | A standard transaction message that hardware wallets can sign | A signature over a hash of the instructions, which many hardware wallets refuse to sign |
| Setup | No initialization step | Needs an initialize step |
| Maturity | Interfaces may change | Interfaces may change |
The hardware wallet point matters most for custodians. If a signing device cannot display or approve the payload, the design may not fit an existing cold-signing setup. Neither option should be called final or universally deployed.
Teams comparing Solana offline signing options should check how each choice affects Solana transaction signing, Solana nonce migration timing and the split between the cold wallet and the hot wallet.
Durable nonce replacement is not a drop-in swap, so tests of the Solana Vector signer and the Programmatic Signer need real hardware.
The guidance splits preparation into two stages.
Now:
Test the full flow on Devnet. Both programs can be used today, though they may change.
Inventory current workflows that depend on nonces, including approval delays and fee payers.
After the programs are live on mainnet:
List every account authorized through a durable nonce.
Derive the signer PDA for each cold key.
Move authorities and funds, using durable nonce transactions for the migration itself while they still work.
Run a hot fee payer that only needs SOL for fees, and rotate fee payers so that wallets are not easy to cluster.
Anyone planning Solana Durable Nonce Migration should treat the Solana custodian migration as a project with owners, a test plan and a rollback plan, not a quick configuration change.
Solana custody infrastructure teams often have review steps that take longer than the migration window of other systems, which is why starting early matters.
Migration can touch several account types:
Wallets: Any wallet whose transactions are signed offline with a nonce.
Stake accounts: Both the stake authority and the withdraw authority.
Token accounts: The owner and close authorities.
Token mints: The mint and freeze authorities, which matter most for stablecoin and token issuers.
Unaudited code: A replacement that is not yet audited should not hold production funds.
Hardware wallet gaps: A design that devices cannot sign may force a workflow change.
Authority mistakes: Moving a mint or withdrawing authority to the wrong address can be hard to undo.
Timing risk: A signed transaction that waits too long can fail if its nonce is no longer valid.
Relayer risk: A third-party relayer submits approvals, so its reliability and trust model matter. For background on how transaction ordering and value extraction work on the network, the guide on Solana MEV Explained helps.
Phishing: Migration announcements attract fake tools, so only official documentation should guide the work.
A careful test plan has several parts:
Run the full cold-sign, relay and execute flow on Devnet with throwaway keys.
Test with the exact hardware wallets and signing software used in production.
Rehearse the authority move for each account type, including stake accounts and token authorities.
Check failure cases, such as expired approvals, failed submissions and fee payer outages.
Review the code and audit status before any mainnet use.
Document a rollback path for each step.
Developers who want to follow how builders approach new network features can read Solana Hackathons Explained, though production custody should rely on audited code and official guidance.
Solana Durable Nonce Migration remain valid on mainnet today. Normal transactions are not affected, and wallets or apps that do not rely on durable nonces need no action. The guidance says nonces stay until a suitable replacement is available and enough time to migrate has passed.
Removal itself would require a feature gate, so it would not happen silently. The background discussion is in the soft deprecation discussion.
Solana Durable Nonce Migration is a planning problem, not an emergency. Durable nonces still work, the replacement is still being built and no final date exists.
Custodians gain the most by testing early, mapping every authority and keeping a clear line between the announced plan, the candidate programs and the eventual mainnet change.
For crypto custodians, the Solana upgrade is mainly about Solana transaction signing and Solana network safety.
Solana nonce migration, Solana offline signing, durable nonce replacement and Solana custodian migration belong in one plan, backed by Solana custody infrastructure reviews, Solana transactions testing and transaction security checks. The Solana Vector signer and the Programmatic Signer remain candidates, not final answers.
Disclaimer: This article is for educational purposes only and is not financial, legal or investment advice. Protocol plans and proposals can change. Always confirm current details with official Solana documentation before changing any custody system.