Drift Hack Explained: Solana Durable Nonces, the $270M Exploit and SIMD-0723

Most crypto hacks get explained as "a bug in a smart contract" or "a leaked private key." The Drift protocol hack was neither. Every transaction that moved funds was validly signed by people who were authorized to sign. What broke was timing: a Solana feature called durable nonces let signatures collected days earlier be used at the moment the attacker chose.

We wrote this guide for two groups. First, anyone who wants to understand what durable nonces are and why Solana developers now want to remove them. Second, investors who join token sales and want to know how to check that a project's treasury could not be emptied the same way. The second part is where we spend most of our time, because that is the part you can act on today.

Why Normal Solana Transactions Expire So Fast

Every Solana transaction includes a "recent blockhash," a fingerprint of a recent block. Validators only accept a transaction while that blockhash is fresh. According to the SIMD-0723 proposal text published on GitHub by the Solana Foundation's improvement-documents repository, "a transaction expires once its recent blockhash is more than 150 blocks old." In wall-clock terms that is roughly a minute; CoinDesk (as summarized by PrimeXBT on November 9, 2026) describes the practical window as about 30 seconds.

This short life is a security feature, not just a technical detail. It means:

• A signature cannot be replayed later. Once the blockhash is stale, the signed transaction is useless.
• A mistake has a short shelf life. If you sign something wrong and it is not broadcast quickly, it simply dies.
• Signer intent and execution stay close together. What you approved is what happens, at roughly the time you approved it.

BlockSec, the blockchain security firm that published a detailed technical analysis of the Drift incident on April 3, 2026, calls this short expiry "an implicit safety layer" that multisig security quietly depends on.

What Is a Durable Nonce on Solana?

A durable nonce replaces the short-lived recent blockhash with a value stored in a dedicated on-chain "nonce account." The transaction stays valid for as long as that stored value does not change. In practice, that means a transaction signed today can still land next week or next month. The SIMD-0723 text notes that durable nonces were proposed and implemented in 2019 specifically "to support offline and delayed signing."

Under the hood, a durable nonce transaction must start with the System Program instruction AdvanceNonceAccount. When it executes, the nonce value changes, so the same signed transaction cannot be used twice. The only way to "cancel" a signed durable nonce transaction before it is used is for the nonce authority to advance the nonce manually. BlockSec's analysis stresses this point: once a signer approves a durable nonce transaction, they cannot simply revoke the signature.

Legitimate use cases for durable nonces

Durable nonces were not built for attackers. They solve real operational problems:

• Air-gapped custody. Exchanges and custodians often sign withdrawals on machines that never touch the internet. Moving a signature from an offline device to the network can take far longer than a minute. PrimeXBT's summary of CoinDesk's reporting names this as the main reason custodians and exchanges rely on the feature.
• Multisig approvals across time zones. A treasury that needs three of five signers cannot always gather everyone inside a 60-second window.
• Hardware wallet workflows. Users who carefully review a transaction on a hardware device, or pass it through a compliance check, need more time than the blockhash allows.
• Scheduled or pre-authorized payments. Some teams pre-sign transactions to be broadcast later by a relayer.

How much is this used? According to researcher Max Resnick, as cited by CoinDesk and summarized by PrimeXBT, durable nonce transactions were about 3% of Solana traffic in one June 2026 measuring period but paid about 30% of all priority fees, and just 555 accounts sent 97.5% of them. That profile fits a small number of professional operators, not ordinary users.

How the Durable Nonce Feature Was Used to Drain Drift for at Least $270 Million

Drift is a Solana-based trading protocol whose high-privilege actions, such as admin changes, market creation and withdrawal-limit adjustments, are controlled by a multisig rather than a single key. According to BlockSec's technical post-mortem published April 3, 2026, Drift used the Squads multisig framework with a 2-of-5 threshold and, critically, zero timelock on its Security Council: any two of five signers could authorize administrative actions with immediate effect.

The attack, as reconstructed by BlockSec from on-chain data and Drift's own timeline, ran in three phases over several weeks:

