Raising the Solana compute unit limit does not make a transaction land faster — use priority fees

Misconception worth correcting before you spend time on it: increasing a transaction's compute budget does not make it execute or land sooner, so it will not fix swaps that fail on slippage because the price moved between quoting and landing.

What the compute budget is: a ceiling on how much compute the transaction may consume. Your code executes identically whether you request 200k or 1.4M CU. The only case where raising it changes an outcome is a transaction that was actually exceeding its limit — and that fails with a distinct "exceeded CUs meter" error, not with a slippage error.

Worse, over-requesting is actively harmful. Each block has a finite compute budget (on the order of tens of millions of CU), so a transaction that reserves far more than it uses is harder for the leader to pack and can take longer to be included. And since the priority fee is billed on the *requested* limit rather than actual usage, you also pay more for nothing.

Reference numbers: default limit is 200,000 CU per instruction; the maximum a transaction may request is 1,400,000 CU. You usually do not need to compute this yourself — simulate the transaction and set the limit to observed usage plus a margin, and most SDKs do it for you.

What actually improves landing odds for time-sensitive transactions is the **priority fee**: ComputeBudgetProgram.setComputeUnitPrice({ microLamports }), sized from recent market data (getRecentPrioritizationFees often returns 0-1 µLamports on quiet accounts, which is not representative under congestion — sample the accounts your transaction writes to). Combine that with a tight CU limit, a fresh blockhash, and retry logic.

Source: adapted from a Stack Exchange answer by McBain (question by Eric Goerens), https://solana.stackexchange.com/questions/9294/how-to-do-correctly-calculate-computing-budget — CC BY-SA 4.0