Sending TXs
Recommendations to optimize transaction delivery through our Cascade network.
Last updated
Was this helpful?
Recommendations to optimize transaction delivery through our Cascade network.
Last updated
Was this helpful?
Manage retries in your client/backend. Don't rely on the RPC retry service!
Include maxRetries: 0 when sending.
Sample code to manage client-side retries is in our repo on GitHub.
Simulate in a separate RPC call before sending. When simulations are not requested, we have more delivery routes available. The extra delivery routes will speed up confirmations.
Include skipPreflight: true when sending.
Blockhashes from a 'finalized' commitment are the most reliable. Using 'confirmed' will work too. Never use 'processed' for blockhashes.
The commitment level of your connection for sendTransaction() should match your block hash.
Set a tight CU budget. The default CU budget is too high for most transactions. An accurate budget will help validators pack your TX when limited space remains in the block. Here is a good page on .
Priority fees are essential, but don't go crazy.
The blockchain can become congested with more transaction requests than could possibly be written to the blockchain. We call that "backpressure." Backpressure means some users need to wait & try again.
Previously, the backpressure accumulated in queues on the RPC nodes, where the RPCs would retry transactions on the user's behalf. When there is too much backpressure, the queues become saturated, and the RPC can no longer send TXs.
How do we fix the problem? Don't use the retry queues!
We recommend that all dApp developers take control over user experience and manage TX retries; your app will be more awesome, and TX delivery will be more predictable without queues.
The required changes are:
Add retry logic to your application
Include maxRetries: 0 with sendTransaction().
That's it! The RPCs will no longer use the queue.
Our Cascade delivery network sends each transaction through multiple pathways. We have more delivery options available when simulations are not required. For the fastest delivery, include skipPreflight: true when sending.
If you need simulations, use simulateTransaction() immediately before sending. Many traders skip simulations to save valuable milliseconds before sending.
The default CU budget is too high for most transactions. An accurate budget will help validators pack your TX when limited space remains in the block. In the future, providing an accurate budget will be critical. For reference, a simple SOL transfer requires only 500 CUs, and a token transfer requires only 5000.
The inclusion of a priority fee is critical. As little as 1 Lamport is sufficient. However, you should check the prevailing rates for your writable accounts. The improved priority fees API will help you identify fees at the Nth percentile. Don't go crazy with your PFs. Slightly below the median value should be OK. See .
Jordan from Anza Labs has some good advice on X. See the thread here: