Solana Durable Nonce Deprecation Moves Offline Signing Out of the Runtime

Solana durable nonce deprecation is becoming a real migration programme rather than a distant architectural preference. The Solana Foundation’s 12 November engineering changelog linked new proposals to remove durable nonces and disable their use as fee payers, while the ecosystem has begun releasing software for a replacement built around program-verified offline signatures. The immediate event is technical. The broader consequence is institutional: exchanges, custodians, stablecoin issuers and treasury operators may have to move long-lived signing authority away from a special validator rule and into ordinary onchain programs.

That is not the same as abandoning offline signing. Durable nonces exist because a normal Solana transaction expires quickly. An air-gapped key, a multisignature approval committee or a customer who reviews a complex transfer cannot always complete the process inside a short blockhash window. The feature solved that operational problem by storing a value in a nonce account and allowing a signed transaction to remain valid until the nonce changed.

The cost was architectural exceptionalism. Validators must recognize a transaction that bypasses the ordinary blockhash-expiration path, load state to decide whether it is valid, advance the nonce under unusual failure conditions and preserve replay protection across edge cases. Those rules have become harder to reconcile with Solana’s next execution model. The proposed replacement keeps the user outcome—sign now, submit later—but moves signature verification, replay protection and instruction execution into a program. Every outer transaction can then look ordinary to the validator.

Block2Learn’s assessment is that this is a sensible direction, but not a free simplification. Runtime risk can decline while migration and application risk rise. The security question will move from one special consensus path toward audited programs, program-derived addresses, relayers, hardware-wallet support, cross-program invocation and authority conversion. Solana is not removing complexity. It is relocating complexity to a layer that may be easier to isolate, upgrade and reason about.

The November changelog turns deprecation into current engineering work

The Solana engineering changelog published on 12 November placed three developments beside one another. It listed version 1.0.0 releases for the Rust and JavaScript nonce-program software connected to the ed25519 Programmatic Signer. It highlighted proposals to remove durable nonces and prevent nonce accounts from paying fees. It also described the reason in unusually direct terms: durable nonces have introduced security, runtime and developer-experience risks.

These items do not mean that durable nonces have already been disabled. Mainnet users can still rely on them, and the removal proposal remains part of an open improvement process. The Foundation’s upgrade material says the replacement must be ready, audited and available before a migration window begins. It describes an expected interval of roughly six months after readiness, but gives no activation date.

That distinction matters. A proposal can shape engineering decisions long before it becomes a protocol rule. Custody platforms must decide whether new products should be built on an interface that is expected to disappear. Wallets and software-development kits must decide when to warn users. Programs that inspect nonce instructions or reject cross-program calls must decide whether their assumptions are compatible with the replacement. The transition therefore begins before the final feature gate.

The event is also larger than one deprecated command. Durable nonces sit at the boundary between transaction validity, signing policy and replay protection. Changing them forces Solana to define which responsibilities belong in the validator and which belong in an application. That boundary will influence future upgrades well beyond offline signing.

Why ordinary Solana transactions expire

A blockchain cannot accept the same signed transfer forever. If a valid message could be replayed without a changing freshness condition, an attacker could submit it repeatedly. Solana’s ordinary protection combines a recent blockhash with a status cache that remembers processed signatures. The blockhash limits the transaction to a short interval; the cache stops a signature from being accepted again inside that interval.

The official durable-nonce documentation explains that a normal transaction uses a recent blockhash, while a nonce transaction substitutes a value stored in a System Program account. The stored state includes an authority, the durable nonce and a fee value. When the validator receives a transaction whose blockhash is no longer in the normal queue, it can inspect the nonce account and determine whether the message follows the special durable path.

This design gave Solana an important institutional capability. A cold key could sign a transfer without remaining connected to a network. Several people could review and approve an operation across a longer period. A custodian could prepare a transaction inside a controlled environment, move it through policy checks and submit it later. The message did not die merely because the current blockhash expired.

The same property changed the validator’s job. Validity no longer depended only on cheap transaction fields and recent network state. It could depend on loading the nonce account and evaluating rules that ordinary transactions do not need. A nonce must advance so the signed message cannot be replayed. Today, that advance can remain committed even when later execution fails, which protects against replay but consumes the signed authorization.

The feature therefore combines two different concepts: a long-lived approval and a transaction-level exception. The replacement effort asks whether the first can survive without the second.

Special runtime rules create a wider security surface

The nonce-replacement meta-proposal identifies four structural problems. First, nonce transactions require special handling to avoid replay because they bypass the normal expiry mechanism. Second, they complicate asynchronous execution, where a transaction may be placed into a block before all execution effects are known. Third, a message that never expires can be attractive to spammers during congestion. Fourth, invalid nonce transactions are harder to reject early because validity depends on account data.

