Solana Weighs End to Durable Nonces After Drift Hack

What to Know

Solana developers have proposed retiring durable nonces, a transaction feature that keeps signed transactions valid indefinitely.
Attackers used the feature in the April Drift exploit, which drained at least $270 million from the trading protocol.
The draft proposal, known as SIMD-0723, was filed on Nov. 5 by Gabe Rodriguez of Anza, the firm behind Solana’s main validator software.
The change would not activate on mainnet-beta before May 5, 2027, giving users at least six months to migrate from the proposal’s publication date of 2026-11-05.
The Solana Foundation’s migration requirements could push the effective deadline later, as its deprecation page still says no date is set.
Durable nonces are used by custodians and exchanges that rely on air-gapped signing, where approval and submission can take longer than the ordinary transaction expiry window.
Normal Solana transactions use a recent blockhash and expire after about 30 seconds now that the network runs 200-millisecond blocks.
Durable nonce transactions accounted for about 3% of Solana traffic in one June measuring period but paid 30% of all priority fees.
Data cited by researcher Max Resnick showed that 555 accounts sent 97.5% of durable nonce transactions in that measuring period.
The proposal still requires technical approval from at least one engineer at Anza and one at Firedancer before it can be merged.

Solana Developers Target a Long-Running Transaction Feature

Solana developers are moving toward a major change in how the network handles certain pre-signed transactions, with a draft proposal seeking to retire durable nonces, a feature that allows a signed transaction to remain usable indefinitely. The proposal has gained attention because the same mechanism was used by attackers in the April exploit against Drift, where at least $270 million was stolen from the trading protocol.

The proposal, labeled SIMD-0723, would require every transaction to use a recent blockhash after activation. In plain terms, that would end the ability for a transaction signed today to be held and submitted far into the future under the durable nonce system. The proposal was filed on Nov. 5 by Gabe Rodriguez of Anza, the firm behind Solana’s main validator software, and it remains subject to technical approval before it can be merged.

The draft states that the feature will not be activated on mainnet-beta before May 5, 2027. That date is designed to provide at least six months for affected users to migrate, counted from the proposal’s publication on 2026-11-05. However, the Solana Foundation’s own migration framework could push the transition further out because its deprecation page still says no date is set and starts the clock only once a replacement is ready.

Why Durable Nonces Matter on Solana

Under normal conditions, every Solana transaction carries a stamp tied to a recent block, known as a blockhash. That blockhash is part of what keeps the network from processing stale instructions long after they were created. With Solana running 200-millisecond blocks, ordinary transactions currently expire after about 30 seconds. This short validity window is part of the network’s design for speed and finality, but it can create operational challenges for institutions that do not sign transactions directly from internet-connected systems.

Durable nonces were designed to solve that problem. Instead of relying on a recent blockhash that quickly expires, the mechanism allows a transaction to use a nonce that does not go stale in the same way. That means a transaction can be signed offline and submitted later, even if the normal blockhash window would have already closed. For custodians and exchanges, that buffer can be important because approval may happen on air-gapped machines, meaning computers kept off the internet for security reasons.

Offline signing is a common security practice for firms that handle large amounts of digital assets. By separating signing systems from the public internet, custodians reduce exposure to remote compromise. The tradeoff is speed. Moving a transaction from an air-gapped approval process to network submission may take longer than the ordinary Solana expiry window. Durable nonces gave these institutions time to complete that process without having to keep hot signing systems online.

How the Drift Exploit Changed the Debate

The same flexibility that helped legitimate custody operations also created a risk surface. In the Drift incident, attackers obtained approvals signed in advance and allowed those transactions to sit for more than a week before using them on April 1 to empty the trading platform. Drift later attributed the attack to a North Korean state-affiliated group. The exploit put renewed attention on whether indefinitely valid transaction authorizations are compatible with the security expectations of a high-speed blockchain.

SIMD-0723 does not center its argument on Drift by name. Instead, it points to a broader history of technical problems involving durable nonces. One cited incident from 2022 involved a failed transaction being processed through both the blockhash and nonce paths, halting mainnet for about 4.5 hours. For developers, that kind of history supports the case that removing the feature could simplify transaction logic and reduce future risk.

Market participants watching Solana’s infrastructure roadmap are likely to view the proposal as part of a larger effort to harden the network after periods of strain and high-profile exploits. The issue is not simply whether durable nonces were misused in a single attack. It is whether the network should continue supporting a mechanism that allows pre-signed transactions to remain valid far beyond the default expiry period.

Custodians and Exchanges Face the Biggest Adjustment

The impact of the proposal would not be evenly distributed across Solana users. Most retail users and ordinary decentralized application activity rely on standard transaction flows and would likely see little direct change. The burden would fall more heavily on custodians, exchanges and other institutions that depend on air-gapped approval workflows. These firms may need to adopt new onchain programs or redesign internal procedures for authorizing transfers.

The proposed replacement path includes onchain programs that verify offline signatures, with Anza’s Programmatic Signer and Blueshift’s Vector named as options. These alternatives aim to preserve some of the operational benefits of offline approval without relying on durable nonces. Yet they are not risk-free. The draft warns that a failed execution can leave an authorization usable, meaning a failed submission should not be treated as a revocation.

That warning is important for custody desks. If a transfer attempt fails, the underlying approval may still be live under certain replacement models. Firms would therefore need controls to track whether authorizations remain valid, whether they can be canceled, and how staff should respond to failed submissions. The operational challenge is less about losing a convenience feature and more about ensuring that authorization lifecycles are fully understood.

Fee Data Shows a Concentrated Use Case

Available data suggests durable nonce activity is relatively small by transaction count but meaningful by fee contribution. In one June measuring period, durable nonce transactions represented about 3% of Solana’s traffic while paying 30% of all priority fees, the tips users add to get processed first. That imbalance indicates that the feature was used by a concentrated set of high-value or high-urgency senders rather than by the broader network equally.

Researcher Max Resnick’s data also showed that just 555 accounts sent 97.5% of durable nonce transactions during that measuring period. The data does not identify who operates those accounts, and the activity was described as durable nonce spam being coopted. Even so, the concentration helps explain why developers may believe the network can retire the feature without disrupting most users, while still acknowledging that a smaller set of institutions may face significant migration work.

Priority fee dynamics matter because they show how certain transaction pathways can shape network economics. If a narrow group of users accounts for a large share of fees tied to a specialized feature, removing that feature may alter behavior among sophisticated actors. Some may move to replacement programs, while others may restructure transaction submission strategies to fit the standard blockhash model.

Approval Process and Timeline

The proposal is still in draft form and requires additional technical review. Before it can be merged, it needs sign-off from at least one engineer at Anza and one at Firedancer, the rival validator software built by Jump. That requirement reflects Solana’s multi-client direction and the importance of ensuring that major protocol changes are reviewed across independent validator implementations.

The earliest stated mainnet-beta activation date is May 5, 2027, but the deadline is not necessarily final. The Solana Foundation’s migration process may delay the cutoff if replacement tooling is not considered ready. This creates a transition period in which custodians, exchanges, wallet infrastructure teams and application developers can test alternatives while durable nonces remain available.

For Solana, the core policy question is how to balance institutional custody needs against protocol simplicity and security. Durable nonces helped solve the practical problem of offline signing in a fast network environment. But the Drift exploit and earlier bugs have made the cost of indefinite transaction validity harder to ignore. If SIMD-0723 advances, it would mark a clear shift toward tighter transaction freshness requirements across the network.

What It Means for Solana’s Security Roadmap

The proposal signals that Solana developers are willing to remove legacy or specialized features when they create outsized operational and security risks. That approach may be welcomed by technical traders and infrastructure-focused market participants who want clearer, simpler transaction rules. At the same time, the migration burden for custody providers should not be minimized, especially for firms that have built compliance, approval and treasury systems around air-gapped signing.

The market impact is likely to depend on execution. A smooth transition, with reliable replacements and a long runway, could strengthen confidence in Solana’s infrastructure. A rushed or confusing migration could introduce new operational risks for the very institutions the network wants to support. For now, the long lead time and formal approval process suggest developers are treating the change as a significant protocol event rather than a quick patch.

FXCOINZ will continue watching how the proposal develops, particularly whether institutional infrastructure providers publicly endorse the replacement models and whether the activation date remains tied to May 5, 2027. The outcome could reshape how large Solana transfers are approved, submitted and monitored in the years ahead.

Frequently Asked Questions (FAQs)

What are durable nonces on Solana?

Durable nonces are a Solana transaction feature that allows signed transactions to remain valid indefinitely instead of expiring after the normal recent blockhash window.

Why do Solana developers want to retire durable nonces?

Developers are seeking to reduce risks tied to indefinitely valid signed transactions, including security concerns highlighted by the Drift exploit and earlier technical incidents involving the feature.

How was the feature connected to the Drift hack?

Attackers used approvals that had been signed in advance and left them unused for more than a week before submitting them on April 1 to drain at least $270 million from Drift.

When could durable nonces be removed?

The draft proposal says the change will not activate on mainnet-beta before May 5, 2027, although Solana Foundation migration requirements could push the effective date later.

Who would be most affected by the change?

Custodians, exchanges and other institutions that rely on air-gapped offline signing would be most affected because their approval workflows can take longer than Solana’s ordinary transaction expiry window.

How long do normal Solana transactions remain valid?

Normal Solana transactions use a recent blockhash and currently expire after about 30 seconds, with the network running 200-millisecond blocks.

What replacements are being considered?

The proposal points to onchain programs that verify offline signatures, including Anza’s Programmatic Signer and Blueshift’s Vector, as possible alternatives for affected users.

Are the proposed alternatives risk-free?

No. The draft warns that a failed execution can leave an authorization usable, meaning a failed submission should not automatically be treated as a revoked approval.