Durable nonces are being deprecated: an authority checklist for the migration

Durable nonces will be removed from Solana, and their replacement moves your mint, stake and token authorities from a key to a program-owned address [1]. That makes the migration an authority change, so treat it like one: list every authority first, move them deliberately, and check the result on chain.

What is changing

The Solana Foundation's deprecation page went live in October; the 16 October changelog announced it [1][2]. The page says "Durable nonces will be removed", and that there is "no final decision yet on what replaces them", but "the shape is settled: an onchain program that verifies an offline signature" [1].

The page gives four reasons: nonce special cases have caused replay bugs and outages, nonce transactions can land more than once and block asynchronous execution, they are cheap to spam, and they are expensive for validators to filter. In one June 2026 epoch they were 3.1% of transactions but 30% of priority fees [1]. SIMD-0571 proposes an interim step: treat a nonce transaction's priority fee as zero, so it stays valid but cannot pay to be prioritised [5].

Timing. There is no date. Removal is expected "roughly six months after the replacement program is ready", and "durable nonces keep working until a replacement is audited and live on mainnet" [1]. The upgrades page lists it as unscheduled and in development [3]. Removal will need a feature gate; the replacements need none [1].

What replaces them

The chosen design, out of seven considered in SIMD discussion #456 [4], is an offline signer program:

1. A program-owned address (a PDA) becomes the authority over your mint, stake account, token account or wallet.
2. Your cold key signs a message listing instructions. It has no blockhash, so it does not expire.
3. A hot fee payer submits it in an ordinary transaction.
4. The program checks the signature and advances its own nonce, so the message runs only once.
5. The program runs each instruction by cross-program invocation (CPI), signing as the PDA [1].

Two candidates are named, and neither is chosen:

The new authorities this creates

Today the authority over a nonce-signed action is a key. After migration, there are several things to inventory, not one:

• The signer PDA. It now holds your funds and acts as your mint, freeze, stake or token-owner authority [1][6].
• The cold key behind it. It still controls everything, but it no longer appears as a transaction signer. The page says indexers must attribute the action to the signer PDA in inner instructions [1]. Any alert you key on "this address signed" will go quiet.
• The signer program itself. Your authority is now only as safe as that program. Once one is deployed on mainnet, check who can upgrade it: solana program show on its program ID.
• The program's nonce. It is the replay guard. Vector notes that signatures from failed transactions can remain valid until the nonce moves [7].
• The fee payer and relayer. They submit, so they decide when your signed message lands.

One property does not change: the signed message does not expire. Vector "deliberately remains unopinionated about expiration" and suggests putting a timeout instruction inside the signed message [7]. A message signed today can still run next month, just as a nonce transaction can.

That is the property at the centre of the Drift incident. BlockSec reports that two Security Council signers were induced to pre-sign malicious transactions, that durable nonces kept those approvals valid for about a week and a half, and that the council ran a 2-of-5 threshold with zero timelock [11]. Chainalysis wrote that zero timelock removed "the delay window that could have allowed detection and intervention" [12]. Moving to a signer program does not remove that risk; a time lock on the multisig that holds your privileged authorities still matters.

The checklist

Before you move anything

1. List your nonce accounts and their authorities. A nonce account's authority can advance it, withdraw from it and hand it to a new authority, who "inherits full control" [8]. solana nonce-account "$NONCE_ACCOUNT" shows one.
2. Find nonce accounts you did not create. Anyone can create a nonce account and name your key as its authority. Search the System Program's 80-byte accounts with your key at byte offset 8 (a getProgramAccounts filter). Our scanner does this for a program's single-key upgrade authority, or for the members of the Squads v4 multisig that holds it, when the RPC provider allows the search, and reports the count as information only [13].
3. Void pre-signed transactions you no longer want. A transaction signed against a nonce can be submitted until that nonce is advanced; afterwards it cannot [9]. solana new-nonce "$NONCE_ACCOUNT" advances it.
4. List every authority each cold key holds. Upgrade authorities, multisig memberships, mint and freeze authorities, Token-2022 extension authorities, stake and vote authorities, token account owners. This is the list that will move.

When a replacement is live on mainnet

5. Test on devnet first, as the page advises [1].
6. Derive the signer PDA for each cold key and record it next to the key it stands for [1].
7. Move authorities one at a time, and check each on chain after the move. Move funds too [1].
8. Do not withdraw a nonce account to itself. A full self-withdrawal leaves a funded, uninitialised account that another party can initialise with themselves as authority. SIMD-0610 would reject it [10]. Withdraw to a different address.
9. Check your own programs accept CPI. The page warns about stack-height checks, top-level-only instruction checks and Token-2022's CPI Guard [1].

After the move

10. Re-point monitoring from signer keys to signer PDAs and inner instructions [1].
11. Record the signer program's upgrade authority in your inventory, and re-check it on a schedule.
12. Ask how a compromised cold key is replaced. Anza's PDA is derived from the authority's key [1]; Vector's README documents rotation for its Winternitz and XMSS variants [7]. Know the answer before you need it.
13. Keep a time lock on whatever multisig holds your privileged authorities.

What we are not saying

We are not recommending either replacement. Both are pre-audit or of unstated audit status at the time of writing [6][7]. Wait for audits and mainnet deployment, and follow the deprecation page, which "will be updated when a date is set" [1].

What we do: our admin-plane Snapshot inventories who controls your programs, tokens and funds, and how fast they can act. It is not an audit. See https://centrob.co/#solana.