Solana market price and chart developers are reviewing a proposal to remove durable nonces, a transaction feature used for offline signing and approvals that take longer than a normal transaction’s validity window.
The SIMD-0723 draft, opened on November 5 by Anza contributor Gabe R., would require recent blockhashes for all transactions. It remains a proposal under review, rather than an activated mainnet change.
Proposal would remove special transaction lifetime handling rules
The technical specification argues that durable nonce exceptions have repeatedly complicated validation, replay protection and failure handling across validator clients. It proposes removing the exception instead of maintaining separate paths.
After activation, the System Program would stop initializing, advancing and upgrading nonce accounts. Withdrawal and authority-change instructions would remain available. The draft points to onchain signature-verification programs as alternatives for offline and delayed signing.
The proposal requires technical review before merging. Its publication therefore creates a planning issue for affected developers, without establishing that existing nonce transactions have stopped working.
Current documentation explains why custodians use durable nonces
Solana’s transaction documentation explains that durable nonces substitute a stored value for a recent blockhash. That allows a transaction to be signed offline and submitted later.
The process involves a nonce account, an authority and an instruction that advances the nonce. Once processed, the stored value changes, preventing the same signed transaction from being reused.
The existing failure rules also distinguish validation failure from execution failure. A transaction rejected during validation does not change state or collect fees. One that passes validation but fails during execution still advances the nonce and collects the fee.
That behavior illustrates the maintenance concern behind the proposal: the transaction’s instruction outcome and its replay-protection state do not always move together in the same way as an ordinary transaction.
Replacement readiness will determine the practical migration window
The Solana Foundation’s October migration guidance describes two candidates, Anza’s Programmatic Signer and Blueshift’s Vector. Both move offline signature verification into onchain programs.
Its guidance gives no fixed activation date and anticipates roughly six months for migration after a replacement is ready. Ordinary transactions are unaffected; the operational work falls on teams using durable nonces.
The proposed flow separates a cold signing key from a hot account paying transaction fees. The onchain program verifies the signed instructions and handles replay protection before calling other programs.
For custody providers, that means reviewing authorities, supported hardware wallets and application compatibility. It also means testing the complete signing and submission process, rather than changing a single endpoint.
BlockBriefing’s guide to shared custody and multiple-signature approval discusses the broader importance of approval design. Its comparison of hardware and software wallets provides background on separating signing from internet-connected activity.
Those guides do not replace Solana-specific migration instructions. The immediate distinction is between reviewing a future compatibility requirement and taking action on a feature already disabled.
Wallet providers will need to explain any changed signing prompts clearly so users can recognize what an offline signature authorizes.
The next milestones are technical acceptance, audited replacement readiness and an explicit activation plan. Until those are documented, a draft removal proposal should not be described as a completed network upgrade.