1. Pre-attack staging (weeks before April 1). The attacker manufactured a fake collateral token ("CVT"), seeding small amounts of liquidity and wash-trading it to build an artificial price history. In parallel, the attacker used phishing or misleading signing requests to get two of Drift's five Security Council signers to pre-sign durable nonce transactions tied to a malicious admin-transfer proposal. On March 23, 2026, four durable nonce accounts appeared on-chain: two linked to Drift signers, two controlled by the attacker, according to BlockSec's timeline. When Drift rotated its Security Council on March 27 due to a member change, it should have invalidated the earlier signatures — but by March 30, a new durable nonce account tied to a signer under the updated multisig appeared, showing the attacker had regained the needed signatures.
2. Governance takeover (April 1, roughly 16:05 UTC). The attacker submitted two pre-signed durable nonce transactions four slots apart. The first created and approved the malicious proposal; the second executed AdvanceNonceAccount to activate the stored nonce, then proposalApprove and vaultTransactionExecute, ending in UpdateAdmin, which transferred administrative control of Drift to the attacker's address. BlockSec notes the attacker waited roughly a minute after a legitimate Drift insurance-fund withdrawal, suggesting real-time monitoring to confirm the system looked normal before striking.
3. Fund extraction (same day, about 12 minutes). With admin control, the attacker listed the fake CVT token as collateral, switched to an attacker-controlled price oracle to inflate its value, relaxed withdrawal protections, then executed 31 rapid withdrawals, draining USDC, JLP, SOL, cbBTC, USDT, wETH and other assets. BlockSec puts the final on-chain total at $285,279,417.69; CoinDesk's reporting (via PrimeXBT and FinScans) describes the loss as "at least $270 million." Security firm TRM Labs attributes the operation to a suspected North Korean state-linked group, in a blog post discussing the incident.

BlockSec's core technical finding is worth stating plainly: "durable nonces decouple signing from execution, removing the implicit temporal guarantees that signers rely on." The keys were never stolen. The approval pipeline — what the signers thought they were approving, and when it would actually execute — was manipulated instead. We did not find a public full post-mortem from Drift Labs itself as of this writing; the technical reconstruction above comes from BlockSec's independent analysis plus Drift's own partial timeline disclosures, as cited by BlockSec.

What SIMD-0723 Proposes

SIMD-0723, titled "Remove Durable Nonces," was filed on November 5, 2026 by Gabe Rodriguez of Anza, the firm behind Agave, Solana's main validator client. Its status on GitHub is Draft as of November 9, 2026. The summary is short: "After activation, every transaction needs a recent blockhash."

In concrete terms, the draft would:

• Make every transaction depend only on a recent blockhash (the 150-block window). A durable nonce transaction would fail with BlockhashNotFound, and a block that includes one would be invalid.
• Disable three System Program instructions: InitializeNonceAccount, AdvanceNonceAccount and UpgradeNonceAccount. These would fail with InvalidInstructionData, including when called through cross-program invocation (CPI).
• Keep WithdrawNonceAccount and AuthorizeNonceAccount working, so owners can still pull SOL out of existing nonce accounts.
• Leave existing nonce accounts untouched at activation. The authors explicitly rejected sweeping or closing them, because that "would move user funds without their owners' signatures."
• Depend on another proposal, SIMD-0610 (Prohibit Nonce Account Self-Withdrawals), being active first, so no new permanently locked balances are created.

Interestingly, the proposal does not mention Drift at all. Its case rests on years of maintenance problems. The SIMD-0723 text lists a 2019 fee-replay vulnerability, a 2020 failure-path vulnerability, a 2022 mainnet incident in which a failed transaction processed through both the blockhash and nonce paths halted mainnet for about 4.5 hours, several Firedancer bugs from 2024 to 2026, and a 2026 testnet incident. It also argues durable nonces invite spam, because a sender can sign many transactions against one nonce value and only one has to pay. The Drift connection is the reason the proposal made headlines, but the engineering argument is broader.

Who Is Affected by Removing Durable Nonces?

The table below summarizes the practical impact of SIMD-0723 by user type, based on the "Impact" section of the proposal text. Treat it as a planning guide, not a final rule: the proposal is still a draft.

Timeline: from the Drift hack to the earliest activation

• March 11, 2026: Attacker begins staging the fake CVT collateral token, according to BlockSec.
• March 23 to 30, 2026: Durable nonce accounts tied to Drift signers appear on-chain; the attacker re-obtains signatures after Drift's March 27 council rotation.
• April 1, 2026: Admin takeover and roughly 12 minutes of withdrawals; at least $270 million lost.
• November 5, 2026: SIMD-0723 "Remove Durable Nonces" filed as a draft.
• May 5, 2027 (earliest): The proposal states the feature "will not be activated on mainnet-beta before 2027-05-05." The real date could be later: CoinDesk, as summarized by PrimeXBT and FinScans, reports the Solana Foundation's deprecation page only starts its six-month clock once a replacement is ready and still says "No date set."

Treasury Security Checklist for IDO and IKO Investors

Here is the part most news coverage skips. The Drift hack was a treasury governance failure: a 2-of-5 multisig with no timelock, and signers who approved transactions they did not fully understand. Every token project you consider in an IDO or IKO has a treasury, a token contract with admin powers, or both. The same questions apply on any chain, not only Solana.

Before you commit funds to a token sale, try to answer these questions from the project's docs, audit reports, block explorers or AMA sessions. If the team cannot or will not answer them, treat that as information.

1. Who holds the treasury and admin keys? Is it a single wallet, a named multisig, or a DAO contract? Ask for the actual addresses and check them on an explorer. A single externally owned wallet controlling the treasury is a red flag.
2. How many signers, and what threshold? 2-of-5, like Drift, means compromising just two people is enough. Larger thresholds (for example 4-of-7) and signers from different organizations raise the bar. Our guide on how multi-sig wallets enable decentralized governance explains how to read these setups.
3. Is there a timelock on admin actions? A timelock forces a delay (for example 24 to 72 hours) between approval and execution of sensitive changes, such as admin transfers, oracle changes or withdrawal limit changes. BlockSec's Drift analysis states that a timelock "would have created a response window to identify and block the malicious transfer." Zero timelock on a protocol holding user funds is a serious warning sign.
4. When was the last audit, and did it cover governance? Many audits only look at smart contract code, not at how the multisig is configured or how signatures are collected. Check the date and scope. Our security audit checklist for Web3 crowdfunding projects lists what a meaningful audit should include.
5. Does the project use delayed or offline signing, and how? On Solana, ask whether treasury or admin transactions are signed with durable nonces today, and what the migration plan is before SIMD-0723 could activate. On any chain, ask whether pre-signed transactions can sit unexecuted for days, and how a signer would revoke one.
6. What can the admin key actually do? Can it list new collateral, change price oracles, mint tokens, or lift withdrawal limits? The Drift attacker used exactly those powers. The fewer emergency powers sit behind a fast-acting key, the smaller the blast radius.
7. Is there monitoring and an incident plan? Does the team use on-chain monitoring for governance changes, and is there a public process for pausing contracts?

These questions fit alongside the tokenomics, team and vesting checks we cover in our complete IDO due diligence checklist. If you want to spot broader warning signs, such as unlocked liquidity or anonymous teams with mint authority, see how to spot rug risks on launchpads. A treasury with weak governance is not always a rug pull, but from an investor's perspective the outcome can look the same.

Custody failures are not unique to Solana. For a comparison with centralized exchange and bridge incidents, read our breakdown of what the Bitget, Liquid Network and Coldcard breaches teach about custody.

Practical Wallet Safety: How Not to Become the Signer Who Gets Tricked

The Drift signers were not careless amateurs; they were Security Council members of a large protocol. That is exactly why the following habits matter for everyone, from treasury signers to ordinary users:

• Never blind-sign. If your wallet or hardware device shows a transaction you cannot read, such as raw hex or "unknown instruction," do not approve it. Ask for a human-readable explanation first.
• Use transaction simulation. Most major Solana wallets simulate a transaction before you approve it and show the expected balance and authority changes. If the simulation shows an authority change, an admin update or an unexpected token outflow, stop.
• Watch for AdvanceNonceAccount. A transaction that starts with this instruction is a durable nonce transaction: it may not expire. If you did not expect a delayed-execution transaction, reject it.
• Verify signing requests out of band. If someone asks you to sign an "urgent migration" or "routine admin update," confirm through a second channel with a known contact. BlockSec notes that governance transitions create "a natural social engineering window."
• Revoke old approvals and authorities. Regularly review token approvals, delegate authorities and connected apps, and revoke anything you no longer use.
• Protect your seed phrase. Signature tricks are one threat; stolen seed phrases are another. Follow our guide on how to back up and recover your seed phrase safely, and our security advisory on safe Trust Wallet usage after an incident for wallet hygiene after a breach.

