Durable Nonce Deprecation

October 2026 • Solana Foundation

TL;DR: Durable nonces will be removed. There is no final decision yet on what replaces them, but the shape is settled: an onchain program that verifies an offline signature. Two strong candidates exist, Anza's Programmatic Signer and Blueshift's Vector. Removal is expected roughly six months after the replacement is ready. Only durable nonce users need to act.

A normal transaction expires 150 blocks after its blockhash: about 38 seconds at today's 250ms slots, 30 seconds at 200ms (see Reduced Slot Times). Durable nonces swap the blockhash for a stored value, so the transaction never expires. They are used when approval processes require air-gapped signing or long approval flows, common for exchanges, custodians, and stablecoin issuers.

The replacement is an offline signer program:

The cold key signs a message that lists the instructions to run.
A hot fee payer puts it in a normal blockhash transaction.
The program checks the signature, consumes its own nonce, and runs the instructions via CPI with a PDA as signer.

Durable nonces make the validator special-case transactions that skip the blockhash check. The replacement moves signature checking and replay protection into an ordinary onchain program, so every transaction the validator sees is a normal blockhash transaction.

Two implementations are under development: Anza's Programmatic Signer and Blueshift's Vector.


Expected Mainnet Activation Date	Roughly six months after the replacement program is ready. No date set
Devnet Activation	Anza Programmatic Signer deployed on Devnet (pre-audit). Vector program IDs published, cluster not stated
Breaking Change?	Yes, for durable nonce users, once nonces are removed
Indexing Changes Required?	Yes, for indexers that attribute transactions to signers
Feature Gate	None for the replacements, which work today. Removing durable nonces will need one
Discussion	SIMD Discussion #456

Does This Affect Me?

Only if you use durable nonces. Normal transactions are unaffected.

For UsersNo action needed, unless you use durable nonces yourself.+

Wallets and apps work as before. If your custodian uses durable nonces, they handle the migration.

Advanced users and teams that use durable nonces in their business flows will need to change their process. See For Nonce Users.

For Nonce Users: Custodians, Exchanges, Issuers, BotsYes, if you sign with durable nonces. Test on Devnet now. Move authorities to a signer PDA once the programs are live on mainnet.+

If you	Breaking?	What to do
Sign with durable nonces (custody flows, treasury operations, high-frequency sending)	Yes, when nonces are removed	Test on Devnet now. Once the programs are live on mainnet, move to a signer PDA and run a hot fee payer.
Sign normal transactions before the blockhash expires	No	Nothing.

Start now: test on Devnet. The programs are pre-audit and interfaces may change, but the full flow can be built and tested today.

Programmatic Signer: install the spl-programmatic-signer CLI, create a nonce account with nonce create, sign offline with transaction sign, and relay with transaction submit. Program IDs and the JS client are under Anza Programmatic Signer.
Vector: use the Rust (vector-core) or TypeScript SDK to create an account with Initialize, sign an Advance, verify it offline, and submit. See Blueshift Vector.

Once the programs are live on mainnet, migrate while durable nonces still work:

List all accounts authorized through a durable nonce: wallets, stake accounts (stake and withdraw authorities), token accounts (owner and close authorities), token mints (mint and freeze authorities).
Derive the signer PDA for each cold key. Programmatic Signer: no initialization required. Vector: create it with Initialize.
Move authorities and funds. Use durable nonce transactions for the migration itself. Stake accounts and mints: reassign the authorities. Token accounts: create a new associated token account owned by the PDA and transfer the tokens. Native SOL: transfer it to the PDA.
Run a hot fee payer. It only needs SOL for fees. A paymaster such as Kora can do this. Rotate fee payers between clients to avoid wallet clustering.

For Wallets and Offline Signing ToolsYes. Decode the new payloads, tell users when a signature is delayed, and add offline signing if you don't have it.+

Add offline signing if you don't support it. Users who sign on air-gapped or time-gapped devices will need it once durable nonces are gone.
Decode the new payloads. Anza: a standard v1 message, any v1 decoder works, and the program IDLs are published on Devnet, so IDL-based decoders can show the Submit and Execute instructions too. Vector: a SHA-256 hash of the instruction list. Show the full transaction and verify it with the SDK's offline check.
Tell the user they are signing a delayed transaction. The message has no blockhash. It stays valid until it is used or cancelled, and whoever holds it can submit it later.
Recognize the program IDs in Technical Details. Show which PDA signs, next to the cold key.
Support v1 transactions. The nested payload often needs the 4096-byte limit. See Larger Transaction Sizes.