Each problem comes from a legitimate feature. Long-lived validity is useful to a cold signer. Account-based replay protection is what allows the message to remain valid. Special failure semantics prevent a signed transfer from becoming reusable after partial processing. Yet a collection of individually defensible exceptions can become a fragile subsystem.

This is similar to the lesson in Block2Learn’s analysis of the Osmosis network halt and compiler risk. A decentralized validator set can still share a narrow technical dependency. In Solana’s case, durable-nonce handling is implemented across validator clients and transaction-processing paths. The network needs different clients to interpret the exceptional case consistently.

Removing the exception can simplify consensus-critical software. Validators would receive an ordinary outer transaction with a current blockhash and a hot fee payer. The offline authorization would be data verified by a program, not a reason to alter the transaction-admission rules. A failure would behave like an ordinary program failure from the runtime’s perspective.

That reduction is meaningful. Consensus code deserves a higher standard than application code because disagreement can affect the entire network. A program can be audited, versioned, tested on Devnet and called only by users who need it. A runtime exception affects every validator and every transaction pipeline, even if relatively few users depend on the feature.

The replacement separates authorization from submission

Anza’s Programmatic Signer documentation describes the new model as a long-lived authorization rather than a long-lived transaction. The authority signs a message offchain. A relayer later wraps that message inside a normal transaction, supplies a recent blockhash and pays the fee. An onchain program verifies the ed25519 signature, advances replay-protection state and invokes the approved instructions through cross-program invocation.

This separation changes the control model. Under a durable nonce, the cold signer signs a Solana transaction that includes a fee payer and nonce value. Under the programmatic approach, the cold signer approves an artifact describing what may happen. The submitting party creates the ordinary transaction later. The authorization can therefore outlive a blockhash without forcing the outer transaction to outlive one.

A program-derived address is central to the design. The cold authority’s signature allows the program to grant signer privilege to a PDA for the duration of the call. That PDA can own SOL, token accounts, stake accounts or other authorities. The offline key remains the root of authorization, but the program-derived account becomes the actor visible to downstream instructions.

This resembles an institutional control stack more than a conventional wallet transfer. The cold key defines authority. The signed message defines scope. The nonce program prevents replay. The relayer supplies liveness and fees. The executor coordinates instructions. Each component has a narrower job.

Block2Learn’s recent examination of Blockstream and Thales custody reached a related conclusion: protecting an institutional wallet is not only about hiding a key. It is about protecting the decision process around that key. Solana’s replacement makes the process more explicit, but institutions will still need hardware, policy, reconciliation and recovery controls around it.

Retryability improves, but cancellation becomes a first-class problem

The replacement can improve failure behavior. With durable nonces, an execution failure after nonce validation can advance the nonce and consume the signed transaction. A custodian may need to return to the cold environment and sign again. In the programmatic model, replay state and the approved instructions can execute atomically. If the full operation fails, state can roll back and the same authorization may be submitted again.

That is valuable when failure is temporary. Slippage may exceed a limit. An account may be momentarily unavailable. A relayer may choose a poor fee. Resubmission can preserve the human approval while changing the outer transaction’s blockhash and payer.

But an indefinitely retryable authorization needs a cancellation path. A transfer approved on Monday may become dangerous on Friday if an account is compromised, a counterparty defaults or regulation changes. The signing format must support a deadline, sequence or explicit cancellation mechanism that the institution can operate without the same unavailable cold key.

Retryability also changes monitoring. Operations teams must distinguish a message that was signed, a transaction that was submitted, an execution that failed, a nonce that was consumed and an authorization that remains live. A dashboard that treats every transaction signature as the complete approval object will be insufficient.

This is one reason the replacement cannot be judged only by validator-code reduction. The total system includes message stores, relayers, audit logs, hardware wallets, policy engines and recovery procedures. Runtime simplicity is a strong objective, but operational clarity determines whether institutions receive the benefit.

Fee-payer flexibility can improve custody architecture

Separating the cold authority from the fee payer solves an old inconvenience. A cold wallet should not need to maintain SOL merely to pay a network fee if a service provider is willing to submit the transaction. A relayer can fund the outer transaction, rotate fee-paying accounts and adjust priority fees when it submits.

This creates resilience. If one relayer is unavailable, another can package the same authorization. A custodian can separate asset authority from network operations. A stablecoin issuer can preserve a tightly controlled mint authority while using online infrastructure for routine submission.

It also creates a new intermediary role. The relayer sees the authorization, chooses when to submit it, selects the fee and may influence transaction ordering. The signed message must be narrow enough that the relayer cannot change the economic action. Institutions should also consider confidentiality: if an authorization reveals a large transfer or market-sensitive action before execution, a relayer or observer may act on that information.

