Solana developers have proposed removing durable nonces, a feature used in the attack that caused more than $270 million in losses at Drift Protocol. The SIMD-0723 proposal seeks to remove a mechanism that allows signed transactions to remain valid for extended periods.

The attack on Drift occurred in April, when hackers obtained advance authorizations and executed them more than a week later. This feature allowed them to prepare transactions that subsequently facilitated the takeover of the protocol.

The proposal was submitted by Gabe Rodriguez of Anza after the Solana Foundation announced plans in October to retire the feature. The change still requires technical approval and cannot be activated before May 5, 2027.

The decision raises a question about Solana’s security. Does removing a problematic feature demonstrate that its developers can correct mistakes, or confirm that the network retained known threats for too long?

The Drift Hack Exposed the Risks of a Legitimate Feature

Durable nonces allow transactions to be signed without being subject to the usual expiration window. On Solana, a conventional transaction uses a recent blockhash and generally expires after approximately 30 seconds.

This alternative is useful for custodians and platforms that need to approve transfers using devices disconnected from the internet.

However, the ability to execute previously authorized transactions can also be exploited by attackers.

In Drift’s case, the attackers obtained approvals from members of the multisignature system and held the transactions until they executed the attack. The incident did not require directly exploiting a vulnerability in the protocol’s smart contract code.

This detail is crucial because it demonstrates that a technically valid feature can become a problem when combined with weaknesses in authorization procedures.

The Solana Foundation has also identified other problems associated with durable nonces. Its documentation mentions security vulnerabilities, difficulties implementing asynchronous execution, and repeated operations that can increase network congestion.

In 2022, an error related to processing these transactions caused a network outage lasting approximately four and a half hours.

The problems therefore did not begin with Drift. The discussion about removing durable nonces stems from difficulties accumulated over several years, although the hack provides a particularly costly example of their consequences.

Removing a Feature Does Not Guarantee That Every Problem Will Be Solved

The SIMD-0723 proposal aims to require all transactions to use a recent blockhash. Authorizations that need to remain valid for longer periods would instead be handled through independent programs.

The alternatives include Programmatic Signer, developed by Anza, and Vector, developed by Blueshift. Both allow signatures created offline to be verified through programs running on Solana.

This would reduce the special rules validators must process, but it would also require custodians and exchanges to adapt their authorization systems.

The Solana Foundation expects a migration period of approximately six months once a suitable alternative is ready. It has not yet established a definitive date for removing the feature.

Furthermore, the proposed mechanisms carry risks of their own. A failed transaction can leave an authorization available for subsequent attempts, meaning users will need to manage its revocation carefully.

Moving a feature outside the protocol does not automatically eliminate implementation errors or operational problems.

Security will depend on appropriate audits, testing, and procedures for managing signatures.

This could reduce the complexity of validator software, but it would be premature to claim that it will prevent attacks similar to the Drift exploit.

Trust in Solana Depends on How It Implements the Changes

Solana has historically prioritized processing speed and the ability to execute large numbers of transactions. However, performance loses some of its appeal when users must accept risks that are difficult to identify.

Removing durable nonces also creates obligations for developers. Custodians that use offline signatures will need to modify procedures that protect substantial amounts of assets.

Accelerating implementation without providing sufficiently tested tools could introduce new vulnerabilities.

The proposal requires approval from technical representatives of Anza and Firedancer. This process allows the change to be reviewed before it is incorporated into the network’s software.

The ability to correct mistakes is necessary, but how long problematic mechanisms remain active also matters.

Directly comparing Solana’s security with Ethereum’s does not provide a simple answer either. Both networks use different architectures and face risks involving their applications, validators, and authorization procedures.

A blockchain’s maturity should be assessed through its history of incidents, the quality of its audits, and its ability to implement changes without compromising users’ funds.