Optimal transaction landing using Compute Units (CU) and priority fees

When sending transactions on Solana, optimizing two key parameters can significantly improve your transaction's success rate and cost-effectiveness:

Priority Fees

Priority fees let you bid in local fee markets to get your transactions included faster. When the network is congested and multiple transactions compete to modify the same accounts, validators prioritize transactions with higher priority fees.

Key points about priority fees:

• They are calculated as: compute_unit_limit * compute_unit_price
• Higher fees increase likelihood of faster inclusion
• Only pay what's necessary based on current network competition

Compute Unit Limit

Compute Units (CUs) represent the computational resources your transaction needs. While transactions default to requesting many CUs as a safety measure, this is often inefficient:

1. You pay priority fees for all requested CUs regardless of actual usage
2. Blocks have limited CU capacity - requesting excess CUs reduces total transactions per block

Benefits of optimizing your CU limit:

• Lower transaction costs by only paying for needed CUs
• Improved network efficiency by allowing more transactions per block
• Still ensures sufficient resources for execution

For example, a simple token transfer might only need 20,000 CUs, while an NFT mint could require 100,000 CUs. Setting these limits appropriately helps optimize both your costs and overall network throughput.

Implementation Guide

This guide demonstrates how to programmatically calculate optimal values rather than guessing.

Calculate Priority Fees

When using priority fees it is important to remember that those have the best effect when the competition is taken into account. Adding a huge number manually may result in overpaying more fees than required, while using a too low number might result in the transaction not being included into the block in case there is too much competition.

To get the last paid prioritization fees that were paid for the accounts in our transaction one can use the getRecentPrioritizationFees RPC call. We use the result to calculate an average based on the top 100 fees paid. This number can be aligned according to your experience.

The following steps are necessary:

1. Extract writable accounts from your transaction
2. Query recent fees paid for those accounts
3. Calculate optimal fee based on market conditions

At the bottom of the page you can find a full example where a Sol Transfer is done with this.

Calculate Compute Units

To optimize transaction costs and ensure reliable execution, we can calculate the ideal compute unit limit by simulating the transaction first. This approach is more precise than using fixed values and helps avoid over-allocation of resources.

The simulation process works by:

1. Building the transaction with maximum compute units (1,400,000)
2. Simulating it to measure actual compute units consumed
3. Adding a 10% safety buffer to account for variations
4. Falling back to a conservative default if simulation fails

Full example for Sol Transfer

Following the code above and introducing some boilerplate to create the Umi instance could result in a script like this to create a Sol Transfer transaction: