Compute Unit Budget
Transaction primitives
The compute-unit budget is a pair of numbers a transaction sets up front: how many compute units it can consume, and how much it pays per unit as a priority fee. Both are configured by instructions to the ComputeBudget program. They control whether your transaction fits, and how aggressively the leader prioritises it during congestion.
Detailed explanation
The ComputeBudget program lives at ComputeBudget111111111111111111111111111111. Its two important instructions are SetComputeUnitLimit and SetComputeUnitPrice. The first caps how many CUs the transaction is allowed to consume, up to the network max of 1.4M. The second sets the price in microlamports per CU, which is the priority fee.
If you do not set a CU limit, you get the per-transaction default of 200,000 CUs. That is too small for almost any DEX swap and is the silent reason behind a lot of "ComputationalBudgetExceeded" errors. Setting it explicitly to 400,000 or higher fixes that class of failure. If you do not set a CU price, the priority fee is zero and you only land when the leader has slack.
Modern Solana clients call getRecentPrioritizationFees on a target program before signing, then set the CU price to a percentile (often p75) of recent fees. Pair that with a tight CU limit and you get cheap, reliable landings. Pair it with a sloppy limit and you waste lamports on every transaction.
One opinion: do not over-tip. Median CU price plus a small buffer beats blanket "200000 microlamports per CU" by a wide margin once you tune it. Track your landing rate, not your tip spend.
One more practical note. The CU limit you request is also charged against the per-block CU cap. Asking for 1.4M when your transaction only needs 350,000 makes you compete with other large transactions for fewer slots inside a block, which lowers your landing rate even with a high CU price. Right-size the limit to your actual usage plus a 20% buffer. Track real consumption from transaction logs and tighten over time.
When you'll see this
Almost every modern Solana transaction starts with two ComputeBudget instructions. You will see them in the instruction list of any swap, mint, or transfer built with the current Anchor or web3.js helpers. They are the first two instructions because they have to apply before the runtime measures CU consumption.
How NoLimitNodes uses this
We expose live CU pricing on our RPC nodes via getRecentPrioritizationFeesand surface CU consumption per program in our system events stream so you can tune your bot's budget against real network conditions.
Related terms
- Jito Tip · A SOL transfer to a Jito tip account that pays the block engine to include and order your transaction bundle.
- Durable Nonce · A System Program nonce account that lets a transaction stay valid past the 150-slot recent-blockhash window.
- Slippage · The gap between the price you quoted and the price you actually got, set as a tolerance on every swap instruction.
- Processed, Confirmed, Finalized · The three Solana commitment levels, ordered from "this validator saw it" to "supermajority will not roll it back."
- IDL · An Anchor Interface Definition Language file. JSON describing a program’s instructions, accounts, and event layouts.