Solana Sets May 2027 as the Earliest End for Durable Nonces, the Tool Behind the Drift Hack

Solana developers have put a date on the end of durable nonces, the transaction feature that let attackers drain at least $270 million from trading protocol Drift in April.

A draft proposal called SIMD-0723, filed on November 5 by an engineer at Anza, the firm behind Solana’s main validator client, would remove the feature from the protocol. It says the change “will not be activated on mainnet-beta before 2027-05-05.”

The proposal is still a draft. It needs technical sign-off before it can be merged, and the Solana Foundation’s own deprecation page still lists no final date.

What Durable Nonces Do

Every normal Solana transaction carries a recent blockhash, a stamp tied to a recent block. Once that blockhash is more than 150 blocks old, the transaction expires and can no longer land.

At today’s 200-millisecond block times, that window is about 30 seconds. It used to be roughly a minute when blocks took 400 milliseconds.

Durable nonces swap the blockhash for a value stored in a special account. A transaction signed that way never goes stale, so it can be signed today and submitted weeks later.

That is useful for exchanges, custodians and stablecoin issuers. Their approvals often happen on air-gapped machines kept off the internet, and getting a signature from the vault to the network can take far longer than 30 seconds.

How the Feature Figured in the Drift Hack

The Drift hack on April 1 was not a classic code exploit. As publicly reported after the attack, the attackers got approvals from Drift’s multisig signers ahead of time and let those durable nonce transactions sit for more than a week.

When they finally submitted them, they took control of protocol permissions and emptied the platform within minutes. The approvals were valid on paper, but the context the signers thought they were approving no longer matched how the transactions were used.

Interestingly, SIMD-0723 does not mention Drift at all. Its case rests on something more technical: years of bugs that the feature has caused inside validator software.

Seven Years of Nonce Bugs

The proposal says durable nonces need special consensus rules that every client must preserve “across transaction validation, scheduling, execution, commit, caching and replay.” A change in one layer can quietly break another.

It then lists documented problems going back to 2019, when the feature was introduced.

The most serious came in 2022. According to the proposal, “a failed transaction was processed through both the blockhash and nonce paths, halting mainnet for about 4.5 hours.”

Others include a 2019 flaw that let failed nonce transactions be replayed to drain fees, several fixes in Jump’s Firedancer client between 2024 and 2026, and a 2026 testnet incident in which one client rejected a block that other clients accepted.

The draft also flags spam. A sender can sign many different transactions against one nonce value, and once one lands, the rest pay nothing even though validators still have to receive and check them.

What Changes If SIMD-0723 Passes

“After activation, every transaction needs a recent blockhash,” the proposal says. Durable nonce transactions would simply fail with a “blockhash not found” error, and no fee would be charged.

The System Program would stop creating, advancing and upgrading nonce accounts. Withdrawing from them and changing their authority would keep working, so existing balances are not frozen by default.

There is one edge case. Funded nonce accounts left in an uninitialized state could become permanently locked if no one holds the account’s own key, and the draft says it “accepts that loss.”

The Replacement and Its Own Risks

Instead of a protocol feature, offline signing would move to onchain programs. Anza’s Programmatic Signer and Blueshift’s Vector are the two named options.

The flow works like this:

• Assets and authorities move to an address controlled by the program.
• A cold key signs a message listing the instructions, with no expiry.
• A hot wallet submits it in a normal, short-lived transaction.
• The program checks the signature, uses its own nonce to block replays, then runs the instructions.

The proposal is candid that risk moves rather than disappears. It warns that “a failed execution can leave an authorization usable, so a failed submission is not a revocation.” A custody desk that sees a transfer fail cannot assume the approval behind it is dead.

That lesson echoes recent incidents across the industry, from Drift to Binance restoring HYPE and APT after October’s exchange hack. Operational controls around signing matter as much as the code itself.

What Comes Next

Affected users get “at least six months to migrate,” counted from November 5. The Solana Foundation plan, by contrast, starts its six-month clock only once a replacement is ready, so the real cutoff could land later than May 2027.

Solana is not the only network rethinking old features this season. Ethereum developers are debating a similar trade-off in the Glamsterdam gas repricing for older contracts.

For exchanges and custodians on Solana, the message is clear: the long-lived signed transaction is on its way out, and offline signing workflows will need to be rebuilt before the switch is flipped.