Skip to main content
The /build response includes computeBudgetInstructions with the compute unit price but not the compute unit limit. You need to simulate to determine the correct limit. Why: since you are building your own transaction with custom instructions, the CU usage will differ from a base swap. The simulation gives you the actual number, and you set the limit with a safety buffer.

​
Why this matters

Priority fee cost is calculated as:
A tighter CU limit directly reduces the priority fee you pay. Setting it to the maximum (1,400,000) when you only use 200,000 means you pay 7x more than necessary. See Solana fee structure for details.

​
Customise compute unit price

The /build response bakes a compute unit price into computeBudgetInstructions based on recent network priority fees. Use computeUnitPricePercentile to control how aggressively you bid: When mode=fast is set and no computeUnitPricePercentile is provided, the default is the 90th percentile instead of the 50th. You can also override entirely by replacing the computeBudgetInstructions from the response with your own setComputeUnitPrice instruction.

​
Cap the compute unit price

The estimated compute unit price tracks recent network priority fees. When recent blocks contain transactions bidding extreme values, the estimate can spike far above what is needed to land. Validate the compute unit price before signing.
Decode the compute unit price from the setComputeUnitPrice instruction in computeBudgetInstructions and clamp it to your own maximum. The instruction data is base64: a 1-byte discriminator (3 for setComputeUnitPrice) followed by the price as a little-endian u64 in micro-lamports.
Run this on the raw /build response before converting the instructions for your SDK, so the same check works with both @solana/kit and @solana/web3.js. With the clamp in place, your worst-case priority fee is bounded: CUP cap × CU limit. A lower cap can slow landing during congestion, so pick a maximum that matches the fees you are willing to pay. If you already maintain your own priority fee estimate, you can skip the decode: drop the returned computeBudgetInstructions and set your own setComputeUnitPrice with the lower of your estimate and your cap. A low computeUnitPricePercentile is not a substitute for a cap, because a percentile of an inflated fee distribution can still be extreme.

​
Estimate compute unit limit

  1. Build the transaction with all your instructions + max CU limit (1,400,000)
  2. Simulate with replaceRecentBlockhash: true to get actual CU consumed
  3. Rebuild with 1.2x the simulated value (capped at 1,400,000) as the CU limit
  4. Add the CU price instruction from the /build response
The Build code example demonstrates this in steps 4-5 (kit) with full working code.
Setting the CU limit too tight causes transaction failures. Always use at least a 1.2x buffer over the simulated value.