Compute units, explained

What a compute unit measures

Solana meters work rather than time. Every instruction a transaction executes consumes some quantity of compute units, and the total a transaction may consume is capped.

The reason the cap exists is that block space is finite and shared. Without a ceiling, one transaction could occupy an arbitrary amount of a validator's capacity, and the network could not make guarantees about how much it can process. Every transaction therefore declares in advance how much room it wants.

That declaration is a commitment, not an estimate. If execution reaches the declared ceiling before finishing, the transaction aborts. It does not get extended, it does not partially complete, and the fees paid to reach that point are gone.

Two settings that get treated as one

Almost all confusion here comes from collapsing two independent knobs into a single idea called the compute budget.

The two multiply to produce the priority fee. That relationship is why a generous limit is not free: raising the ceiling raises what you pay at any given price, even if the extra room is never used.

The limit, and how it fails

Setting the limit too low produces one of the more confusing failures in scripted trading, because the transaction was valid, well funded and correctly priced, and it still produced nothing.

What happens is that execution proceeds normally until the budget is exhausted, then stops. From the outside it looks like any other failed swap. Teams reading only that a swap failed will reach for slippage or fees, and neither is the problem.

The reason this bites scripts specifically is that routes vary. A swap through a single pool is inexpensive. A route split across several venues, touching more accounts and running more instructions, costs considerably more. A limit tuned against the simple case fails whenever the router picks a more complex path, which it does exactly when the token has liquidity in several places.

The failure guide covers how to read the transaction log to tell this apart from the other causes, and it is worth doing that once properly rather than adjusting settings in the dark.

The price, and how it fails

The price does not affect whether a transaction can complete. It affects whether it gets included promptly, by determining the priority fee attached to it.

Set it too low during a contested period and the transaction waits. Wait long enough and it becomes irrelevant, because the blockhash it carries expires and it is rejected without being processed. That is a timing failure produced by a pricing decision, which is why these two problems are so frequently confused with each other, and the expiry guide covers the other routes to the same error.

Set it too high and nothing breaks; you simply pay more than the moment required. That is a smaller error than the alternative, which is why under-paying is generally the more expensive mistake in this category. A transaction that lands late executes at a worse price or fails outright, and the base fee is charged either way.

What a swap actually consumes

There is no single correct number, and anyone quoting one is describing a specific route rather than a general rule.

Consumption scales with what the transaction touches: how many accounts are read and written, how many programs are invoked, whether address lookup tables are involved, and how many hops the route contains. A direct swap against one pool sits at the low end. A multi-hop route across venues, with account creation included, sits considerably higher.

Because of that variance, the reliable approach is not to memorise a figure but to simulate the transaction you intend to send. Simulation reports the units actually consumed, and setting a limit modestly above that figure gives you headroom for variation without paying for room you will never use.

The practical consequence for a campaign is that the correct limit is not a constant across the run. Routes differ between swaps as depth shifts and the router chooses differently, so a script that sets one value for everything will either overpay on the simple cases or fail on the complex ones.

One consequence of the limit affecting the fee is worth spelling out because it produces a quiet overspend. A script that requests a very generous ceiling on every transaction, on the reasoning that headroom is safer, is multiplying that ceiling by the price on every single swap. Across a campaign of a thousand transactions that is a real number, paid for room that was never used. Headroom is sensible; a ceiling several times actual usage is a habit worth costing out before adopting.

Setting both sensibly

1. Simulate to find real usage, then set the limit modestly above it rather than at a generous round number.
2. Set the price from current conditions, not from a figure copied out of a guide written months ago.
3. Do not raise the limit to fix an inclusion problem. That raises the fee without addressing the cause, and it treats the wrong dial.
4. Do not raise the price to fix an abort. An aborted transaction had enough priority to be processed; it ran out of room.
5. Re-simulate when routes change, because a token that gains a second pool starts producing different transactions.
6. Read the error before changing anything. These two failures are indistinguishable without it and call for opposite responses.

The broader point is that both settings are small numbers that decide whether a swap happens at all, and neither appears in most people's mental model of what a trade costs. They sit alongside the base fee, the rent deposits and the venue fees that dominate the total, all of which the fee breakdown works through with figures. Getting the compute settings wrong does not make a campaign expensive; it makes parts of it silently not happen, which is harder to notice and more annoying to diagnose.