Transaction sending advice

Recommendations to optimize transaction delivery through our Cascade network.

Sending transactions effectively on Solana requires a client-side strategy that accounts for network congestion and leader schedules. Following these best practices will significantly increase your transaction inclusion rate and create a better experience for your users.

TL;DR: Quick Summary

• Handle retries in your own code. Do not rely on the RPC node to retry for you.

• When sending, set maxRetries: 0.

• If you need simulations, do it separately via simulateTransaction() before sending.

• When sending, set skipPreflight: true.

• Use a recent blockhash from a finalized or confirmed commitment level. Never use processed for blockhashes.

• Set a tight Compute Unit (CU) budget and a competitive priority fee.

---

1. Handle Retries in Your Client

Previously, RPC nodes would queue and retry transactions on behalf of the user. During periods of high traffic, this system creates backpressure, saturating the queues and causing widespread transaction failures.

The modern best practice is to manage the retry logic entirely within your own application. This gives you full control over the user experience and leads to more predictable transaction delivery.

• Your Action: Build your own asynchronous retry logic (e.g., re-fetching a recent blockhash and re-signing every few seconds).

• RPC Parameter: Always include maxRetries: 0 in your sendTransaction options. This tells our RPC node not to use its legacy retry queue.

---

2. Simulate First, Then Send

Our Cascade delivery network has more pathways available for transactions that do not require a pre-flight simulation. For the fastest and most reliable delivery, you should separate simulation from execution.

• Your Action: If you need to verify a transaction's outcome, call the simulateTransaction() method first.

• RPC Parameter: When you are ready to send the transaction for real, use sendTransaction() with the skipPreflight: true option.

---

3. Set Precise Compute Budgets & Priority Fees

A well-defined compute budget and priority fee are critical for getting your transaction included in a block.

• Compute Budget: The default CU budget is often too high for simple transactions. Setting an accurate, tight budget helps validators fit your transaction into blocks more efficiently. For example, a simple SOL transfer uses only ~500 CUs. Here is a good page on How to Optimize Compute Usage on Solana.

• Priority Fee: Including a priority fee is essential. You should check the prevailing market rates for the accounts your transaction needs to write-lock. Our Improved Priority Fees API can help you determine a competitive fee without overpaying.

---

Resources

• Example Code: See our Optimized Transactions Examples repository on GitHub for sample client-side retry logic.

• Further Reading: This thread on X by Jordan from Anza Labs provides excellent context on this topic.