Drift's $285M hack: phished signatures banked on Solana's durable nonces

What happened

On 1 April 2026, Drift, a perpetuals trading protocol built on Solana, lost roughly $285 million. According to a technical write-up published on dev.to (originally on xroot.dev), the attacker compromised neither a smart contract nor a key server. Instead, over several weeks they tricked two of the five members of Drift's security council into signing transactions, then waited. When they chose, they broadcast both pre-signed transactions, four slots apart.

The write-up says the published post-mortem reduces its finding to a single sentence: the point of no return came when the signatures were given, not when the transactions ran. The enabling mechanism was a Solana feature most users have never heard of — the durable nonce.

The safety net durable nonces remove

Every ordinary Solana transaction carries a recent blockhash and is accepted for only about 150 slots, roughly a minute at current slot times, the write-up explains. That short window is an implicit guarantee: a signature you handed over last week cannot be turned into an action this week, because the transaction wrapped around it has already gone stale.

A durable nonce swaps the blockhash for a value stored in an 80-byte on-chain account owned by the system program. That value remains valid until explicitly advanced, so a transaction referencing it stays valid indefinitely. Whoever holds the signed bytes can run it tomorrow or in six months.

The mechanics, per the write-up

Several rules govern these transactions. The first instruction must be AdvanceNonceAccount, signed by the nonce account's authority; executing it rotates the value so the same signed bytes can never run twice. The account also records the fee rate from its last advance, and the runtime charges that rate at execution — a nonce locks in the per-signature fee along with validity. A nonce can advance at most once per slot, so parallel pre-signed transactions each need their own nonce account.

Since 12 August 2026, the write-up adds, the runtime has stopped tracking nonce transactions in the status cache that normally blocks double execution, because rotating the nonce is itself the replay protection. RPC nodes keep retrying a nonce transaction until the nonce moves; to prevent malicious senders from filling retry queues with undying transactions, nodes impose an artificial cutoff — the current block height plus 150 — after which they stop retrying, though the transaction itself remains valid.

A legitimate feature, weaponized

Nothing here is a vulnerability. The write-up lists the intended uses: hardware and offline signing, multisigs whose members sign across time zones over days, scheduled treasury payouts, and cold-key custody where a batch is signed offline and released gradually. Each is also, viewed from the attacker's side, a description of the Drift operation.

The danger is not the nonce account itself but the signed transaction sitting somewhere its signer cannot see. A leaked blockhash-based transaction goes stale within a minute; a leaked nonce-based one is an open-ended grant that persists through credential rotations and hardware replacement. Wallet previews only evaluate transactions at signing time — they cannot surface a weeks-old signed-but-unsent transaction, and nothing about it exists on-chain until it executes.

The off switch, and an audit routine

Because a pre-signed transaction is bound to a specific nonce value, a single AdvanceNonceAccount instruction from the nonce authority invalidates every unsent transaction against that nonce. Closing the account works too and refunds its rent, which the write-up puts at about 0.00106 SOL at a rate of 5,080 lamports per byte.

That yields a concrete checklist for treasuries: enumerate every 80-byte system-owned nonce account whose authority belongs to your keys, establish who signed against each and whether every signed transaction has run, and rotate any nonce you cannot fully account for.

Two edge cases from the write-up stand out. UpgradeNonceAccount, which migrates legacy nonces to the current format, requires no signature at all — anyone can send it against any account, though it does not advance the value. And a nonce transaction whose account is not exactly 80 bytes is dropped by the block producer before execution, without any error, charge or log entry — the first thing to check when one disappears.

Why it matters

Drift's council did not lose private keys; they lost control of signatures they had already given, attached to transactions that never went stale. Any organization using multisig governance — especially where offline signing or durable nonces are involved — should treat every nonce account its signers touch as a live, undated authorization waiting to fire. Counting those accounts, and rotating nonces once an operation completes, turns an invisible standing risk into a manageable one. The broader lesson travels beyond Solana: in signature-based authorization, the moment of consent and the moment of effect can be separated by design, and security processes have to assume they will be.