Solana is reportedly weighing whether to retire durable nonces, which allow signed transactions to remain valid beyond the short window for ordinary transactions. The change could reduce the risk of stale approvals, but organizations using offline-signing systems would need to test and migrate to replacement tools.
- Proposal: SIMD-0723 is described as a plan to retire durable nonces, but its formal status and timeline remain unverified.
- Drift: Reports link long-lived approvals to the attack, though the technical sequence and loss figures remain unsettled.
- Migration: Solana points to alternative signing programs, but warns that they are pre-audit and may change.
What durable nonces do
Ordinary Solana transactions use a recent blockhash, a temporary reference that helps prevent old transactions from being submitted indefinitely. Solana’s processing rules determine how long it remains valid, so it should not be treated as a universal, fixed 30-second countdown.
A durable nonce replaces that temporary reference with a value stored in a nonce account. A signed transaction remains valid as long as the account holds the nonce value used to sign it. Advancing the account changes that value and invalidates transactions tied to the previous one.
This can make offline signing practical. An organization can prepare a transaction, send it through an approval process involving devices kept offline, then submit it later. But a durable nonce does not grant authority or execute a transaction by itself. It extends the window in which someone can submit an already-signed transaction. If the signer’s intent changes, that old approval can become a liability unless the nonce is advanced or the transaction is otherwise made unusable.
SIMD-0723 and the Drift connection
A proposal identified in reports as SIMD-0723 would retire durable nonces and require transactions to use recent blockhashes. Solana’s migration guidance does not establish the proposal’s author or filing date, its current governance status, or the reported May 5, 2027 mainnet activation date. Treat that date as tentative, not as an approved deadline.
Reports have linked the proposed change to the Drift Protocol attack, which accounts place on April 1, 2026. Those accounts say attackers obtained administrative approvals through air-gapped signing systems and waited more than a week before submitting transactions. Drift reportedly attributed the attack to a North Korean-linked group.
That account raises a serious security question, but it does not prove that durable nonces were the decisive cause. A long-lived approval may have been one part of a broader failure involving signer procedures, access controls or transaction review. The technical sequence, and the evidence linking the exploit to durable nonces, need to be clear before the proposal can be judged as a direct fix. Earlier coverage also examined how the Drift breach unfolded.
Reported losses also vary. Some accounts cite at least $270 million, while a separate headline gives $285 million. Available incident details do not explain the difference, so neither figure should be treated as a reconciled final accounting. The reported North Korean link is Drift’s attribution, not an independently established conclusion. Coverage of the alleged North Korean connection does not establish it independently either.
Offline signing may remain, but the workflow changes
Retiring durable nonces would not necessarily end delayed or offline signing. Solana’s migration guidance describes two alternatives: Anza Programmatic Signer and Blueshift Vector. Both are available for Devnet testing, the guidance says, but they are pre-audit and may change. That is a serious caveat for organizations considering them for production.
The alternatives handle signed data differently. Anza Programmatic Signer uses a standard Solana message format supported by hardware wallets. Vector asks a key to sign a raw SHA-256 hash, which Solana’s guidance says most hardware wallets refuse to sign. The approaches also represent authorization differently in the final transaction, so wallet interfaces and internal review procedures may need updates.
That matters because an approval process is only as safe as the information signers can understand. Organizations need to know what a signing device is authorizing, how someone can submit a delayed transaction, and how to invalidate it if circumstances change. A different signing format can affect how wallets display or decode an approval. “The key signed something” is not a useful security policy.
Migration involves more than replacing a wallet feature. Solana’s guidance calls for reviewing authorities on wallets, stake accounts, token accounts and mints, and checking programs and infrastructure that depend on nonce instructions. Operators may also need to update software that builds, relays or indexes transactions.
Before migrating, institutions should test replacement workflows, identify which accounts and programs depend on durable nonces, and plan how to cancel stale approvals. Removing one mechanism does not remove the need for careful signing practices. It changes where those practices apply.
Key questions and answers
-
What would SIMD-0723 change?
It is described as a proposal to retire durable nonces and require recent blockhashes instead. Solana’s migration guidance does not establish its formal status or activation schedule.
-
Do durable nonces cause exploits?
No. They extend the validity window of a signed transaction, but do not grant authority. A stale approval can still be dangerous if signing, review or cancellation procedures fail.
-
Does the Drift attack prove durable nonces were the cause?
No. Reports link the attack to long-lived approvals, but the technical sequence and role of durable nonces have not been established in enough detail to prove causation.
-
Will offline signing disappear?
Not necessarily. Solana describes alternative signing programs, but says they are pre-audit and available for Devnet testing. Their readiness for production and migration requirements need careful review.
The practical test is whether replacement tools are audited, clear to signers and ready before operators have to migrate. Until then, a proposed security change is not a completed security upgrade.
