Compute Budget

Summary

Default 200K CUs per instruction, 1.4M max per transaction. Use SetComputeUnitLimit and SetComputeUnitPrice instructions to optimize. Priority fee is based on requested CUs, not actual usage.

Compute unit limit

Each instruction is allocated a default of 200,000 CUs, and each transaction is capped at 1,400,000 CUs. When no explicit SetComputeUnitLimit instruction is present, the default is calculated based on instruction type:

Default CU limit calculation
default_cu_limit = (num_non_migratable_builtin_instructions * 3,000)
+ (num_not_migrated_builtin_instructions * 3,000)
+ (num_non_builtin_instructions * 200,000)
+ (num_migrated_builtin_instructions * 200,000)

The result is clamped to MAX_COMPUTE_UNIT_LIMIT (1,400,000).

You can override this default by including a SetComputeUnitLimit instruction in your transaction.

To determine the appropriate CU limit:

  1. Simulate the transaction to measure CU consumption.
  2. Add a 10% safety margin to the simulated value.

The priority fee is determined by the requested compute unit limit on the transaction, not the actual number of compute units used. If you set a compute unit limit that is too high or use the default amount, you pay for unused compute units.

Compute budget instructions

The Compute Budget Program (ComputeBudget111111111111111111111111111111) has four instructions.

VariantDiscriminatorParameterTypeDescription
RequestHeapFrame1bytesu32Requested heap size in bytes for each program in the transaction
SetComputeUnitLimit2unitsu32Max CUs the transaction may consume
SetComputeUnitPrice3micro_lamportsu64CU price in micro-lamports
SetLoadedAccountsDataSizeLimit4bytesu32Max total bytes of account data the transaction may load

Source: ComputeBudgetInstruction enum

Constraints and error conditions

The following rules apply when processing compute budget instructions:

  • One per type: only one of each instruction variant is allowed per transaction. Including duplicates causes a DuplicateInstruction error (the entire transaction fails).
  • RequestHeapFrame: the value must be between MIN_HEAP_FRAME_BYTES (32 KiB) and MAX_HEAP_FRAME_BYTES (256 KiB), and must be a multiple of 1,024. Otherwise the transaction fails with InvalidInstructionData. The heap size applies to every program invoked in the transaction (including CPIs).
  • SetComputeUnitLimit: any u32 value is accepted. The effective limit is clamped to MAX_COMPUTE_UNIT_LIMIT (1,400,000).
  • SetComputeUnitPrice: any u64 value is accepted (0 to u64::MAX).
  • SetLoadedAccountsDataSizeLimit: the value must be greater than 0 (NonZeroU32). A value of 0 causes InvalidLoadedAccountsDataSizeLimit. The effective limit is clamped to MAX_LOADED_ACCOUNTS_DATA_SIZE_BYTES (64 MiB).
  • Unrecognized data: any instruction sent to the Compute Budget Program that does not deserialize to a known variant fails with InvalidInstructionData.

The scheduler cost model below describes validator-internal pre-execution cost estimation. Most developers only need the compute budget instructions above.

Scheduler cost model

The validator's scheduler uses a cost model to estimate transaction resource usage before execution. These pre-execution cost estimates determine whether a transaction fits within the block's remaining capacity. They are separate from the CU metering that happens during execution.

The total scheduler cost is the sum of five components (UsageCostDetails::sum):

Scheduler cost formula
total_cost = signature_cost
+ write_lock_cost
+ data_bytes_cost
+ programs_execution_cost
+ loaded_accounts_data_size_cost

Cost components

ComponentDescription
Signature costPer-signature cost for each signature type
Write lock costPer writable account
Instruction data costBased on total instruction data bytes
Programs execution costCU limit from compute budget or default
Loaded accounts data costBased on total loaded account data size

All values are in compute units.

Scheduler cost constants

Vote transaction cost

Vote transactions use a static cost of 3,428 CUs regardless of their actual content.

Block limits

The scheduler enforces per-block limits. If adding a transaction would exceed any limit, it is not included in the block.

SIMD-0286 proposes increasing MAX_BLOCK_UNITS to 100,000,000.

Execution budget constants

The following constants from execution_budget.rs define runtime limits during transaction execution:

ConstantValueDescription
MAX_COMPUTE_UNIT_LIMIT1,400,000Maximum CU limit per transaction
DEFAULT_INSTRUCTION_COMPUTE_UNIT_LIMIT200,000Default CUs per non-builtin instruction
MAX_BUILTIN_ALLOCATION_COMPUTE_UNIT_LIMIT3,000Default CUs per builtin instruction (SIMD-0170)
DEFAULT_HEAP_COST8 CUsCost per 32 KiB heap page
DEFAULT_INVOCATION_COST1,000 CUsCost of one CPI invocation
INVOKE_UNITS_COST_SIMD_0339946 CUsCPI invocation cost with SIMD-0339
MIN_HEAP_FRAME_BYTES32,768Minimum heap size (32 KiB)
MAX_HEAP_FRAME_BYTES262,144Maximum heap size (256 KiB)
MAX_LOADED_ACCOUNTS_DATA_SIZE_BYTES67,108,864Maximum loaded account data per transaction (64 MiB)
MAX_INSTRUCTION_STACK_DEPTH5Maximum instruction stack depth (top-level + CPIs)
MAX_INSTRUCTION_STACK_DEPTH_SIMD_02689Maximum instruction stack depth (top-level + CPIs) with SIMD-0268
MAX_CALL_DEPTH64Maximum SBF-to-SBF call depth within a program
STACK_FRAME_SIZE4,096 bytesSize of one SBF stack frame

Is this page helpful?

Table of Contents

Edit Page

Managed by

© 2026 Solana Foundation.
All rights reserved.
Get connected