Solana compute units: what they are and why your bot's transactions fail

13 November 2026

Solana compute units are the metered amount of computational work a transaction is allowed to perform on the network, and when your trading bot runs out of them - or when you don't set enough - its transactions get dropped or fail. The short version: a compute unit is not a fee you pay; it's a budget. If your bot's transaction needs 400,000 units of compute but you only allocated 200,000, the transaction fails before it ever lands, regardless of how much priority fee you attached.

The actual mechanism

Every Solana instruction - whether it's swapping tokens on Raydium, approving a token transfer, or calling a complex DeFi program - consumes a specific amount of compute. The Solana runtime measures this in compute units (CU). A simple transfer might need 150,000 CU. A token swap through a liquidity pool can easily need 300,000 to 600,000 CU, depending on how many programs the transaction touches.

The limit per transaction is 1.4 million compute units. That's a hard ceiling. But here's where bots run into trouble: the default compute unit limit in many Solana libraries and bot frameworks is set to 200,000 CU. That's fine for a basic transfer, but it's far too low for a sniper bot that's trying to buy a memecoin at launch, because that transaction is doing multiple things at once - signing, transferring SOL, calling the DEX program, managing token accounts, and often interacting with a liquidity pool that doesn't even exist yet.

Why your bot fails

When a transaction runs out of compute units mid-execution, the entire transaction reverts. The bot gets an error that often reads something like "Transaction simulation failed" or "Blockhash expired," but the underlying cause is frequently insufficient compute. The network never even tries to include it in a block, because the simulation step - where the node runs the transaction to see if it works - fails first.

There's also a secondary issue related to compute unit price. Solana uses a local fee market. If you set a low compute unit limit, you might also need to set a higher compute unit price (the priority fee) to get your transaction into a block during congestion. Bots that fail on Raydium launches often fail because they set a reasonable priority fee but a laughably low compute limit. The transaction simulates fine at 500,000 CU, but the bot only allocated 200,000, so it's dead on arrival.

How to check and fix it

Here's what you can do, in order.

1. Find the actual compute usage. Run a transaction simulation with your bot's current settings. Most Solana RPC providers offer a simulateTransaction endpoint. The response includes a unitsConsumed field. That number tells you exactly how much compute the transaction used. Compare it to what your bot is allocating.

2. Set the compute limit explicitly. In most bot configurations, you can pass a computeUnitLimit parameter. Set it to the value from the simulation, plus a 10 - 20% buffer. If simulation says 410,000 CU, set 500,000 CU. That buffer covers edge cases where the program's behavior changes slightly - for example, if the pool's fee structure shifts between simulation and execution.

3. Check the compute unit price separately. The price is what you pay per compute unit, measured in micro-lamports per CU. A higher price means your transaction is more likely to be included during congestion. But raising the price doesn't fix a low limit. They're independent settings. Many bots let you adjust both. If you only touch one, you're guessing wrong.

4. Look at the transaction's instruction count. A snipe at launch often bundles multiple instructions: creating a token account, approving spending, swapping. Each instruction adds compute. If your bot is failing consistently at launch, try reducing the number of instructions it bundles. For instance, if the token account already exists, don't create a new one.

A common misconception

Newer traders often confuse compute units with gas fees on Ethereum. They're different. On Ethereum, you set a gas limit, and unused gas is refunded. On Solana, you pay for the compute units you request, not the ones you use - but the priority fee portion (the price per CU) is only charged for the units actually consumed. The limit is a cap, not a prepayment. So setting a high limit doesn't cost you more in priority fees, unless you use them. That means there's no downside to setting a generous compute limit, as long as it's under 1.4 million. The failure risk comes from setting it too low.

What actually happens on a failed bot transaction

When your bot's transaction fails due to compute, the SOL spent on the priority fee is still gone. The network charged you for the simulation and the attempt. The swap never happened, but your wallet is lighter. That's why you see bots repeatedly "buying" nothing while burning fees on failed attempts - especially during volatile launches when the token's program does more work than expected.

One more thing: some Telegram bots hide compute settings behind "advanced" or "expert" mode. If your bot's interface doesn't show compute unit controls, it's using a default. That default is often the culprit. If you can't adjust it, you're stuck with whatever the bot's developers chose. That's a limitation of the tool, not something you can fix by tweaking priority fees.

What to check before you blame the bot

If your bot keeps failing on Raydium launches, check three things in this order: the compute unit limit, the compute unit price, and the blockhash expiration. The first two are the most common culprits. The third - an expired blockhash - happens when the transaction sits in the queue too long, which is often a side effect of the first two being wrong. Fix the compute settings, and the blockhash issue usually resolves itself.

The honest take: a lot of bot failures are misdiagnosed as network congestion or RPC issues when they're actually a compute budget problem. The network isn't rejecting you because it's busy. It's rejecting you because your transaction tried to do more work than you allowed it to do.

Back to trading bots