Durable Nonces

Priority Fee Discovery, Limited Execution Windows, and One-of-Many Transactions

On Solana, durable nonces can be used in lieu of a recent blockhash to sign a transaction. They have two great properties that make them quite distinct from recent blockhashes:

1) They don't expire until you say they do

2) They can only be used once

We will exploit these properties to show how we can come up with a better priority fee discovery mechanism, how to limit the execution window for transactions, and how to avoid tipping multiple transaction landing services (or, how to use more of them without paying them all).

1. Better Priority Fee Discovery

Consider the case of a low to medium priority user transaction where a user would happily wait an extra slot to pay a smaller fee. In this case, a series of transactions of increasingly higher fee can be generated and sent with a short delay between them. This would look something like:

Step 1) Send tx with 1/10th of recent median fee. Wait 40 ms

Step 2) Send tx with 1/4th of recent median fee. Wait 40 ms

Step 3) Send tx with 1/2 of recent median fee. Wait 40 ms.

Step 4) ...

When this transaction set shares a durable nonce, at most one of these transactions will be included and executed — and the fee will be collected only once. Every other transaction will fail to be included due to an invalid nonce. This incremental bidding allows for better price discovery for block space over the status quo of a single bid.

2. Landing one-of-many transactions

There are many creative ways to use the property that a durable nonce can only be used exactly once. In 1) we saw how to submit multiple bids for block space. Another possibility is tipping different transaction lander services. One could construct a transaction that tips Nozomi (Temporal's transaction landing service), for example, and a second transaction that uses the same nonce to tip some other service. This allows the user to use (and trace!) multiple transaction landing services without paying for all of them.

Another one-of-many use case is to send a blitz of swap orders through different venues. The first to be included will be the only one executed, enabling urgent portfolio rebalancing.

3. Limiting Transaction Execution Window

Suppose a user sends a transaction with a durable nonce and it fails to be included. Suppose a slot (or several) later, the user realizes they no longer want to execute this transaction. With a recent blockhash, this transaction is valid for 150 blocks (over 1 minute); it could be sitting in a mempool to be executed later! Although a user could stop the transaction from executing by transferring their SOL elsewhere, a simpler solution would be to advance and expire the durable nonce used in the previous transaction. This allows the user to arbitrarily shorten the execution window for a transaction for maximum flexibility.

Summary

Durable nonces on Solana offer unique capabilities that extend beyond their initial use case. They enable better priority fee discovery by allowing incremental bidding, ensuring only one transaction is executed and charged. Durable nonces also give users precise control over transaction execution windows by enabling nonce expiration, mitigating risks of delayed execution. Furthermore, they facilitate one-of-many strategies, such as using multiple transaction landing services or prioritizing urgent orders, without incurring redundant fees or unintended executions.