Solana’s Nonce Plan: An Approval Can Outlive Its Delivery
Solana plans to retire durable nonces without abandoning offline signing. The proposed program-based approach separates a lasting authorization from the short-lived transaction that carries it.
AI-generated conceptual illustration: an unchanged authorization capsule moves from an expired delivery carrier to a fresh one. This is a metaphor, not a wallet interface or evidence of a completed Solana migration.
Key Points
- The October 16 changelog pointed to the deprecation plan. No replacement has been finally selected and no removal date is set; the roughly six-month window depends on a suitable replacement becoming ready.
- An offline authority signs a message; a relayer carries it in an ordinary transaction. Refreshing that transaction’s blockhash need not change the signed authorization.
- The proposed programs act through derived addresses and internal calls. Compatibility, the scope of a signature and authorization cancellation remain separate questions.
Chronological Timeline
The Solana Foundation’s October 16 changelog points readers to the durable nonce deprecation announcement. It is a plan, not a completed removal.
A plan with a conditional clock
An offline approval may take longer to collect than a normal Solana transaction remains valid. Durable nonces address that mismatch today. The Solana Foundation’s October 16, 2026 changelog linked to a plan to retire them, but the upgrade page remains In Development. It describes an onchain program verifying an offline signature, with Anza’s Programmatic Signer and Blueshift’s Vector as candidates. It does not name a final replacement or a removal date.[1][2]
The page expects removal roughly six months after a suitable replacement is ready, and says durable nonces stay available until a replacement is audited and live on mainnet. That is not a countdown from the October announcement. Anza’s own documentation currently reports a Devnet deployment, audits in progress and remediations required before v1 and any mainnet deployment; interfaces may change. Published Vector code and program addresses do not, by themselves, establish an audited mainnet rollout. This article explains the published designs, not a completed network change.[1][4]
What the current nonce preserves
A normal transaction refers to a recent blockhash and has a limited acceptance window. A durable nonce transaction substitutes a value stored in a System Program nonce account. That lets the signer approve the transaction offline and someone else submit it later, without the ordinary blockhash expiry. The stored value also provides replay protection: a transaction signed against an old nonce cannot simply be used again after that nonce advances.[3]
Failure has two different meanings here. The current documentation says a nonce transaction rejected during validation—for example because the nonce was already used—is dropped without fees or state changes. If it passes validation but an instruction fails during execution, however, the nonce still advances and the fee is collected. The application action can fail while the old signed transaction becomes unusable. Describing every rejected attempt as consuming a nonce would miss this distinction.[3]
The approval and its carrier have different lifetimes
Programmatic Signer separates the action into three layers. An execution message lists the application instructions. An authorization message binds that work to an executor and a nonce account; the required authorities sign its exact bytes. A relay transaction then carries the authorization and signatures onto the network, using an ordinary recent blockhash and a fee payer. Programs check the offline signatures, advance their own nonce and invoke the approved instructions. The validator sees a normal transaction.[4][5]
Imagine a signed approval as the contents of a delivery envelope. If the envelope expires, the relayer can prepare a fresh relay transaction and sign that outer transaction again; the authorization inside need not be signed again. The analogy has a precise limit: the relayer cannot edit the approved instructions or substitute different accounts inside the authorization. In Anza’s documented format, the execution message’s blockhash field holds the expected nonce, while the outer relay’s field holds the recent blockhash. The fields serve different purposes.[5]
The calling account and signature boundary also change
The program acts for the offline authority through a program-derived address (PDA) and calls the application through cross-program invocation (CPI). An existing keypair and that derived account are not interchangeable identities. A program that insists on a top-level call can reject this path. An indexer looking only at outer transaction signers may see the relayer, while the acting PDA appears in inner instructions. Supporting offline authorization therefore involves more than replacing one expiry field.[1][4]
The candidates also differ in what the signature freezes. Programmatic Signer lets a relayer add instructions before or after Submit, while forbidding changes inside the signed authorization. Vector binds every top-level instruction into the signed digest, including its passthrough contents; the relayer cannot add, remove or reorder those instructions after signing. Both use program-managed replay protection and CPI, but they offer different boundaries for surrounding work. Neither description establishes that an application is already compatible.[1][5][6]
Expiry, cancellation and a retry are different events
Neither published design gives an authorization a built-in deadline. The relay transaction expiring is therefore not cancellation of the authorization. Advancing the relevant nonce invalidates an authorization tied to its previous value; a business deadline instead has to be enforced by an instruction covered by the signed payload. A date shown by an approval tool is not enough unless the executed rules actually check it.[1][5][6]
The designs also allow a failed execution attempt to leave the authorization available for another try when the transaction rolls back and the nonce remains unchanged. That is different from the current durable nonce’s execution-failure behavior, and it does not promise eventual success or free network attempts: ordinary transaction fees still apply. For readers evaluating the plan, the useful questions are what was approved, which account will act, what can invalidate the approval, and whether the receiving application accepts that call path. The Foundation says ordinary transactions are unaffected by the planned removal; the migration concerns workflows that use durable nonces.[1][3][6][7]
Continue reading
Explore the topic through other cases and contexts.
