X

Solana Compute Unit Price

microLamports, Compute Budget & Fee Formula

Solana Compute Unit Price

Solana Compute Unit Price

The Solana compute unit price is the core parameter that determines how much you pay in priority fees. Expressed in microLamports per compute unit (CU), this value — combined with the compute unit limit — calculates your total priority fee. Understanding it is essential for writing cost-efficient on-chain programs and transactions.

Compute Unit Price is measured in microLamports per CU. One microLamport equals 0.000000001 SOL (10⁻⁹ SOL). The priority fee formula: ceil(computeUnitPrice × computeUnitLimit / 1,000,000) lamports.

What Is a Compute Unit?

A compute unit (CU) is the fundamental unit of computational work on Solana. Every operation a transaction performs — arithmetic, memory reads, syscalls, cross-program invocations — costs a fixed number of CUs. Solana's runtime meters these costs precisely during execution. The maximum compute unit limit per transaction is 1,400,000 CU, and the maximum per block is 48,000,000 CU. Simple transfers consume around 300–600 CU; complex DeFi instructions may consume 100,000–400,000 CU.

How the Scheduler Uses Compute Unit Price

Solana's transaction scheduler ranks transactions using a priority score calculated as: reward / cost, where reward equals the priority fee plus the validator's share of the base fee, and cost is the scheduler's estimated CU consumption. Transactions with higher compute unit prices receive higher priority scores and are dequeued for execution first during congestion. This is why setting a competitive compute unit price is critical for time-sensitive transactions.

Setting an Optimal Compute Unit Price

Developers should always set an explicit compute unit limit using ComputeBudgetProgram.setComputeUnitLimit() alongside their compute unit price. Without an explicit limit, transactions use the default maximum, which increases their apparent cost in the scheduler's priority calculation and makes them appear less competitive than transactions with tightly-set limits. Simulate your transaction to find its actual CU consumption, add a 10% safety buffer, and combine that with a dynamically fetched compute unit price for optimal efficiency.