Solana plans to retire durable nonces for an onchain signer program. Both designs roll back a failed transaction's nonce, so a signature can be resubmitted.
SOL$108.02-4.08%Solana's plan to retire durable nonces starts from a small, annoying detail: today an approval that fails on its way through still burns the nonce behind it. If a swap slips past the limit a cold key signed off on, that key has to sign the whole thing again.
Both replacement designs fix that. The nonce advances in the same atomic transaction as the instructions, so if anything fails the nonce rolls back and you can resubmit the same message. One signature, one trip to the cold key.
The bigger news is that the mechanism itself is going away. The Solana Foundation's upgrade page states plainly that durable nonces will be removed, with the shape of the replacement settled: an onchain program that verifies an offline signature. What is not settled is which one. Two implementations are under development, Anza's Programmatic Signer and Blueshift's Vector.
Normal Solana transactions are built to expire. A transaction dies 150 blocks after the blockhash it references, about 30 seconds at 200 millisecond slots, down from 60 seconds at 400 millisecond slots. That is fine for a wallet doing everyday things and impossible for a signer that never touches the internet.
Durable nonces exist for that gap. They keep a transaction valid across a slow approval process, which is why exchanges, custodians and stablecoin issuers lean on them for air-gapped signing and long approval flows.
For everyone else this is invisible. Only durable nonce users need to act. Wallets and apps work as before, and if your custodian uses durable nonces, the custodian handles the migration.
The concentration is real, though. In one epoch in June 2026, nonce transactions were 3.1% of all transactions but paid 30% of all priority fees, and 555 fee payers sent 97.5% of them, per SIMD Discussion #564 cited on the upgrade page. Few users, large amounts.
Today a durable nonce transaction that fails, on slippage for example, still advances the nonce. The cold key must sign again. For a custodian with a hardware process behind every signature, that is a round trip for every failed attempt, and failed attempts are how limit orders behave on a busy day.
Under either replacement, the nonce moves in the same transaction as the instructions. Failure rolls it back. The same message goes back in as-is.
There is a tradeoff. Neither program has a built-in expiry. A signed message stays valid until it is used or cancelled, and any deadline has to be added by an instruction where you want one. Vector's README says it stays deliberately unopinionated about expiration, so users can compose with whatever deadline primitive suits them, slot-based, unix-time-based or oracle-based, without bloating the core protocol.
Vector's version also carries a sharper edge. Its documentation warns that it only invalidates a signature once its nonce advances, so a signature revealed in a transaction that failed for a transient reason like slippage could later become valid and be replayed. A malicious relayer could withhold the transaction until conditions move in its favour. The rollback that makes retries easy is the same thing that keeps an old signature alive.
Seven designs were discussed in SIMD Discussion #456 before core developers converged on one called CPI Passthrough. It won for a maintenance reason: it is the only option that removes nonces from the validator entirely and needs no runtime change.
The cost lands on accounts that hold authority. Under CPI Passthrough, account authorities move to a program-derived address, and instructions run as cross-program invocations instead of top-level calls. That has consequences:
sol_get_stack_height() == TRANSACTION_LEVEL_STACK_HEIGHT rejects any call arriving through a CPI, which in this design includes every one of these signatures.Migration is manual and list-shaped. Token account owner and close authorities, token mint and freeze authorities, and stake and withdraw authorities all have to be accounted for. Token accounts need a new associated token account owned by the PDA with the tokens transferred into it, and native SOL has to be sent to the PDA. Deriving the address does not move any assets or permissions on its own; the transfers are the part that touches funds.
One detail helps. The new signature covers neither the fee payer nor the blockhash, so anyone can submit and pay, whether that is the key holder, a relayer or an RPC provider. The cold key never needs SOL.
Fireblocks, which says it manages signing infrastructure for thousands of institutional clients across millions of Solana addresses, argued in the discussion that the chosen design breaks at institutional scale:
We believe the CPI Passthrough (Contract-based) proposal, while architecturally elegant and the safest from a validator-maintenance perspective, is fundamentally incompatible with the realities of large-scale institutional custody.
Unit 410, a noncustodial cold storage provider, made the timing problem concrete:
We will never be able to sign within 60 seconds. The offline signing process, while automated, simply takes longer than 60 seconds.
Unit 410 also rejected the obvious workaround of moving assets to an ephemeral hot signer, saying funds must remain associated with the cold storage wallet and cannot be sent to a temporary hot key no matter how short its life. Anchorage Digital added that CPI Passthrough is likely a non-starter in practice.
Nothing here is on mainnet, and the timing is soft. Core developers said durable nonces stay until a suitable replacement is available and enough time to migrate has passed. Removal is expected roughly six months after the replacement program is ready, and no date has been set. Institutions asked for 6 to 12 months after mainnet availability against that roughly six-month plan.
On the two candidates: Anza's Programmatic Signer is deployed on Devnet with audits pending, and its own documentation says interfaces may change before the v1 release and before any mainnet deployment. In that design none of the three blockhash fields gives an authorization a deadline, so a deadline has to be enforced by an instruction in the execution message. Vector publishes implementation code and program IDs.
What would move this forward is a final choice between the two programs, a finished audit and a live mainnet deployment. Until then, if you do not use durable nonces, nothing changes for you. If you do, the thing to watch is not the calendar. It is whether either program clears its audit and reaches mainnet first.
NEAR Intents' GM says only part of the $3.8 million exploit refund came back in Bitcoin, with the rest in Monero the team still must convert.
NEAR
BTC+1 more
Ontology resumed block production on Oct. 12 after a two-day security halt tied to an unnamed ecosystem project, its second shutdown in about six weeks.
Cardano processed 1,780,896 transactions in Epoch 660, its busiest five-day stretch in about five years, while two governance votes expired short of quorum.
