Solana Plans to Deprecate Durable Nonces for New Program Architecture

Solana is preparing to retire durable nonces, a mechanism that permits offline transaction signing and delayed broadcasting, in favor of dedicated onchain signer programs. The Solana Foundation introduced this deprecation initiative in October, highlighting two competing proposals to handle offline approvals without relying on legacy nonce accounts. The planned transition aims to streamline validator operations by removing special replay-prevention rules for asynchronous transactions. However, the shift requires custodial services, exchanges, and treasury managers to adapt their operational setups to a completely different custody architecture.

Understanding Durable Nonces and Why They Matter

Ordinarily, blockchain transactions require a recent blockhash to prevent replay attacks, imposing a tight window between signing and network submission. Durable nonces were designed to bypass this timing restriction by storing a unique value that does not expire immediately, allowing offline keys to sign instructions well ahead of execution. This capability is crucial for institutional custodians and multi-signature setups that isolate signing keys from internet-connected computers. As Solana block production speeds accelerated with recent network upgrades, maintaining these legacy nonces became increasingly complex for validators managing asynchronous workloads.

Evaluating the Proposed Alternatives

The Solana Foundation outlined two potential replacements for the retiring mechanism, developed by separate infrastructure teams. One contender is an option introduced by Anza, while the other design comes from Blueshift. Both solutions introduce an intermediary program between the offline cold key and the final transaction execution, shifting how permissions and assets are managed.

• Cold keys authorize an approval message rather than the network transaction itself.
• A program-derived address assumes control of the affected accounts without owning a private key.
• An online relayer submits the transaction and covers network fees.
• Assets, native tokens, and administrative permissions must be manually migrated to the new address structure.

The two candidate frameworks handle native assets and transaction constraints differently. The architecture proposed by Anza utilizes a System-owned account for native funds, permitting standard transfers. Meanwhile, Blueshift initializes a program-controlled account, releasing funds through its own specialized withdrawal procedures. Furthermore, the proposals differ in how strictly they bind surrounding instructions to the signed payload, influencing how much flexibility an online relayer retains when packaging a submission.

Operational Challenges and Market Outlook

Moving toward these new signer programs involves significant preparation for institutional operators. Beyond evaluating the software, treasuries must audit their account inventories and migrate permissions, staking authorities, and token balances to the appropriate program-derived addresses. The Solana Foundation has indicated a tentative six-month migration timeline, though this schedule is strictly conditional upon a chosen replacement being thoroughly audited and deployed on the mainnet. For the broader digital asset market, the successful execution of this architectural change will demonstrate how high-throughput networks can modernize validator logic while maintaining robust offline custody workflows.