Durable Nonce Fan-out for SWQoS
Background and usage scenario
In Solana transaction sending, slot progression, leader placement, and network-path congestion constantly change which route reaches the leader fastest. This is not specific to any RPC provider or sending service; it is a structural characteristic of Solana's execution model.
ERPC's SWQoS endpoint provides a sending path that injects transactions into the priority lane allocated by leaders based on Stake-weighted Quality of Service (SWQoS). This priority bandwidth is about 5× that of the non-priority lane and is applied before priority fee evaluation.
For that reason, the SWQoS endpoint is an important option for transaction sending, but in production a single endpoint is not always the fastest. Even within the same slot, transient path differences or load skew can allow another fast endpoint to lead.
Given these characteristics, an operational pattern of sending the same transaction to multiple fast paths in parallel and accepting the first one processed can be effective, rather than relying on a single route.
However, when the same transaction is sent to multiple endpoints, you cannot guarantee that it will execute only once without additional control. Fan-out without this control can lead to unintended double execution or broken retry control.
Solana provides Durable Nonce as the mechanism for this. Using Durable Nonce lets you send the same signed transaction across multiple routes while limiting on-chain execution to a single time.
This page explains how to implement fan-out operations that combine ERPC's SWQoS endpoint with other fast RPC endpoints, assuming transaction sending with Durable Nonce.
Scope and prerequisites
This guide covers creating a Durable Nonce account with web3.js and using it for transaction sending and fan-out operations.
Prerequisites to understand:
- For Durable Nonce transactions, use the nonce value as
recentBlockhashand placenonceAdvanceas the first instruction - Once
nonceAdvanceexecutes, the nonce can be consumed even if later instructions fail. You cannot resend the same rawTx as-is. - Nonce account creation is a one-time setup and is typically reused
Step 1: Prepare the nonce authority and connection
The nonce authority is a Keypair that can advance the nonce.
- The nonce authority can execute
nonceAdvance - It can be the fee payer, or a separate keypair
Step 2: Generate a nonce account Keypair
A nonce account is a System Account.
This Keypair is used for:
- Holding the nonce value (replacement for
recentBlockhash) - Signing only at creation time
- Safe storage afterward; it is not needed for daily sends
Step 3: Calculate the rent-exempt minimum
Nonce accounts must be rent-exempt. Do not hardcode values; fetch them from the RPC.
Step 4: Create and initialize the nonce account
Create the nonce account with createAccount + nonceInitialize in a single transaction.
Use this
nonceAccount.publicKey for subsequent sends.Step 5: Fetch the nonce before each send
For every transaction, fetch the current nonce value.
- Use
nonceasrecentBlockhash context.slotis used in confirmation
Step 6: Build the Durable Nonce transaction
Durable Nonce transactions must satisfy the following conditions:
recentBlockhash = nonce- The first instruction is
nonceAdvance
Notes:
- If you use ComputeBudget instructions, they must come after
nonceAdvance - If
nonceAdvanceis not first, the transaction will be rejected
Step 7: Fan out to multiple RPCs
Send the same rawTx concurrently.
- The signature is identical across endpoints
- A successful send is not a confirmation
Step 8: Confirm with Durable Nonce
With Durable Nonce, include the nonce info in confirmation.
If confirmation succeeds:
- The nonce advances
- Copies sent to other RPCs return
InvalidNonce
Next sends
- After confirmation, fetch a fresh nonce
- Do not reuse the same rawTx or nonce value
- For parallel workflows, use separate nonce accounts
For the next transaction, fetch the updated nonce and build the transaction using the same steps.