Originally published on xroot.dev.
On 1 April 2026, the perpetuals protocol Drift lost about $285 million. The attacker did not break a contract or steal a key from a server. Over several weeks they phished two of the five signatures on the protocol's security council, and then, at a time of their choosing, submitted two transactions that had been signed long before, four slots apart. The published post-mortem's finding is one sentence: the decisive authorization happened at the moment of signing, not the moment of execution.
The mechanism that made "sign now, execute whenever" possible is a Solana feature most users have never heard of and most wallets never mention: the durable nonce. It is a legitimate tool with real uses, and it removes the one safety property every Solana user relies on without knowing it. This post is how it works, where the hazards are in the code, and the single instruction that defuses one.
The Safety Property You Did Not Know You Had
Every ordinary Solana transaction carries a recent blockhash, and the network only accepts it for 150 slots after that blockhash — about a minute today, thirty seconds once slots reach 200 ms. Sign a transaction and do nothing, and in a minute it is worthless. That expiry is not a nuisance; it is the reason a signature you gave last week cannot be used against you today.
A durable nonce replaces the blockhash with a value stored in a small on-chain account — 80 bytes, owned by the system program — that stays valid until someone advances it. A transaction built on it is valid for as long as the nonce sits still. Days. Months. It has no expiry at all.
How a Nonce Transaction Is Built, and the Fee It Locks
The rules, from the system program and the runtime:
- The first instruction in the transaction must be
AdvanceNonceAccount, signed by the nonce's authority. Executing the transaction advances the nonce, so the same signed bytes can never run twice. - The nonce account stores the fee rate at the moment it was last advanced, and the runtime charges that rate when the transaction executes — a nonce is a lock on the per-signature fee as well as on validity.
- A nonce can be advanced at most once per slot. Two transactions on the same nonce in the same slot: the second fails with "nonce blockhash not expired". Running many pre-signed transactions in parallel needs one nonce account per lane.
- Since 12 August 2026 the runtime no longer tracks nonce transactions in its status cache — the cache that prevents an ordinary transaction from executing twice. It does not need to: advancing the nonce is the replay protection. But it means the usual "already processed" signal does not exist for them.
Worth knowing: an RPC node retries a nonce transaction until the nonce advances, not until a blockhash expires. To stop a malicious sender packing the retry queue with immortal transactions, the node gives each one an artificial deadline of the current block height plus 150 and drops it from the retry pool after that. The transaction remains valid; only the node's retrying stops.
What It Is For
None of this is a bug. Durable nonces exist for exactly the cases where the one-minute expiry is the problem:
- Hardware and offline signing, where the machine that signs never sees the network and the machine that broadcasts never sees the key.
- Multisig, where five people in five time zones sign over a week.
- Scheduled payments, where a treasury approves today and the transaction lands on the first of the month.
- Custody flows where a cold key signs a batch and a warm system releases it piece by piece.
Every one of those is a legitimate reason to hold a signed transaction that does not expire. Every one of them is also a description of the Drift attack from the inside.
The Hazard, Precisely
The hazard is not the nonce account. It is the signed transaction that exists somewhere you cannot see.
A blockhash-based transaction that leaks is a one-minute problem. A nonce-based transaction that leaks is a standing capability: whoever holds the bytes can execute them at any moment until the nonce moves. It survives a password change, a device wipe, a new laptop. It survives everything except the nonce advancing.
Wallet simulators show you what a transaction does at signing time. They cannot show you a transaction you signed six weeks ago that has not been sent yet. There is no on-chain record of it, because it has not happened. The only on-chain trace is the nonce account itself, sitting at the same value it held when you signed.
The Kill Switch
Because a pre-signed transaction is bound to a specific nonce value, advancing the nonce invalidates every transaction signed against it. The nonce authority — the key that created the account, or whoever it delegated to — can send a single AdvanceNonceAccount instruction at any time. Every unsent transaction on that nonce is dead the moment it lands.
That gives a treasury or an individual a concrete audit:
- List every nonce account whose authority is one of your keys. They are system-owned accounts of exactly 80 bytes; the authority is in the data.
- For each one, ask who signed against it and whether every signed transaction has been executed. If you cannot answer, advance it.
- If the account is no longer needed, withdraw and close it. It holds rent — about 0.00106 SOL at the 5,080 lamports-per-byte rate live at the time of writing — that returns to you, the same way an empty token account returns its deposit.
The reverse hazard exists as well. UpgradeNonceAccount, which migrates a legacy nonce to the current format, requires no signature at all; anyone can send it against anyone's nonce. It does not advance the value, so it does not invalidate anything, but it is the reason your nonce account may show a transaction you did not send.
What a Leader Does With a Bad Nonce
One rule lives only on the leader side. A transaction that claims to use a durable nonce, but whose nonce account is not exactly 80 bytes, is dropped by the block producer before execution and never reaches replay. It is a silent drop of the kind covered in the post on transactions that vanish: no error, no fee, no log. If a nonce transaction disappears, the account's size is the first thing to check.
Durable Nonces: Questions People Actually Ask
What is a durable nonce on Solana?
An 80-byte on-chain account whose stored value replaces the recent blockhash in a transaction, so the transaction stays valid until the nonce is advanced instead of expiring after 150 slots.
How did the April 2026 Drift exploit use durable nonces?
According to the published post-mortem, two of five security-council signatures were obtained over weeks on transactions built against durable nonces. Because those transactions never expired, the attacker executed them later, four slots apart, on 1 April 2026.
How do I cancel a pre-signed durable nonce transaction?
Advance the nonce. One AdvanceNonceAccount instruction from the nonce authority invalidates every transaction signed against the old value. Closing the account also works and returns its rent.
Can I run several durable nonce transactions at once?
Only with several nonce accounts. A single nonce can advance at most once per slot, so parallel pre-signed transactions need one nonce account each.
Two Rules to Keep
If you ever sign a transaction that uses a durable nonce — a hardware wallet flow, a multisig, an offline approval — you now hold a capability that does not expire. Know where the bytes are. When the operation is done, advance the nonce, so the capability dies.
And if you administer a treasury with council signatures, count the nonce accounts your signers can be asked to sign against, and treat every one as a standing withdrawal that has not happened yet. Drift's council did not lose keys. They signed.
Mechanism read from the Agave validator source at commit beee69b958: the solana-nonce crate, programs/system/src/system_instruction.rs, runtime/src/bank.rs and rpc/src/rpc.rs. The April 2026 incident figures are as reported in the published post-mortem, not independently reproduced here.
