Solana Durable Nonces Support

DFNS now supports Solana durable nonces on Solana.

Steffel Fenix
Steffel Fenix
| 5 min read

DFNS now supports durable nonces on Solana. This removes the single biggest obstacle to operating Solana the way institutions operate every other chain: the inability to sign a transaction now and broadcast it later. With durable nonces, a Solana transaction built through DFNS no longer expires after roughly 90 seconds. That unlocks offline and airgapped signing, multi-party approval flows that take minutes or hours, and resilient retries, all through the same DFNS control plane that already powers onchain operations across 60+ networks.

The problem: Solana transactions expire in about 90 seconds

Every standard Solana transaction is bound to a recent blockhash, the mechanism Solana uses to prevent double-spending. A blockhash contains a 32-byte SHA-256 hash used to indicate when a client last observed the ledger. Transactions are checked within the last 150 blocks and rejected if they are found, and also rejected if they get older than 150 blocks, which is roughly 80 to 90 seconds.

For an online, automated signing path where construction and broadcast complete in seconds, this is fine. But the forced mortality of the transaction makes three things that regulated institutions depend on effectively impossible:

  • Offline and airgapped signing. Moving a constructed transaction into an air-gapped environment, signing it there, and bringing the signature back takes far longer than 90 seconds. The blockhash expires before the transaction can be broadcast.
  • Multi-party approval flows. When several approvers must review and sign a transaction, often across time zones and review queues, the process routinely exceeds the window. This is exactly the case of a multi-sig operated by a DAO where co-signing takes more than 90 seconds.
  • Resilient automated signing. Even on online paths, intermittent signing retries can push past the window, so the constructed transaction expires before it lands and has to be rebuilt.

The solution: durable nonces

A durable nonce replaces the recent blockhash with a value that does not age out. Durable transaction nonces, 32 bytes in length, are used in place of recent blockhashes to make every transaction unique while removing the mortality on the unexecuted transaction. The first instruction of the transaction advances the nonce, which ensures every transaction signed against it is unique, irrespective of being successfully submitted or not.

Two on-chain concepts make this work:

  • Nonce account. The account that stores the value of the nonce. It is owned by the System Program and is rent-exempt, requiring a minimum balance of around 0.0015 SOL.
  • Nonce authority. The account that controls the nonce account, with the authority to advance the nonce, or withdraw from and close it.

The result: a transaction signed against a durable nonce stays valid indefinitely, until the nonce account is advanced by some other transaction, which is typically the broadcast of that very transaction. There is no time-based expiry.

How DFNS supports durable nonces

DFNS makes durable nonces a first-class, hands-off capability rather than something you assemble manually. The decision is made per request at construct time. There is no wallet-level mode, and the same wallet can mix immediate and durable-nonce transactions freely.

For most cases, one flag is enough. To send a durable-nonce transfer, pass useDurableNonce: true and DFNS reserves a free nonce account from the wallet’s pool automatically:

POST /wallets/{walletId}/transfers
{
  "kind": "Native",
  "to": "DMrSBHfk1iw9PbWdYtYp8M6LpiHd47B87cNPf5pzNYFX",
  "amount": "1000000",
  "useDurableNonce": true
}

Behind that simplicity, DFNS handles the two parts institutions care about most.

A clean bootstrap and authority model. A nonce account is created by one wallet but controlled by another. A bootstrapper wallet, typically a hot DFNS wallet, signs the creation transaction and pays the rent. The target wallet is set as the on-chain authority and is the only key that can ever use the account from that point on. For airgapped setups, this matters: the offline wallet is set as the authority without ever signing anything at bootstrap time, and the bootstrapper retains zero residual control once the account is created. An online wallet can therefore safely provision a pool of nonce accounts on behalf of a cold wallet that cannot sign within the blockhash window.

Safe concurrency under slow signing. Each nonce account can back only one in-flight transaction at a time. DFNS treats nonce accounts as a reservable resource: an account is locked at construct time and released only when the transaction confirms or is aborted. While a transaction sits unsigned in an approval queue or an air-gapped device, its reservation stays active and the on-chain nonce stays unchanged, so no concurrent flow can race against it and consume the same nonce. To run several offline transfers in parallel from one wallet, you simply maintain a small pool of nonce accounts.

DFNS does not turn nonce accounts into wallet entities. Setup is a one-time step on your side: creating a nonce account costs a small amount of SOL and requires your keys, so it runs as a transaction you broadcast. From then on, DFNS treats them as infrastructure: pooled, reserved, and advanced automatically.

What this unlocks

  • Offline signing and storage for Solana. Durable nonces are what make Solana compatible with air-gapped, HSM-grade signing through DFNS Offline Signer. A transaction can be constructed online, carried to a cold environment, signed, and broadcast hours later, with no expiry.
  • Long-running approval and governance flows. Transactions can move through multi-party review, policy approval, and quorum collection without racing a 90-second clock. The Policy Engine and approval workflows apply exactly as they do on other chains.
  • Resilient automated signing. Durable-nonce transactions survive intermittent signing retries, so high-value flows do not fail and rebuild because a blockhash aged out mid-process.
  • Pre-signed and scheduled transactions. A transaction can be signed once and submitted at the right moment, supporting planned transfers and triggered execution.

Full support on DFNS

Durable nonce support is available now on Solana and Solana Devnet, integrated into the existing transaction and transfer endpoints:

  • Auto-managed nonce pools: pass useDurableNonce: true and DFNS reserves, locks, and advances accounts for you
  • Explicit control when you want it: pin a specific nonce account per transfer
  • Self and cross-wallet bootstrap: provision nonce accounts for a wallet itself, or for a separate offline wallet that cannot sign in the blockhash window
  • Native and token transfers: supported across Native SOL, SPL, and SPL 2022 transfers
  • The same signing models: works across MPC, HSM, and Offline Signer, with no single point of failure

All operations are secured by DFNS’ zero trust architecture, with SOC 2 Type II, ISO 27001, ISO 27017, and ISO 27018 certifications. DFNS operates strictly as a technology provider. Custody remains under the client’s own regulatory perimeter and licensing framework.

Get started

Contact us