The design therefore shifts trust rather than eliminating it. The relayer does not need authority to rewrite the transfer, but it may control timing and availability. Paymasters need allow lists and transaction guards that understand the new programs. Monitoring must detect withholding, repeated failures and unusual payer behavior.

For a public blockchain, this is a familiar pattern. Cryptography constrains what an intermediary can do, while operations determine whether the permitted action happens on time. Good architecture narrows trust to observable, replaceable functions.

Migration will be difficult precisely where security matters most

The Foundation’s durable-nonce deprecation guide says the replacement is aimed at users such as custodians, exchanges and issuers. Those organizations often control the most sensitive accounts and operate the slowest approval processes. They are also the least able to move quickly through a breaking change.

Migration can require more than updating a library. If assets or authorities currently belong to an offline keypair, the new design may require transferring them to a signer PDA. Stake authorities, token-account owners, mint authorities and freeze authorities may need to change. Native SOL may need to move. Each conversion is itself a privileged operation that must be tested, approved and reconciled.

This creates a bootstrapping problem. The safest way to migrate may be to use durable nonce transactions while they still exist. Institutions need both systems during the transition: the old one to authorize change and the new one to receive authority. A rushed cutoff would turn a security improvement into an operational hazard.

Hardware-wallet compatibility is another constraint. An institutional signer may be certified to approve a recognizable transaction format, not an arbitrary hash or application-specific blob. A replacement that is elegant for validators but opaque to signing devices can weaken human review. Clear transaction presentation, domain separation and deterministic serialization are part of security, not merely user experience.

The migration should therefore be measured by controlled authority conversion, not by the number of SDK downloads. A successful Devnet transaction proves that the software path can work. It does not prove that a custodian’s governance, disaster recovery and reconciliation can survive the change.

Applications must accept a PDA arriving through CPI

The replacement also changes how other programs see the user. The cold key may no longer appear as the signer of the outer transaction. A relayer signs and pays for the outer transaction, while a PDA acts as the authorized account inside nested instructions. Programs that assume the economic owner must be a top-level signer can reject valid calls.

Several patterns require review. A program may inspect stack height and forbid calls made through CPI. It may examine the instructions sysvar and expect a verification instruction at the top level. A Token-2022 account may use CPI Guard to block authority actions initiated through cross-program calls. A security filter may treat an unfamiliar PDA as suspicious even when it is deterministically derived from a known authority.

These controls were often added for good reasons. Top-level signing is easier to explain. CPI restrictions can reduce composability risk. Instruction introspection can bind a loan, payment or verification step to the rest of a transaction. Removing those assumptions without an alternative would be dangerous.

The correct response is not to allow every nested call. Programs can recognize audited signer programs, validate PDA derivation and expose a separate path for offline-authorized users. Indexers can map the PDA back to the authority. Wallets can show both the cold approver and the fee-paying relayer. Security remains explicit, but the identity model becomes richer.

This is where the transition touches Solana’s broader institutional strategy. Block2Learn’s analysis of DTCC’s planned Solana connection emphasized that public-chain access does not remove authoritative ownership controls. Offline signing migration makes the same point at account level. A blockchain address is part of the control system, but legal and operational authority still depends on who can approve, submit, cancel and explain an action.

Indexers and explorers will need a deeper attribution model

Public-chain transparency is only useful when software interprets it correctly. Under the old model, analysts can often associate a transaction’s visible signer with the authority that approved the action. Under a programmatic signer, the outer signer may be a relayer, while the economically meaningful authority is represented by a PDA and a verified message deeper in the call stack.

An explorer that highlights only the outer fee payer could make an institutional transfer look as if it were authorized by an operations service. A compliance tool that screens only top-level signers could miss the cold authority. An accounting system could attribute fees correctly but assets incorrectly.

Indexers will need to decode the signer program, follow inner instructions and map the PDA to its controlling authority. They may also need to distinguish the authorizer from the submitter and the fee payer. Those roles can belong to three different entities.

This richer model is not necessarily worse. Traditional financial systems already separate beneficial owner, account controller, executing broker and settlement agent. The mistake would be pretending that a single signer field captures every role. Solana’s replacement can make authority more modular, but the data layer must expose that modularity clearly.

The same principle applies to incident response. If a suspicious transfer occurs, investigators need the signed artifact, the relayer transaction, the nonce state, the PDA derivation and the executed instructions. Observability must mature alongside the signing model.

What the change means for SOL value capture

