Compute Units on Solana

Solana’s reputation as the fastest, highest-throughput blockchain is powered by the concept of compute units (CUs)—the raw “fuel” behind every on-chain action. But as activity surges and DeFi/NFT apps grow more complex, understanding CUs—and how users, bots, and protocols pay for and sometimes waste them—is crucial for anyone serious about optimizing cost and performance.

Key Definitions: Compute Units, Allocation, Consumption, and Priority Fees

Compute Units (CUs)

A compute unit is Solana’s way to measure how much computation is required to process a transaction. Each instruction (swapping tokens, minting NFTs, etc.) is “priced” in CUs. Just like gas on Ethereum, too little compute, and your transaction fails; too much, and you might be overspending.

• •
  Most non-ComputeBudget instructions have a default allocation of 200,000 CU while default program instructions were reduced to a default allocation of 3000 CUs to improve validator performance.
• •
  Max per transaction: ~1.4M CU.

CU Limit (Allocated) vs CU Consumed

• •
  Consumed: the actual compute used by the program (e.g. transfer ≈ 300 CU).
• •
  Limit (Allocated): the budget you declare via setComputeUnitLimit.

  • •
    If not set, defaults to 200k CU for an instruction.
  • •
    If you set it (e.g. 300k), that replaces the default — it does not add up.You always get billed on the allocated limit, not the consumed CU.

CU Price & Priority Fee

• •
  CU Price: what you’re willing to pay per CU, in micro-lamports per CU.
• •
  Priority Fee = CU Price × Allocated CU.
• •
  Optional: if you don’t set CU price, the priority fee = 0
• •
  Validators look at fee per CU (not just total fee) when deciding which transactions to prioritize in congestion.So smaller CU limit + higher CU price = stronger priority signal, even if total SOL paid is the same.

Transaction cost and Transaction fees

• •
  Transaction fee = base fee + (priority fee if set). This is what the validator gets for processing our transaction.
• •
  Transaction cost determines block-packing. Its a broader term including more than just the CUs consumed by validators during execution of transactions. It includes:

  • •
    Execution (program) CUs
  • •
    Loaded Account Data Cost
  • •
    Write Lock Cost
  • •
    Signature Cost
  • •
    Data Bytes Cost

Current CU Limits on Solana

• •
  Per Instruction: Default 200k CU per non-ComputeBudget instruction (unchanged). Default program instructions have been reduced to 3k CU per instruction to improve validator performance.
• •
  Per Transaction: Max ~1.4M CU per transaction (unchanged).
• •
  Per Account (per block): Max 12M CU per account per block (unchanged).
• •
  Per Block (global): Raised from 48M → 50M (Feb 2025) → 60M (mid-2025), with 100M proposed (SIMD-0286).

How Cost Units Are Calculated:

• •
  Compute Units consumed: The actual compute your tx used at runtime. Exposed as meta.computeUnitsConsumed in RPC
• •
  Signatures: Crypto checks for the tx. Read from the message header; charge 720 CU per signature .
• •
  Writable accounts: State the tx can modify. Derive from header counts + ALT writable indexes; charge 300 CU per writable. (CPIs don’t add new locks; only message accounts count.)
• •
  Instruction data bytes: Total payload size of all instructions. Sum their data lengths; charge 1 CU per 4 bytes (i.e., bytes ÷ 4).
• •
  Loaded accounts byte limit: Cap on account data the tx may load. From the last SetLoadedAccountsDataSizeLimit (default 64 MiB); charge 8 CU per 32 KiB page → 8 × ceil(bytes / 32 KiB).
• •
  Precompile verifies (if used): Explicit crypto ops inside instructions; add per call: secp256k1: 6,690 CU ed25519: 2,280–2,400 CU (feature-dependent) secp256r1: 4,800 CU

"“Tracks the growing share of transactions where users explicitly request more compute than defaults. Rises often map to volatile market days, DEX launches, or sophisticated bot activity.”"

Practical Example: How and Why CUs Are Used

Imagine a DEX trading bot during a token launch. To guarantee inclusion, it allocates 400,000 CUs—double the default—and sets a priority fee. If the network’s busy and the trade executes, it might only use 220,000 CUs, but pays as if it used all 400,000 (in addition to the priority fee).

If it had gambled on less and run out, the transaction would fail and the α (alpha) gone.

"The persistent gap between allocated versus consumed CUs above highlights ecosystem-wide over-allocation. This results in real, compounding costs to users and protocols"

Recent Changes: Solana CU Limits & Ecosystem Effects

Key upgrades

• •
  Solana cut the default CU allocation for native programs from 200k to 3k, reducing waste and accidental overpayment—though best practice remains setting your own compute limit and price.