For Program DevelopersNot breaking. Offline signer users reach your program through CPI. Check that you don't block them.+

Authorized instructions reach your program as a CPI, at stack height 2 (Vector) or 3 (Programmatic Signer), signed by a PDA. Three common patterns lock these users out:

Stack height checks. A program that asserts sol_get_stack_height() == TRANSACTION_LEVEL_STACK_HEIGHT rejects any call that arrives through CPI, including these.
Instruction introspection that expects top-level instructions. Flash loan programs read the instructions sysvar to find their repayment instruction, and signature verification reads it to find a precompile instruction. Only top-level instructions appear there, so instructions nested inside Submit or Passthrough are invisible to the check.
Token-2022 CPI Guard. This extension lets a token account's owner block transfers, approvals, burns, and authority changes whenever the owner's signature arrives via CPI. A signer PDA only ever acts via CPI, so a token account with CPI Guard enabled refuses every instruction from it.

Allow the known signer program IDs, or offer another path. The CPI depth increase from 4 to 8 in SIMD-0268 leaves room for your own CPIs.

If your program introspects System Program nonce instructions, for example to detect AdvanceNonceAccount at index 0, that check stops matching once nonce transactions are gone. Remove the dependency.

For Relayers, Paymasters, and Transaction GuardsYes, if you inspect transactions before paying or forwarding. Drop nonce-specific rules and allow the new program IDs.+

Drop guards on System Program nonce instructions. Rules that require or reject AdvanceNonceAccount stop matching.
Add the signer program IDs to allow lists. Paymasters such as Kora and assertion guards such as Lighthouse need to recognize Submit, Advance, and Passthrough, and the CPIs they make.
Expect a PDA as the acting signer in inner instructions, not a keypair.

For SDK, CLI, and Test Tool MaintainersYes. Ship clients for the new programs and warn on durable nonce usage.+

Bundle clients for the new programs in web3.js, Kit, the Solana CLI, Rust crates, Anchor CPI wrappers, and local test tools such as Surfpool and LiteSVM.
Warn on durable nonce usage. A deprecation warning in nonce helpers that links to this page reaches users before removal. Keep nonces working until then; they remain valid on mainnet today.

For RPC ProvidersYes, if you add nonce-specific handling. One standard method changes behavior.+

getFeeForMessage falls back to the nonce account's stored fee when a message's blockhash is a nonce value. That fallback goes away with durable nonces. Review any nonce-specific logic in your own middleware as well.

For Indexers and ExplorersYes, if you attribute transactions to signers. The acting account is a PDA in inner instructions.+

The cold key no longer signs. The relayer is fee payer and signer. The acting account is the signer PDA in inner instructions. See this Programmatic Signer example on Devnet: one signer, and the PDA is the source of a transfer three CPI levels down.
Map PDAs to authorities. Programmatic Signer: the PDA is derived from the authority's public key with seeds ["programmatic-signer", authority]. Vector: the account data holds the signer's public key or address at byte offset 33, after the 32-byte nonce and 1-byte bump.
Read v1 transactions. Pass maxSupportedTransactionVersion: 1 on getTransaction and getBlock.

For Validator OperatorsUpdate any process that uses durable nonces, such as vote authority transfers.+

Nothing to configure. The replacements are onchain programs, and removing durable nonces will be a protocol change in a regular client release.

Anza's vote account guide recommends durable nonces for handing over the authorized voter or withdrawer without trusting the other party. Plan to run that flow through an offline signer program instead.

Why Durable Nonces Are Being Removed

Solana stops replays with two checks: the blockhash limits a transaction to a short window, and the status cache remembers every signature in that window.

Durable nonces skip the blockhash check. The validator replaces it with special rules: read the nonce account, verify its value, advance it even on failure, drop the transaction in several edge cases. Four problems follow:

Security bugs. Every special case in the runtime is another place for a replay bug. Nonce handling has caused outages, emergency patches, and bug bounty payouts.
Blocks asynchronous execution. Async execution puts transactions in a block first and runs them later. Some fail without changing state. A normal one can't land again, because its signature is already recorded for its blockhash. A nonce transaction can: its nonce never advanced, so the same transaction could land twice. Explorers, RPCs, and indexers assume signatures are unique.
Spam during congestion. Nonce transactions never expire, so resending them is free. In one epoch in June 2026 they were 3.1% of transactions but 30% of all priority fees paid. 555 fee payers sent 97.5% of them (SIMD Discussion #564).
Expensive filtering. A bad blockhash is rejected with a cheap lookup. A nonce transaction's validity depends on account data, so it travels further down the pipeline before it can be dropped.

The Replacement: Offline Signer Programs

The replacement for durable nonces is an offline signer program. Core developers converged on this design, called CPI Passthrough in the discussion, because it is the only option that removes nonces from the validator entirely and needs no runtime change.

How it works:

A PDA owned by the program becomes the authority (mint, stake, token owner, wallet).
The cold key signs a message listing the instructions. No blockhash, so no expiry.
A hot fee payer submits it in a normal transaction.
The program verifies the signature and advances its own nonce. Same message can't run twice.
The program runs each instruction via CPI, signing for the PDA.

The cost: authorities move to a PDA, and instructions run as CPIs instead of top-level. Two other changes soften this: SIMD-0268 raises CPI depth from 4 to 8, and Larger Transaction Sizes allows 4096-byte payloads.

Concerns Raised by Institutions

Concerns raised by custodians and issuers, and how the new programs address them:

Concern	How the new programs address it
Migration at scale. Millions of token and stake accounts need new authorities.	The signer PDA address is derived from the cold key, so it is known before migration starts. Migrate with durable nonce transactions while they still work, batched in 4096-byte v1 transactions. A hot fee payer covers the fees.
Programs that reject CPI. Flash loan repayment checks, CPI Guard, and "top-level only" rules lock out signers that arrive via CPI.	Programs can allow the known signer program IDs. CPI depth rises from 4 to 8, and Vector enters at stack height 2, so there is room for the program's own CPIs. Where a protocol insists on top-level calls, withdraw to a hot key first and act from there.
A program in the signing path. Cold storage policies often mean "no smart contract between the key and the funds."	Both programs are small, open source, and can be audited or self-deployed. Anza's splits signing, execution, and replay protection into three single-purpose programs. Audits precede the v1 release.
Signed message lifetime. Offline signing routinely takes longer than a minute, and some flows need a message to live for days.	Neither program has a built-in expiry. A signed message stays valid until it is used or cancelled. Add a deadline instruction only where you want one.
The cold key must be the final approver. Some policies forbid any party acting after the cold signature.	The fee payer only pays and broadcasts. It cannot change what was signed. With Vector it cannot add instructions either. The cold signature remains the authorization.
Wallet clustering. A shared fee payer links every wallet it relays for.	Rotate fee payers per client. Nothing is written onchain before submission, so pending approvals stay private.

Core developers confirmed durable nonces stay "until a suitable replacement is available and ample time to migrate has passed." Institutions asked for 6 to 12 months after mainnet availability. The current plan is roughly six months after the replacement program is ready.

What the Replacement Unlocks

The migration is about protocol safety. It also makes a few things possible that durable nonces never allowed.

	Durable nonces	Programmatic Signer	Vector
A failed attempt uses up the signature	Yes	No	No
Fee payer chosen when submitting, not signing	No, the fee payer co-signs	Yes	Yes
Pre-sign a chain of dependent transactions	No, the next nonce value is unknown	Yes	Yes
Others can add instructions around the payload	No	Yes	No, by design
Supported key types	Ed25519	Ed25519, more via new signer programs	Ed25519, secp256k1, EIP-191, Falcon-512

Retry failed attemptsA transaction that lands but fails no longer burns the signed message.+

Today, a durable nonce transaction that fails on slippage still advances the nonce. The cold key must sign again.

In both replacements, the nonce advances in the same atomic transaction as the instructions. If anything fails, the nonce rolls back. Resubmit the same message.

The message stays valid until it lands or is cancelled. Add a deadline instruction like sbpf-asm-timeout when timing matters.

Sign once, submit from anywhereThe fee payer is chosen at submission, not at signing.+

A durable nonce transaction names its fee payer up front, and the fee payer co-signs.

The new signature covers neither fee payer nor blockhash. Anyone can submit and pay: the key holder, a relayer, an RPC provider. The cold key never needs SOL. If one relayer is down, use another.

With the Programmatic Signer, several authorities can sign the same message in any order, at different times, without agreeing on a fee payer.

Pre-signed transaction chainsSign a sequence of dependent transactions in one session. They run in order only.+

The next nonce is a hash of the current nonce and the executed message, so a client can compute every future nonce offline.

Sign message 1, then message 2 against the nonce message 1 will produce, and so on. Message 2 can't run before message 1. Changing any message invalidates the rest. A multi-step treasury operation gets approved in one cold session and executed step by step, hours or days apart.

Signed intents others can build aroundProgrammatic Signer only: a relayer can add instructions around the signed message.+

The Programmatic Signer's signature covers only the authorization message. The relayer can add instructions before and after Submit, for example to combine several users' messages in one transaction.

Vector blocks this on purpose: its signature covers every top-level instruction.

Keys beyond Ed25519Ethereum and post-quantum keys can control Solana accounts.+

The program verifies the signature itself, so it isn't limited to Ed25519. Vector supports secp256k1, Ethereum personal_sign (EIP-191), and post-quantum Falcon-512. The Programmatic Signer ships with Ed25519; new signer programs can add other schemes.

The signer PDA is derived from the key. Switching keys means a new address.

Technical Details

Both follow CPI Passthrough. They differ in what the signature covers, how the payload is encoded, and how deep the instructions run.

Anza Programmatic Signer

Built by Anza for the Solana Program Library (docs, source). Three programs, one job each:

Program	Devnet address	Role
Ed25519 Signer	`EdSigVfK1DkeMrjFNDMjwfQaJPhPTtX7jW8uPv3oKEgN`	Verifies authority signatures, grants PDAs signer privilege for one CPI
Legacy Message Executor	`ExecxgyHYsAXB4c5dZodV1zJZ9hqfsDCYkRDRATrpkFR`	Checks the message against the nonce, advances it, runs each instruction
Nonce	`Noncediea1fH12usShuQAz28UhgAeuE5Maf32LsMUQB`	Stores 72-byte nonce accounts, separate from System Program nonces

Signer PDA: ["programmatic-signer", authority] under the Ed25519 Signer program. No setup needed. Nothing creates an account there, so it stays a System-owned account like a normal wallet. To send SOL out, the authority signs a message with an ordinary System Program Transfer from the PDA.

Three nested layers:

Execution message. A standard v1 message listing the instructions. Its blockhash field holds the nonce.
Authorization message. Wraps the execution message with the executor and nonce account. Every required authority signs these bytes.
Relay transaction. A normal transaction with a recent blockhash, signed by the relayer.

The payload is a regular v1 message, so existing parsers can decode it. Several authorities can sign one message. The relayer can change fee payer, blockhash, and instructions around Submit, but nothing inside the authorization message.

What it looks like onchain. This Devnet transaction uses the Programmatic Signer, not Vector, to move 0.001 SOL out of a signer PDA. The only signer is the relayer, which also pays the 5000-lamport fee. One top-level instruction, Submit, then three levels of CPI:

Ed25519 Signer Submit verifies the authority's signature.
Executor Execute checks the message against the nonce.
Nonce Advance consumes the nonce, then a System Program Transfer runs with the PDA as source.

The transaction used 54,007 compute units. The authority key is not among the transaction's signers; it appears only in the account list. Its derived PDA shows up as the source of the inner transfer.

To see the inner execution message decoded, open it in the Explorer inspector. It is a plain v1 message whose blockhash field holds the nonce value.

Nonce: each advance hashes the current nonce with the SHA-256 of the executed message. One authority can own many nonce accounts, so many messages can be in flight.

Extensible: signature checking is separate from execution and replay protection. A new signer program with another scheme can reuse the executor and nonce programs.

Tooling: spl-programmatic-signer CLI (address, nonce create/show, transaction sign/simulate/submit). JS client: @solana-program/ed25519-programmatic-signer.

Status: Devnet. Audits before v1. Interfaces may change.

Blueshift Vector

Built by Blueshift (source). One program per signature scheme, same instruction set and account layout:

Scheme	Program ID	Advance cost
Ed25519	`vectorcLBXJ2TuoKuUygkEi6FWqvBnbHDEDWoYamfjV`	~14k CUs
Secp256k1	`9NCknbW4LpePSZzbZGFk2HHsSH4y4pkmRjEguJo7qqjd`	~72k CUs
EIP-191	`G6okL1MvXx7k5eytY7wRXNupXyYG1QVZW37ygAjMiTTu`	—
Falcon-512	`HdkE3dPYgCRZJgLv64mbFmojyCprUim8VRXzK2wR6Qgm`	~184k CUs

Account: PDA ["vector", identity], a 33-byte header plus the identity. It stores the nonce, so the Vector program owns it. Anyone can send SOL in. Only Vector's Withdraw (keeps rent minimum) or Close (empties and deletes) can send it out, both inside a signed Passthrough.

Signing: the client builds the full transaction, puts the nonce and identity where the signature goes, hashes the instruction list with SHA-256, and signs the hash. Onchain, Vector rebuilds the hash from the instructions sysvar and verifies. The signature covers every top-level instruction. A relayer can't add, remove, or reorder anything.

Two top-level instructions:

Advance verifies the signature and stores the hash as the next nonce.
Passthrough runs the embedded instructions via CPI, signing as the PDA. Only works if an Advance for the same PDA appears earlier.

Cancel: sign an Advance with no other instructions. It consumes the nonce and kills every signature made against it. Can be prepared in advance.

Expiry: none built in. Include a deadline instruction like sbpf-asm-timeout.

Concurrency: one outstanding nonce per account. Register more identities for more parallel transactions.

Tooling: Rust (vector-core) and TypeScript SDKs, fully offline signing and verification. MIT license. Audit status not stated.

Both designs run the authorized instructions through CPI. Under Anza's design they start at stack height 3; under Vector they start at stack height 2. Programs that require top-level calls reject both.

Programmatic Signer vs. Vector

	Anza Programmatic Signer	Blueshift Vector
Status	Devnet, audits pending	Program IDs published, audit status not stated
Signature schemes	Ed25519, more via new signer programs	Ed25519, secp256k1, EIP-191, Falcon-512
Signature covers	The authorization message	Every top-level instruction
Payload format	Standard v1 message	Instructions sysvar hash
Relayer may add instructions	Yes, around `Submit`	No
Signer PDA	`["programmatic-signer", authority]`, no setup	`["vector", identity]`, created by `Initialize`
Holding SOL	System-owned account. Send out with a signed `Transfer`	Vector-owned account. Send out with `Withdraw` or `Close`
Replay protection	Separate nonce account, hash chain per message	Nonce in the PDA, hash chain per transaction
Concurrent transactions	Many nonce accounts per authority	One per identity
Multiple signers	Yes	One identity per account
Expiry	None built in	None built in. Add a deadline instruction
Your instructions run at	Stack height 3	Stack height 2
Programs	3 (signer, executor, nonce)	1 per scheme
Tooling	CLI, Rust and JS clients	Rust and TypeScript SDKs
License	Apache-2.0	MIT

In short: the Programmatic Signer stays close to today's durable nonce flow: v1 message payload, multiple signers, relayer flexibility. Vector binds the whole transaction to the signature, supports non-Solana and post-quantum keys, and runs instructions one CPI level higher.

Other Proposals Considered

Seven designs were discussed in SIMD Discussion #456 before CPI Passthrough was chosen.

Proposal	How it works	Pros	Cons
CPI Passthrough (Trent Nelson) — chosen	A program verifies an offline signature over a list of instructions, consumes its own nonce, runs them via CPI	Removes nonces from the validator No runtime change, works today Any transaction format	Authorities move to a PDA Instructions run as CPIs New offline tooling needed
Transaction Envelopes (Hana)	New transaction format with its own fee payer and blockhash wraps a signed legacy nonce transaction	Existing nonce transactions still run Keeps existing keypairs Minimal runtime support	New transaction format Transaction inside a transaction Nonce logic stays in the protocol
Sudo Instruction (Oliver Chalk)	A v1 transaction carries a legacy nonce transaction as instruction data; the validator runs it as if top-level	Existing nonce transactions still run No new format Inner accounts compress to 1 byte	Heavy special handling in the validator Execution traces must hide the wrapper from RPC and explorers
Signer Promotion	A PDA becomes a signer for the rest of the transaction after an offline signature check	Later instructions stay top-level	No clear advantage over CPI Passthrough No owner
Epoch-scoped transactions	A transaction names the epoch it may run in instead of a blockhash; higher fees and bonded fee payers limit spam	Simple for users	Breaks message hash uniqueness New economic rules
Extended blockhash TTL (custodians)	Optional, higher-fee transactions keep their blockhash valid for up to about an hour	The cold signature is the transaction No relayer for short ceremonies Still expires	Doesn't cover multi-day signing Larger status cache Raised as a complement, not adopted
Tiered blockhashes (custodians)	Blockhashes from slots divisible by 10, 100, 1000… stay valid longer, from minutes to about 55 hours	Predictable supply of long-lived blockhashes No nonce accounts	Consensus impact unknown Validators keep more blockhashes Not adopted

About This Upgrade

Durable nonces solved slow signing by adding replay rules to the validator. Those rules caused security incidents, block asynchronous execution, and attract spam. The replacement does the same job in an ordinary onchain program. The validator sees only normal transactions. Offline signers get retries, flexible fee payers, pre-signed chains, and new key types.

Durable nonces keep working until a replacement is audited and live on mainnet. Removal is expected roughly six months after that. This page will be updated when a date is set.

Learn more: Solana Upgrades