The deprecation proposal is a protocol-quality decision, not a direct demand catalyst for SOL. Removing exceptional runtime logic can reduce security risk and unblock future execution improvements. A safer, more predictable network can support institutional adoption. Those are meaningful long-term inputs.

The immediate economic effects are smaller and mixed. Relayers still need SOL to pay transaction fees. Institutions may no longer need to hold fee balances inside cold authorities, but that changes custody distribution more than aggregate fee demand. Migration transactions can create temporary activity, yet one-off authority changes do not establish durable usage.

There is also a decentralization question. If a small number of relayers or signer programs become dominant, institutional operations may concentrate around them. The protocol can remain permissionless while practical access depends on audited implementations, supported hardware wallets and compliance integrations. Competition between Anza’s Programmatic Signer, Blueshift’s Vector and future alternatives matters because it limits single-implementation dependence.

Investors should therefore avoid two symmetrical mistakes. The bullish mistake is to treat every security improvement as immediate token appreciation. The bearish mistake is to ignore infrastructure work because it does not change throughput or fees overnight. Protocol value is partly the probability that future applications can operate without catastrophic failure. That probability is difficult to price but economically real.

Three paths for the transition

The best outcome is an orderly replacement. At least one implementation completes audits, interfaces stabilize, hardware and SDK support arrive, institutions test authority migration and the network opens a clearly communicated window. Durable nonces remain available long enough to move critical accounts. Indexers and applications update before removal. The validator runtime becomes simpler without sacrificing the institutional use cases that made nonces valuable.

A second outcome is prolonged coexistence. Replacements work, but large custodians cannot migrate quickly. Core developers keep maintaining the exception while applications split across old and new models. This reduces the benefit of simplification and extends the period in which teams support two signing paths. It may still be preferable to a rushed cutoff, but the network carries additional complexity for longer.

The adverse outcome is a coordination failure. A removal date arrives before tooling, audits or authority conversion are ready. Some accounts cannot transact through the new path, programs reject CPI-based signatures, or monitoring systems misattribute activity. The technical change might be correct in isolation while implementation damages confidence.

The difference between these paths will be visible before activation. Audit publication, mainnet deployments, wallet support, SDK warnings, migration documentation and institutional test results are leading indicators. The open proposal process should also reveal unresolved objections around transaction size, hardware signing and application compatibility.

Solana’s willingness to remove a feature that no longer fits the execution roadmap is a sign of technical maturity only if the ecosystem also accepts the burden of migration. A chain is not mature because it never breaks compatibility. It is mature when it can retire risk without surprising the users who built on the old promise.

The Block2Learn assessment

Solana should move long-lived offline authorization out of the validator runtime. Durable nonces solved a real problem, but they did so by giving one class of transactions exceptional validity and failure rules. Asynchronous execution, early filtering and replay protection are easier to reason about when every outer transaction uses a current blockhash.

The replacement architecture is also conceptually stronger. A cold key authorizes an action. A relayer submits and pays. A program verifies, prevents replay and invokes the instructions. Those responsibilities can be tested separately and combined transparently.

The main risk is migration concentration. Institutional users may converge on one signer program, one relayer network or one custody integration because it is first to complete audits. A runtime exception would disappear, but a service dependency could take its place. Open implementations, clear standards and interoperable tooling are therefore part of the security objective.

The network should not set a final removal date until audits, mainnet deployments and practical migration evidence exist. Roughly six months may be sufficient for ordinary developers. It may be short for regulated custodians that must change authorities across many accounts, update hardware workflows and validate recovery. Readiness should be demonstrated, not assumed.

Block2Learn’s analysis of the Ethereum post-quantum roadmap made a parallel point: long-horizon security upgrades require early preparation because the visible cryptographic change is only one part of the system. Wallets, custody, governance and user expectations move more slowly than code. Solana’s nonce transition is smaller, but the coordination lesson is the same.

Continue Through the Block2Learn Learning Path

Solana durable nonce deprecation sits at the intersection of transaction validity, cryptographic authorization, replay protection, custody, program-derived addresses, cross-program invocation and institutional operations. Understanding it requires more than knowing that one feature will be removed.

The Block2Learn Learning Path develops that structure progressively. Free Start introduces the language of digital assets and market infrastructure. Foundation connects technology to incentives, risk and capital allocation. The Investor Operating System turns incomplete technical evidence into a repeatable decision process. The Crypto layer then goes deeper into wallets, signatures, smart contracts, consensus, custody and token value capture.

That progression helps separate three questions that headlines often merge. Is the new architecture safer for the network? Can institutions migrate without weakening their controls? Does the change create durable economic demand for SOL? The answers can differ. A protocol can become safer before adoption changes, and adoption can improve without token price responding immediately.

Information is abundant. Structure is rare.