How do you set compute unit limit and price for a Solana transaction

18 October 2026

You set the compute unit limit and priority fee directly in the transaction's instructions when you build it, or by using wallet settings that translate your chosen priority level into a price. The compute unit limit caps how much computational work the transaction can request, and the compute unit price (priority fee) determines how much you pay per unit to incentivize validators to include it sooner.

Why these settings matter

Solana transactions consume compute units - a measure of the program instructions executed, memory accesses, and cryptographic operations performed. Each transaction has a default compute unit budget of 200,000 units. If your transaction executes more work than that, it fails with a "Computational budget exceeded" error. If it uses far less, you may be overpaying relative to what you need.

The priority fee is the extra amount you pay on top of the base fee (a fixed 5,000 lamports per signature). You set it as a price per compute unit. Validators sort pending transactions by the total fee they attach (base + priority). A higher priority fee per compute unit makes your transaction more attractive to include quickly, which matters during network congestion.

Setting the compute unit limit

You request a specific compute unit limit by adding a ComputeBudgetInstruction::set_compute_unit_limit instruction to your transaction. This instruction must be the first one in the transaction's instruction list.

In code (using the Solana SDK for Rust):

use solana_sdk::compute_budget::ComputeBudgetInstruction;

let tx = Transaction::new_signed_with_payer(
 &[
 ComputeBudgetInstruction::set_compute_unit_limit(1_000_000),
 // your actual program instructions follow
 ],
 Some(&payer.pubkey()),
 &[&payer],
 recent_blockhash,
);

The limit can range from 0 to 1,400,000 compute units. If you set it above 1,400,000, the transaction will be rejected. Common real-world limits for complex operations (like a Jupiter swap with multiple token accounts) often fall between 400,000 and 1,200,000 units.

Practical approach: Simulate your transaction first. Most Solana RPCs support a simulateTransaction method that returns the actual compute units consumed. Add a 20-30% buffer to that number to account for variable execution paths.

Setting the compute unit price (priority fee)

You add a ComputeBudgetInstruction::set_compute_unit_price instruction to set the price per compute unit. This instruction must also come early in the transaction - typically right after the compute unit limit instruction.

In code:

let tx = Transaction::new_signed_with_payer(
 &[
 ComputeBudgetInstruction::set_compute_unit_limit(1_000_000),
 ComputeBudgetInstruction::set_compute_unit_price(100_000), // 100,000 lamports per compute unit
 // your actual program instructions
 ],
 Some(&payer.pubkey()),
 &[&payer],
 recent_blockhash,
);

The price is specified in micro-lamports per compute unit (1 micro-lamport = 0.000001 lamports). So a value of 100,000 means 0.1 lamports per compute unit. The actual fee you pay is: compute unit limit × compute unit price × 10^-6 lamports. For a limit of 1,000,000 and price of 100,000, the priority fee would be 100,000 micro-lamports × 1,000,000 compute units / 1,000,000 = 100,000 lamports (0.0001 SOL).

Choosing a priority fee

There is no fixed table of "good" priority fee values. The right price depends on current network congestion. You can estimate it by:

1. Querying recent priority fee statistics from your RPC provider using the getRecentPrioritizationFees method. This returns a list of recent fees paid by successful transactions, grouped by write lock accounts. The median or 75th percentile of those fees gives you a reasonable starting point.

2. Using wallet features. Phantom and Solflare allow you to set a priority level (Low, Medium, High) that translates into a fee estimate based on recent network conditions. These estimates update every few seconds.

3. Setting a fixed price for predictable operations. If you run a bot or script that submits the same type of transaction regularly, you can hardcode a fee that worked in recent history, but be prepared to adjust it when network conditions change.

Combining both in a single transaction

A transaction that sets both the compute unit limit and the priority fee looks like:

• Instruction 0: set_compute_unit_limit(800_000)
• Instruction 1: set_compute_unit_price(50_000)
• Instruction 2: your actual program call

The total fee becomes: base fee (5,000 lamports × number of signatures) + priority fee (compute unit limit × compute unit price × 10^-6 lamports).

Common pitfalls

• Order matters. If you place your program instruction before the compute budget instructions, the budget instructions may not apply, and the default 200,000 limit will be used.

• Overestimating the limit. Setting a very high compute unit limit (near 1,400,000) does not cause failure, but it increases the priority fee you pay for the same price per compute unit. Use a realistic limit to avoid wasting lamports.

• Forgetting to update during congestion. A priority fee that worked an hour ago may be too low during a memecoin launch or NFT mint. Check getRecentPrioritizationFees periodically if you submit transactions regularly.

• Wallet settings override manual instructions. If you use a wallet that adds its own priority fee (some wallets do this automatically), your manually set compute unit price may be overridden. Check the raw transaction before signing.

When you don't need to set these

For simple SOL transfers or basic token transfers, the default 200,000 compute unit limit is usually sufficient, and you may not need a priority fee at all. The transaction will confirm eventually, though during heavy congestion it may take many minutes. If you are not in a hurry, leaving both unset is fine.

Back to solana