• •
  Solana has raised block capacity by 20%—from 50M to 60M CUs—giving more room for heavy transactions like DeFi swaps, NFT mints, and MEV auctions while reducing “budget exceeded” errors.
• •
  For developers and users, this means fewer failures, smoother execution, and lower congestion fees. The trade-off: validators need stronger hardware and faster sync, raising centralization concerns.
• •
  Next up, proposal SIMD-0286 targets 100M CUs per block, a 66% jump to further boost throughput for demanding apps.

"Why these changes? Now, more “real” transactions can fit in each block, reducing both cost and failed transaction risk."

"“This shows a decline over the past 30 days in the average CU consumed per block indicating a reduction in CU intensive transactions posted on the Solana blockchain.”"

Transaction Bytes: Who Uses Them and Why?

Byte size refers to the total number of bytes that make up a transaction’s data payload—including all instructions, accounts, signatures, and associated data. The byte size directly determines how much space a transaction occupies in a Solana block. Larger transactions—with more instructions, accounts, or bigger instruction data fields—consume more bytes, reducing the number of transactions that can fit within a single block’s limited capacity.

Why it matters?

The higher the byte size, the more block space your transaction uses, which can increase fees and potentially delay confirmation during network congestion. This is especially relevant for complex programs like DeFi protocols or NFT mints, which often involve multiple instructions and large data payloads.

In summary, Byte size is the precise measure of the total data footprint of a transaction, and optimizing it helps maximize throughput and minimize costs on Solana.

"“The above chart compares the CUs consumed versus CUs allocated for the previous 7 days shows how common is over allocation in the ecosystem including native programs.”"

"“Most transactions are compact, but a significant tail of large transactions—often produced by DeFi aggregators or airdrop claim programs—can monopolize bandwidth.”"

How Are Protocols Using and Paying for CUs?

DEXs and aggregators dominate compute usage, especially during market volatility. Tracking these flows helps identify optimization opportunities and cost drivers.

"“Recent spikes often match major launches or liquidity mining events; a signal for both product teams and infra planners.”"

CU Consumption Efficiency & Overspending

Not all protocols are created equal. Some consume almost all of their allocated CUs (high efficiency); others routinely overbid and waste.

"“Defi is the highest consumer of CU bandwidth amongst all ecosystems consuming almost two-thirds of all the bandwidth.”"

"“Millions of CUs paid for but never used across protocols—an invisible but significant drain on user and treasury funds.”"

Priority Fees: Real-Time Price of Inclusion

"“Fee spikes signal congested periods and lead to meaningful advantages for power users and bots who can strategically bid on blockspace.”"

"“Rare but extreme outliers reveal competitive trading frenzies where the race for first inclusion gets expensive fast.”"

Entrypoint Macro

Why it exists

• •
  Every Solana program must expose an entrypoint so the runtime knows where to begin.
• •
  entrypoint is a macro that expands to the boilerplate function process_instruction(program_id, accounts, instruction_data).

Hidden CU costs

• •
  The runtime copies all account data and instruction data into memory before your logic starts.
• •
  Even a “do nothing” program consumes some CUs just to deserialize inputs.

Impact of account count

• •
  More accounts = more deserialization work = more CU cost.
• •
  Passing unnecessary accounts into your program increases CU use for no reason.

Anchor’s role

• •
  Anchor generates its own entrypoint automatically, wrapping Borsh deserialization of your #[derive(Accounts)] struct.
• •
  This adds some overhead compared to hand-rolled minimal parsing, but it’s optimized for safety and developer productivity.

When to care

• •
  For high-throughput, latency-sensitive apps (DeFi, order books, MEV), custom entrypoints can cut a few thousand CUs off each call.
• •
  For most apps, Anchor’s entrypoint overhead is negligible compared to your core logic.

Best practices

• •
  Don’t pass accounts you don’t use.
• •
  Measure with sol_log_compute_units() right after entrypoint deserialization to see its footprint.
• •
  Consider manual deserialization only if CU usage is the bottleneck.

In short, entrypoint isn’t just boilerplate — it sets the stage for CU consumption. The more data and accounts you pass, the bigger the deserialization bill. Anchor handles this efficiently for most use cases, but power users can squeeze out savings by writing lean entrypoints.

Conclusion: Why CU Optimization Matters—Now More Than Ever

Solana’s ongoing upgrades give everyone more headroom—but the incentive to optimize is economic as much as technical. Reducing CU waste benefits:

• •
  Protocol treasuries: Fewer wasted rewards; more to spend on growth.
• •
  Users/traders: Lower fees, more competitive inclusion.
• •
  Ecosystem: Greater inclusive throughput, higher chain health.

Monitor your protocols’ usage, adapt to Solana’s changing limits, and iterate toward efficiency for competitive advantage

Want to see live stats or analyze your project? Dive deeper at research.topledger.xyz/compute-units.