Solana nonce draft separates expired approvals from locked balances

Solana’s November 5 draft to remove durable nonces would make every transaction use a recent blockhash. The draft, revised November 6, sets May 5, 2027 as the earliest possible mainnet activation. It also leaves existing nonce accounts in place, with different withdrawal rules depending on their state.

For a custody desk, that creates two separate inventories to reconcile. One contains signed transactions waiting to go out. The other contains nonce accounts that may hold SOL. An expired transaction can be rebuilt if the signers are available. A funded account that requires a signature the operator can no longer produce presents a different recovery problem.

Three checks for the cutover

CoinAbout compared the November 6 text of SIMD-0723 with the separate draft for nonce-account withdrawals. Three cases explain why a single test for whether a transaction failed would leave gaps.

A queued signature uses an old durable nonce. Once the proposed change is active, the runtime would reject that transaction at its lifetime check with BlockhashNotFound, without charging a fee. The account’s stored nonce no longer keeps the message valid. A newly built transaction with a recent blockhash has a different signed message and requires fresh authorization through the applicable workflow.

A fresh transaction still contains a retired nonce instruction. A recent blockhash can get the transaction past the lifetime check. The System Program would still return InvalidInstructionData when the transaction tries to initialize, advance, or upgrade a nonce account. The same instruction rule applies when another program calls the System Program. The draft distinguishes that execution path from a lifetime rejection, so a desk should keep the fee and instruction outcome separate in its records.

An account still holds SOL after activation. The proposed activation leaves the account untouched. For an initialized nonce account, withdrawal and authority changes retain their existing rules, subject to the separate self-withdrawal restriction. For a funded uninitialized account, withdrawal would require the account address itself to sign, either through the corresponding keypair or through the program that can sign for a program-derived address. Without that signing path, the draft says the balance stays locked.

The first two checks concern what a particular transaction can do. The third concerns who can authorize a different transaction in the future. An operations team could clear every expired item from its signing queue and still have a balance that needs its own reconciliation.

Why the withdrawal rule has to go first

SIMD-0610 describes an unusual state transition. Under the behavior documented there, a full withdrawal from an initialized nonce account back to its own address can remove the initialized state while putting the same lamports back in the same account. The balance survives, but the account state and the relevant authority change.

The separate proposal would make a withdrawal to the same address fail with InvalidArgument once the instruction reaches the new address check. Other withdrawal destinations would continue through the usual checks. The restriction applies even to a partial or zero self-withdrawal. The dangerous state change documented in the draft concerns a full-balance withdrawal from an initialized account.

That explains the order specified by SIMD-0723. The withdrawal restriction must be active on a cluster before that cluster switches off nonce initialization. Blocking a route into the uninitialized state does nothing to change an account already in that state. The later proposal specifies no automatic sweep or closure, and the earlier rule supplies no replacement signer.

Consider two hypothetical accounts with the same SOL balance. The first is initialized and the desk still has access to its nonce authority. Its withdrawal path remains available under the draft’s existing authorization and balance checks, with a destination distinct from the source. The second is uninitialized and the desk can reach only its former nonce authority. After activation, that former authority alone would be insufficient. A balance report that grouped both accounts together would show the same total while concealing the difference in recoverability.

What an offline approval would become

Today a durable nonce lets a desk prepare a transaction, collect signatures offline, and submit it later while the nonce still matches. The proposal would instead require the blockhash to meet the normal processing-age limit, currently 150 in the draft’s terminology. That limit describes the blockhash queue. It should not be converted into a fixed number of minutes for an approval deadline.

The proposal’s replacement section describes a different sequence. An owner grants authority to a program-derived address. The owner signs an authorization offline, and a relayer later includes it in a newly assembled transaction with a recent blockhash. The program verifies the offline authorization and executes the permitted action. The fresh transaction and the offline authorization now have separate lifetimes.

That difference matters when a submission fails. The network can reject the outer transaction while the authorization remains usable under the replacement program’s rules. A team migrating an approval workflow would therefore have to account for expiry, revocation and replay protection in addition to ordinary transaction status. The draft names possible replacement programs. Its reference to them establishes neither a deployment date nor whether their controls fit any particular desk’s signing policy.

There is a case for keeping some of the old machinery. A transaction envelope that preserved presigned messages could spare operators from replacing existing approvals or moving authorities before the change. The authors considered that option and rejected it because it would preserve the special handling they are trying to remove. For an operator, an accepted design that made old signatures usable would change the queue assessment materially. The current draft provides no such transition.

A fee reconciliation would also change. Under the draft’s description of the existing path, a durable-nonce transaction that reaches execution and fails can still consume the nonce and pay a fee. Under the proposed path, a message rejected for its lifetime never reaches that step. A new transaction that gets as far as a disabled instruction is a different case. For a hypothetical batch, the useful records are the submitted message, the stage at which it failed and any fee actually debited. Counting failures alone would hide whether a message needs a fresh signature, whether a builder still emits a retired instruction, and whether any fee should appear in the ledger.

What to watch before treating the date as operational

The open pull request lists review requirements from Anza and Firedancer. Its November 6 revision adds the timeline language. May 5 is a lower bound in the draft. An approved specification, a public activation plan for the relevant cluster, and evidence that the withdrawal prerequisite is active would establish different milestones. A code review or a calendar date alone cannot establish all three.

The draft makes clear which records would matter in a migration. A signing queue can identify messages that rely on durable nonces and when they would need to be signed again. An instruction inventory can identify direct calls and program calls to the three instructions proposed for retirement. An account inventory can separate initialized balances from uninitialized ones and record which signing path is available for each. Those are three different checks even when the same application owns all three records.

These examples describe the behavior proposed in the two specifications. They do not establish that any existing account is stranded, that a particular signing product is ready, or that mainnet rules have changed. For now, the practical distinction is between an approval that can be replaced, an instruction that needs to be removed, and a balance whose withdrawal depends on a particular signer.