Solana Proposal Would Retire Durable Nonces by May 2027

Solana community members have proposed retiring durable nonces and requiring every transaction to carry a recent block hash, a change that would force offline-signing and custody providers to rebuild their transaction handling. The proposal, published as a mainnet change, names May 5, 2027 as the earliest activation date — a migration deadline, not a confirmed switch-over.

The two halves of the proposal work together. Transactions would rely on a recent block hash for replay protection, replacing the durable-nonce mechanism that currently lets a signed transaction stay valid indefinitely. At the same time, the plan would disable the system-program instructions that initialize, advance and upgrade nonce accounts — the full lifecycle of the feature.

What are durable nonces and why do they exist?

Durable nonces were designed to solve a specific problem: Solana transactions normally expire quickly because they must reference a recent block hash. That's fine for online users, but it breaks offline signing. A transaction signed on an air-gapped device, or held by a custodian for later submission, can go stale before anyone broadcasts it. Nonce accounts decouple the transaction from the clock by substituting a stored nonce value for the block hash.

Custody providers, hardware-wallet workflows and delayed-execution services all lean on this. If the proposal ships as written, those systems need a new approach to signing, maintaining and submitting transactions — the three stages the proposal explicitly touches.

What would change for builders?

The direct technical consequences are narrow but sharp:

• Every transaction would need a recent block hash for replay protection.
• The InitializeNonceAccount-family system-program instructions — initialize, advance, upgrade — would be disabled.
• Applications relying on nonce accounts would need to rewrite transaction handling before activation.
• Existing nonce accounts would lose their purpose, since nothing could advance or upgrade them.

The proposal, per its own text, "focuses on how transactions are signed, maintained and submitted across Solana's network." That's plumbing most users never see, but it's the layer custody desks and institutional integrations sit on.

Why the 2027 date?

The proposal sets mainnet activation "for after May 5, 2027," which the document itself flags as the earliest possible timing rather than a committed date. That gives the ecosystem roughly a two-year migration runway — longer than most protocol deprecations, a signal that maintainers expect the change to touch a meaningful number of production systems.

Migration won't be a one-line patch. Offline-signing flows have no drop-in replacement under the new rules: if a transaction must reference a fresh block hash, the signing moment and the submission moment get coupled again. Custodians that sign now and submit later will need either a re-signing step or a different deferred-execution design. The proposal doesn't prescribe a replacement; it retires the old one and leaves the engineering to integrators.

What happens next?

Nothing is live yet. This is a community proposal, not an accepted upgrade, and Solana's feature-activation process requires validator coordination before any mainnet change takes effect. Teams running custody, multisig or cold-storage infrastructure on Solana now have a dated reference point: audit nonce-account dependencies before May 2027, or plan around whatever replay-protection pattern the ecosystem settles on in the interim.