Why Solana Transaction Costs and Compute Units Matter for Developers

In this article, we clarify the difference between compute units (CUs) and transaction cost, and how they relate to transaction fees on Solana. While these terms are often used interchangeably, they serve different purposes in Solana’s transaction processing pipeline. Understanding these distinctions is important for building efficient programs and ensuring your transactions get confirmed as network throughput scales. We’ll also break down where CUs are spent during transaction processing and why it matters for developers. 

Compute Units vs Transaction Cost vs Transaction Fee

Compute units (CUs) measure execution cost in the runtime. The smallest runtime operation consumes 1 CU and programs have a default limit of 200k CU per instruction with a maximum of 1.4M CUs per transaction. 

Default CUs per txn = 
Min(1.4M, 200k*non_reserve_instructions + 3k*reserve_instructions)

You can learn more about programs that reserve minimal CUs in this article.

Transaction cost is a comprehensive estimate of all resources required to process a transaction,  measured in compute units. Transaction cost is used by the leader to schedule transactions and set block limits. It encompasses not just runtime execution but also pre-execution overhead like signature verification, account data loading, and write lock management.

Transaction Fee is what you pay in SOL (measured in lamports) to compensate validators for processing a transaction. This is different from transaction cost, which represents resource usage measured in compute units (CUs).

Specifically, transaction fees are calculated as follows:

• Priority fee: Derived from your transaction’s Compute Budget, calculated as:

Compute Unit Price (priorityFee) × Compute Unit Limit (either explicitly set or the default)

• Base fees: Fixed charges including:

  • 5,000 lamports per transaction signature.

  • 5,000 lamports per built-in instruction signature verification (e.g., Ed25519, secp256k1).

This distinction matters because a transaction might have a high CU cost but doesn’t necessarily incur higher lamport fees unless priority fees are explicitly added.

Why This Matters for Developers

Optimizing your transaction’s cost by setting limits on execution CUs and peripheral CUs like account data and write account locks, can help improve your transaction’s priority/landing rate and future proof your applications.

Future Proofing for Increased CU Block Limits

With Anza’s mission to double block space in 2025 and increase CU limits reaching 60 million per block, it’s possible to see throughput of 100,000 transactions per second. At Solana’s current max default of 64MB account data per transaction, this could theoretically create 2.5TB of potential data load per block.

Developers who adopt `setLoadedAccountsDataSizeLimit` can view this as essential preparation to improve their transaction landing rates as block limits and network throughput increase. Those who don’t optimize their account data usage could face increasing rejection rates and poor prioritization in congested network conditions. You can read more about loaded accounts data CU optimization here. 

Additionally, Solana’s upcoming transaction v1 format (SIMD-0296) raises the maximum network transaction payload from 1232 bytes to 4096 bytes and removes address lookup tables. This will allow developers to include more accounts directly in a single translation without bundling workarounds.

Priority Fee Calculation

Priority fee is calculated using only execution CUs, not the total transaction cost. The priority fee calculation used by leaders is:

Priority Fee = Compute Unit Limit * Compute Unit Price

For example, a basic token transfer might need only 6k execution CUs. However, if you don’t explicitly limit the loaded account data size, Solana assumes you’re loading the maximum default (64MB), adding another 16k CUs of overhead. Now your total cost jumps to 22k CUs. This higher total CU cost dilutes your effective priority fee per CU, potentially lowering your transaction’s priority. 

Block Packing Decisions

During block packing, leaders use transaction cost to determine which transactions fit in a block. Given the CU limit, leaders maximize yield by prioritizing transactions with the highest reward-to-cost ratio, maximizing yield per CU.

Block Packing Priority = Reward / Transaction Cost
Reward = Priority Fee + (Transaction Fee - burn)  *By default 50% of transaction fee is rewarded to validators

Solana Transaction Cost Breakdown

Under the hood, a transaction’s cost in Solana consists of five main components, all converted to CU for unified measurement:

1. Executions CUs (Program Execution Cost)

   This represents the compute budget you set If your program exhausts this budget during execution, it fails immediately. This is modifiable with setComputeUnitLimit

   
   

2. Loaded Account Data Cost

   Every transaction defaults to loading 64MB of account data, consuming 8CU per 32KB loaded. This translates to a default limit of 16k CU even if your transaction doesn't load that much data. This is modifiable with setLoadedAccountsDataSizeLimit.

   
   

3. Write Lock Cost

   This reflects the cost of acquiring write locks on accounts your transaction modifies. Each write lock incurs a fixed 300 CU cost. 

   
   

4. Signature Cost

   Each signature in your transaction incurs a fixed 720 CU cost for cryptographic verification.

   
   

5. Data bytes cost

   The size of the transaction itself adds to the cost. Large transactions with more instructions or large input data use more bandwidth and memory so they have a higher CU cost.

Developer Recommendations

1. Set Specific Compute Limits

   Don’t rely on defaults. Simulate your transaction and add a 10% buffer to set an appropriate unit limit.

   
   

2. Optimize Account Data Size

   Use setLoadedAccountsDataSizeLimit to request the account data size you need, not only for improving priority but also safeguard against future transaction rejections as CU block limits increase.

   
   

3. Monitor Transaction Costs

   Use RPC method getBlock() and check the transactions array metadata for CUs consumed and transaction cost. This helps you profile and optimize your applications.

   
   

4. Understand the Trade-offs

   Higher transaction costs means lower priority for the same fee, but also ensure your transaction has sufficient resources to execute successfully.

Conclusion

In summary, compute units are the fundamental metric of computation on Solana and transaction cost is the total measured weight in CUs for processing a transaction. Transaction fee is what you pay in lamports (SOL) mostly independent of how many CUs you used, unless you add priority fees. Developers should optimize programs to use fewer CUs and be mindful of overhead like account data loading and unnecessary compute budget headroom. As Solana scales to higher TPS and larger blocks, optimizing these factors becomes increasingly important. In turn, your transactions will execute more efficiently and have a better chance of being prioritized as the network continues to scale.