Solana Durable Nonce Removal: What Happens to Already-Signed Transactions?
Solana’s SIMD-0723 draft would retire transactions that can wait indefinitely before submission, raising a practical question for wallets, treasuries and custodians after the Drift hack.
By Nate Urbas | Reporting checked: November 9, 2026, 10:39 UTC
If you send SOL using an ordinary wallet transaction, nothing changes today. You do not need to move funds or switch wallets because a proposal was filed. But an already-signed payment using a durable nonce would stop working after the proposed change activates, even if its signer approved it earlier. I checked the SIMD-0723 draft: it remains a proposal, and May 5, 2027 is the earliest possible mainnet activation date, not a confirmed shutdown.
What Solana is proposing—and what it isn’t
SIMD-0723, submitted November 5 by Gabe Rodriguez of validator-software developer Anza (listed as “Gabe R.” in the draft), would make every Solana transaction use a recent blockhash. It would disable nonce initialization, advancement and upgrades but retain withdrawals and authority changes. The proposal is open, not accepted or activated; software implementation and network activation are separate steps.
The latest material revisions I found were on November 6, adding a SIMD-0602 reference and a migration notice. The Solana Foundation still says no date is scheduled and describes a migration window after a replacement is ready.
This concerns transaction submission, not a forced move of SOL held on the Layer 1 Solana network.
The Monday signature that can wait until Friday
Imagine a treasury officer signs a 100 SOL supplier payment offline on Monday, but a colleague cannot broadcast it until Friday.
A regular Solana transaction includes a recent blockhash, which expires after a limited number of blocks. Monday’s ordinary signed transaction would be too old on Friday. A durable nonce instead uses a special account holding a nonce value; while that value remains current, the payment can wait without the usual blockhash expiry. Some custodians, exchanges and treasuries use this for air-gapped signing. Solana documents the mechanism.
The signature approves that exact payment, including the recipient, amount and message details. A colleague holding the signed transaction cannot simply edit those details without invalidating the signature. The danger is that authorization can remain executable long after the signer expects. Advancing the nonce invalidates signatures tied to the old value.
What happens to that signed payment after activation?
I followed the Monday payment through the draft’s transaction-lifetime and account rules. Three answers matter.
Can the colleague broadcast the old payment? No. Under the draft, once activation happens, the old durable-nonce transaction fails its lifetime check with BlockhashNotFound, even if its stored nonce still matches. Submitting it later cannot revive it.
Can someone insert a fresh blockhash and keep the signatures? No. Changing the blockhash changes the signed message, invalidating the old signatures. The payment needs rebuilding and re-signing; keeping AdvanceNonceAccount would also fail because that instruction is disabled.
Does the balance disappear? No. The draft does not sweep accounts or move SOL at activation. Existing initialized nonce accounts can still use the withdrawal and authority-change instructions under existing signing rules. But there is a narrow exception: a funded, uninitialized nonce account without an available account-address signer may become permanently inaccessible once initialization is disabled. The draft requires SIMD-0610 safeguards before activation. Ordinary wallet balances face no such risk.
What the April Drift hack actually tells us
On April 1, 2026, attackers took administrative control of Solana-based Drift Protocol and extracted assets. Chainalysis estimated the loss at about $285 million; an early CoinDesk report used “at least $270 million”. These are estimates of one incident.
BlockSec’s on-chain reconstruction identifies two durable-nonce transactions, four slots apart, that approved and executed an administrative transfer. Drift’s Security Council required two of five approvals and had no execution timelock. After taking control, the attacker enabled artificially priced CVT collateral and loosened withdrawal protections before extracting real assets. The chain shows privileged instructions executed, not what signers saw, who requested approval or when signatures were obtained.
Drift and Chainalysis describe social engineering and misleading approvals; those claims are not independently visible on-chain. Withdrawal windows differ: BlockSec counts 31 withdrawals in roughly 12 minutes; Guardian says Chainalysis tracked a later final confirmed transfer. Neither a nonce nor a delayed broadcast forged a signature or stole a private key. Permissions, review and timing mattered.
I also checked the proposal’s own rationale. It does not cite Drift as its stated reason. Instead, the author points to validator complexity, replay and consensus bugs, a 2022 outage and transaction spam. The filing followed Drift; causation is unproven. For broader background on such risks, see CryptoLinks’ blockchain security resources.
Who needs to check something now?
| Who | If the draft activates as written | What to check now |
|---|---|---|
| Everyday wallet users | Ordinary recent-blockhash transfers continue working. | No emergency move. Check whether a specific app actually uses durable nonces; a non-custodial wallet or hardware wallet does not automatically imply nonce use. |
| Offline or air-gapped signers | Long-delayed, pre-signed nonce payments become unusable. | Inventory pending payments; confirm whether signers can meet again to authorize replacements. |
| Treasury multisigs | Only workflows collecting signatures on a single durable-nonce transaction must change; program-recorded approvals are a different design. | Ask which signing flow is used, who controls nonce authority and whether the provider has documented a migration. |
| Wallet and custody developers | Nonce creation, advancement and upgrade calls fail, even inside programs. | Audit SDKs, queued submissions and instructions; test withdrawals, authority changes and any replacement integration. |
The proposed replacement moves responsibility, not risk, away
One approach named in the SIMD draft lets a cold signer approve instructions offline rather than signing a transaction that must remain valid for days. A relayer later places that approval inside a fresh, normal Solana transaction. An on-chain program checks the signature and runs the approved instructions.
This is not a drop-in upgrade. Under the described design, asset ownership or signing authority must be moved to a program-derived address controlled through the replacement program. Users then depend on that program to verify the intended instructions and correctly enforce expiry, replay prevention and revocation. A failed submission may leave the authorization usable. Anza’s Programmatic Signer and Blueshift’s Vector are examples under development, not a universally endorsed drop-in replacement.
My conclusion is straightforward: regular wallet users need not act on this draft; organizations holding outstanding durable-nonce signatures should start identifying them now. The next meaningful news is a revised or accepted SIMD, a tested client implementation, a replacement audited and live on mainnet, or an announced activation date. No shutdown is scheduled. I will follow that through CryptoLinks News; readers can also use the CryptoLinks homepage to find wallet and security research.
Editorial disclosure: This is general technology and security reporting, not personalized financial advice. CryptoLinks may earn commissions from some directory links; the reporting above does not depend on a purchase or registration.