The Counterpoint: Removing Durable Nonces Is Not a Perfect Fix

It is tempting to read SIMD-0723 as "Solana patches the Drift hack." That framing overstates it, for several reasons:

• It is still a draft. As of November 9, 2026, SIMD-0723 has "Draft" status. According to CoinDesk's reporting as summarized by PrimeXBT, it still needs sign-off from at least one engineer at Anza and one at Firedancer before it can be merged. It could change, be delayed or be rejected.
• Legitimate users pay the migration cost. Custodians, exchanges and cold-storage operators that use durable nonces for good reasons must rebuild their signing workflows, retest them and rotate authorities to new program-controlled accounts. That is expensive and creates its own window for mistakes.
• The risk moves, it does not disappear. The proposal's own Security Considerations section says: "Risk moves to replacement programs, which must implement signature verification, replay protection, expiry, and revocation correctly." It also warns that "a failed execution can leave an authorization usable, so a failed submission is not a revocation." A buggy replacement program could recreate the same problem.
• The root cause was governance, not just the feature. A 2-of-5 multisig with zero timelock and phished signers would still be dangerous without durable nonces; the attacker would simply need to act faster. Better thresholds, timelocks and signer verification matter more than any single protocol change.
• Some balances may stay locked. The proposal accepts that funds in certain uninitialized nonce accounts without an available signer could stay locked permanently after activation.
• Market impact is limited and two-sided. FinScans describes the near-term price effect as "limited and two-sided": removing a known attack vector helps security, while migration risk falls on custodians.

The fair conclusion: SIMD-0723 removes one tool attackers used, and simplifies validator code that has caused real bugs. It does not make any protocol's treasury safe by itself.

How Kommunitas Approaches Project Security

At Kommunitas, we see token launches from both sides: founders applying to raise and investors deciding whether to participate. Incidents like Drift reinforce why we encourage investors to look past the pitch deck and ask about treasury controls, audits and admin powers. If you are researching upcoming token sales, you can browse projects on the Kommunitas launchpad and apply the checklist above before you commit. None of this is financial advice; always do your own research.

Frequently Asked Questions

What happened in the Drift hack?

On April 1, 2026, an attacker took administrative control of Drift, a Solana-based trading protocol, using durable nonce transactions that two of its five Security Council signers had been tricked into pre-signing. With admin powers, the attacker listed a fake collateral token, inflated its oracle price and withdrew at least $270 million in about 12 minutes.

What is a durable nonce on Solana?

A durable nonce is a value stored in an on-chain nonce account that replaces a transaction's recent blockhash. It lets a signed transaction stay valid until the nonce is advanced, instead of expiring after about 150 blocks. It was built in 2019 for offline and delayed signing.

What is SIMD-0723?

SIMD-0723, "Remove Durable Nonces," is a draft Solana improvement proposal filed on November 5, 2026 by Gabe Rodriguez of Anza. It would require every transaction to use a recent blockhash and disable the System Program instructions that initialize, advance and upgrade nonce accounts.

When will durable nonces be removed?

Not before May 5, 2027 on Solana mainnet-beta, according to the proposal text. The date could be later, because the proposal is still a draft and the Solana Foundation's deprecation process depends on replacements being ready.

Do I need to do anything as a regular Solana user?

Most likely not. Normal wallet transactions already use a recent blockhash. The change mainly affects custodians, exchanges, developers and treasuries that sign offline or with delays. Keep your wallet updated and avoid signing transactions you cannot read.

How can investors check if a project's treasury is safe?

Ask who holds the treasury and admin keys, how many multisig signers there are and what the threshold is, whether admin actions have a timelock, when the last audit was done and whether it covered governance, and whether the project relies on delayed or offline signing.

Last updated: November 9, 2026. Figures and proposal status are as of this date and may change.