From my first impression, the setComputeUnitLimit() just set the cap of execute unit, so, said Tx actually need 300_000 CU, then I can call setComputeUnitLimit() with any value that higher than 300_000, there is no different bwteeen 500_000, 700_000, 900_000 ...

But some of my colleage not sure of this and worry that all provided CU by setComputeUnitLimit() will be consumed.

Which is right? And how to create a test to verify the conclusion?

2 Answers 2


Short answer is no: currently the cost-per-CU is not implemented on mainnet as of April 2024. Eventually, it will be!

Also, it currently does not really matter how much you pay in priority fees. Txes with a priority fee will be more likely to be processed and increasing the fee does not typically make a difference. This is because RPCs typically group txes into "fee or not" and not sorted by fee/unit.

There is a big catch though: the more CU you request, the less likely your tx is to be processed. The technical reason for this is basically that each block has some amount of CU available (let's say 2 million) and the RPC will essentially put txes in the queue to execute at random. If the queue is close to full (let's say 1.5 million out of 2 million is used up, so 500k is available) and your 900k CU tx comes in, it'll get dropped, while the 400k tx would be added to the queue.

  • The catch you point out is interest and make sense. Though, you said that cost-per-CU is not implemented on mainnet, it is unbelievable. Can you share more material to support this point? Commented Apr 24 at 2:43
  • Here's a link with an example program: rareskills.io/post/solana-compute-unit-price. My answer also somewhat ignores the new SetComputePrice (aka the priority fee) ix from the Compute Budget Program, which is Solana's current way to implement "cost-per-CU", but is technically optional and doesn't appreciably increase your tx's odds to get picked up (usually). See helius.dev/blog/… for details.
    – Whiteseal
    Commented Apr 24 at 15:53

Your impression of setComputeUnitLimit() is indeed correct. This function is used to set the maximum number of compute units (CUs) that the transaction is allowed to consume. If the actual compute units required for executing the transaction are less than the limit set, only the required amount will be consumed, not the full amount specified by the limit.

This is useful for ensuring your transaction does not exceed a certain budget and ensures your transactions are processed within the resource limits you specify

For instance, if you set the compute unit limit to 500,000 but the transaction only needs 300,000 compute units, it will only consume 300,000 CUs.

If the transaction tries to exceed this cap during execution, it will fail.

How to Test and Verify:

To verify how setComputeUnitLimit() behaves, you can create a test where you measure the actual compute units consumed by a transaction. Here’s a basic outline for such a test using Solana's development tools:

Execute the transaction with a compute unit limit just above the expected consumption (e.g., if expected is 300,000, set it at 310,000). Execute the same transaction with a higher limit (e.g., 500,000 and 700,000).

Measure and Compare:

Use simulateTransaction RPC calls to simulate the transactions and retrieve the number of compute units actually used.

Compare the compute units consumed in each transaction to verify if the set limit affects the actual usage.



  • @Whiteseal not really sure where you get that setComputeUnitLimit has not been released but solana.com/docs/intro/transaction-fees and solana.com/developers/guides/advanced/…, Not sure who downvoted my answer or why my answer has been downvoted at all. Commented Apr 23 at 21:34
  • Thanks for great detail explaination. I'm absolute agree with you. Maybe it is better to: check the accout balance change of Txs of different CU. Commented Apr 24 at 2:37
  • @ChristianLiz-Fonts I think most people are downvoting your answer because it looks a bit too heavily created by chatgpt. Figuring out the meat of the answer from the llm answer is really hard.
    – Jacob Creech
    Commented Apr 25 at 18:28
  • @JacobCreech Don't think that should be a problem, the OP asked various questions so I made sure to include a answer for all of them as well as including how consensus and the blockchain itself guards against overcharging as well. Commented Apr 25 at 18:59
  • @JacobCreech OP upvoted and found it useful so I believe it would have been around the point of someone believing that at the time of writing CU limits could not be placed. Commented Apr 25 at 19:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.