Skip to content

Compute Units

CU (Compute Units)

CU (Compute Units) is the unit Solana uses to measure the computational resources consumed during transaction execution. Each operation consumes a certain number of CUs, similar to the concept of Gas in Ethereum, but with different billing methods and limitation mechanisms.

Basic Concepts

In Solana, every transaction consumes computational resources during execution, including: - CPU instruction execution - Memory access - Account data read/write - Cross-Program Invocation (CPI) - System calls (syscall)

CU is the metric that quantifies this resource consumption. Different operations consume different amounts of CU: - Basic instructions: approximately 1-3 CU - Memory allocation: approximately 0.5 CU per byte - Account verification: approximately 100 CU per account - CPI calls: starting at approximately 1,000 CU - SHA256 hashing: approximately 20 CU per 32 bytes

Limits and Configuration

Default Limits - Default budget per transaction: 200,000 CU - Maximum limit per transaction: 1,400,000 CU - Total CU per block: approximately 48,000,000 CU

Dynamic Adjustment Developers can request more CU through ComputeBudgetInstruction:

use solana_sdk::compute_budget::ComputeBudgetInstruction;

// Request 400,000 CU
let set_compute_unit_limit = ComputeBudgetInstruction::set_compute_unit_limit(400_000);

// Set priority fee (micro-lamports per CU)
let set_compute_unit_price = ComputeBudgetInstruction::set_compute_unit_price(1_000);

CU and Transaction Fees

Solana's transaction fees consist of two parts:

  1. Base Fee: Fixed at 5,000 lamports (per signature)
  2. Priority Fee: CU amount x CU price

Priority fee formula: 

Priority Fee = Actual CU consumed x CU unit price (micro-lamports) / 1,000,000

For example, if a transaction consumes 100,000 CU and the CU unit price is set to 10,000 micro-lamports: 

Priority Fee = 100,000 x 10,000 / 1,000,000 = 1,000 lamports
Total Fee = 5,000 + 1,000 = 6,000 lamports

Priority Ordering

When the network is congested, validators prioritize packaging transactions with higher priority fees. CU price becomes a key factor in transaction competition:

  • Low priority: CU price = 0 (only base fee paid)
  • Medium priority: CU price = 1,000 - 10,000 micro-lamports
  • High priority: CU price > 100,000 micro-lamports

In scenarios such as DeFi arbitrage, NFT mints, etc., users often set higher CU prices to ensure their transactions are executed quickly.

CU Optimization Strategies

Developers can reduce their program's CU consumption through the following methods:

1. Reduce Account Count Account verification and loading consume CU, so try to merge accounts or use PDAs.

2. Optimize Data Structures - Use compact data types (u32 instead of u64) - Reduce serialization/deserialization overhead - Use zero-copy techniques to avoid memory copying

3. Batch Operations Combine multiple small operations into a single transaction to reduce repeated account loading and verification.

4. Avoid Redundant Computation Cache computation results to avoid performing the same calculation multiple times within a single transaction.

5. Use Lightweight Libraries Choose optimized libraries (such as the Anchor framework) to reduce unnecessary CU consumption.

CU Monitoring

Developers can monitor CU consumption using the following tools:

  • Transaction Simulation: Simulate a transaction before sending to check estimated CU consumption
  • Log Analysis: Record CU consumption at key points using the sol_log_compute_units!() macro
  • Performance Analysis: Use Solana Explorer to view actual CU usage of transactions
  • Gas (Ethereum): A resource metering unit similar to CU, but Ethereum's Gas prices fluctuate more
  • Priority Fee: An additional fee calculated based on CU consumption, used to incentivize validators to prioritize transactions
  • Transaction Size Limit: Solana transactions have a maximum size of 1,232 bytes; in addition to CU limits, byte limits must also be considered
  • Parallel Execution: Solana can execute non-conflicting transactions in parallel; CU limits apply to individual transactions