Solana’s Transaction Fees Are Insanely Cheap—But Here’s the Catch

In this article, we aim to map out the fee landscape surrounding Solana, providing a solid foundation for understanding how the fee mechanism and market in Solana operate.

Recap: Transaction Lifecycle in Solana

A transaction is the transmission of data across the blockchain. In blockchain networks, transaction fees are a key piece in maintaining network security, incentivizing validators to process transactions swiftly, and preventing spam. Solana, a popular blockchain known for its high-throughput and fast transaction processing speed fueled by its parallel execution and local market mechanism, and a record of having a transaction speed of 300 milliseconds.

A simple Solana transaction could be a trade on a DeFi protocol, an NFT mint, or a token transfer that happens on the Solana blockchain, which forces users to pay a certain fee for each successful transaction. On Solana, transactions tend to be fast and happen instantaneously. The transaction lifecycle in Solana can be summarized as follows:

1. Immediately after the user signs the transaction in their wallet, dApp, or any interface, the signed transaction is sent to a Solana RPC server.
2. RPC servers act as entry points for transactions; after verifying the leader schedule, forward the leader schedule to the current one.
3. The leader is responsible for validating and organizing signed transactions within its designated slot before execution.
4. Solana validators use a block-building algorithm called Prio-Graph, which prioritizes transactions based on priority fees and vote transactions.
5. The RPC server establishes a fast and secure connection to the leader node’s Transaction Processing Unit (TPU) using Quick UDP Internet Connections (QUIC).
6. The TPU processes transactions in multiple stages: SigVerify strategy, Banking stage, and Broadcast stage.
7. Solana has no mempool and instead uses Gulfstream, meaning transactions are locally ordered in each thread’s queue.
8. Transactions specify which state must be read-locked and write-locked, and those unable to obtain the required locks are re-queued.
9. Validators synchronize their states inside Solana clusters to maintain a consistent ledger.
10. A block is deemed complete when 31 or more verified blocks have been constructed onto it.

For a deeper dive into the Solana Transaction Lifecycle, check out my previous article here.

In each signed transaction on Solana, be it $1 to $100, a fixed transaction fee of 0.000005 SOL is incurred. This means that users experience low-cost and fast transaction fees and speed, respectively, compared to other blockchains like Ethereum.

This design of a static fee model in Solana contributes to its high-throughput and cos-efficient architecture, allowing thousands of users to perform bundles of transactions without incurring heavy transaction fee costs. This is unlike other blockchains, where certain scenarios like network congestion or transaction complexity can contribute to heavy transaction fees.

However, this fixed transaction (base fee) is just a fraction of Solana’s fee structure. Solana also has priority fees that determine the order of transactions in a leader queue; these kinds of fees are optional and depend on whether the user wants a faster transaction processing speed. The next section will go over in detail the types of fees in Solana.

A Brief Overview of Compute Units

Compute units (CU) in Solana measure are the computational resources needed for a transaction to be executed. In Solana, each transaction is deducted from the compute unit budget:

• Maximum Limit: A transaction can use up to 1.4 million compute units.
• Default Limit: By default, each instruction is limited to 200,000 compute units.
• Custom Limit: You can request a specific compute unit limit by including a SetComputeUnitLimit instruction in your transaction.

Solana's transaction fees are based on compute units. This means that transactions that use more computational resources will incur higher fees. However, vote transactions are sometimes overcharged compared to their actual CU usage, leading to inefficiencies and centralization risks.

Types of Fees in Solana

Solana fee system is made up of two kinds: Base fees and Priority fees.

Base Fee

Solana transactions have a fixed base fee of 0.0000005 SOL. These base fees are paid by users not relative to any kind of transactions being made on the network, and it gives users the right to write to program accounts. The fee payer must be an account owned by the system program. These fees are paid upfront without regard for the amount of compute units needed to ensure the transaction is added to the block, which makes the transaction fee independent of resources used. Transactions in Solana require a certain amount of compute units (200,000 CU) for each transaction, and if this number is exceeded, the transaction fails and can only be successful if the user decides to pay extra fees (priority fees).

Solana's base transaction fee is split 50/50, with 50% burned to reduce supply and 50% rewarded to the validator who processed the transaction.

Priority Fee

Priority Fee on Solana is an optional additional fee paid by users to validators to increase the probability of their transaction being processed and inclusion into the block. This is non-deterministic as it does not guarantee inclusion in the block due to scenarios like block space limits, high-competiting bids, compute unit constraints, and leader behaviors. The incentives for validators to accept priority fees to include transactions in the block exist outside the Solana runtime (the Solana runtime is only responsible for enforcing transaction execution rules).

The Priority fee Indeterminism for transactions with higher fees is based on the Solana scheduler. The Solana scheduler operates with four execution cores, while two additional cores are reserved for vote transactions. Each thread maintains its queue, processing transactions independently without awareness of other threads’ operations. Threads cycle through their queues, locking and executing transactions before collecting new ones. Due to this design, a high-priority transaction in one thread may compete with a lower-priority transaction in another thread if both involve the same account, leading to unpredictable execution ordering.

Source: Fees in Theory and Practice (Helius)

Note: Vote transactions do not have an associated priority fee and are treated differently than standard transactions. The fee is a fixed fee of 0.9 SOL per day, which is paid by validators.

Fee Calculations in Solana?

Recall: The Solana base fee has a fixed transaction fee of 0.000005 SOL (5,000 lamports) per transaction. It is independent of the resources used to execute the transaction.

Solana Tx Base Fee  =  (5,000 Lamports)  x  (# of Signatures in Tx)

More so, Solana users can add optional priority fees to improve their inclusion probability. Priority fees are priced per CU requested for a transaction. To understand how it is calculated, Solana transactions have the following Compute Budget instructions:

• SetComputeUnitLimit: Transactions can set the maximum amount of CUs that they are allowed to consume (with a max of 1.4M CUs per transaction). When executed, the transaction can be used up to that requested CU limit. If no SetComputeUnitLimit instruction is provided, the transaction’s CU limit is calculated as (# of instructions in the transaction) x (200k CUs).

• SetComputeUnitPrice: # of micro-lamports per CU requested that the transaction offer pay in its priority fee.

This means that the priority fee on Solana is determined by the amount of compute units (CUs) a transaction requests and the price the user is willing to pay per CU.

Tx Priority Fee = (Tx CU Limit)  x  (CU Price)

Shortcomings of Solana Transaction Fee Mechanism (TFM)

The potential shortcomings of Solana Transaction Fee Mechanism are:

Poor CU Usage

Solana base fees do not account for the use of compute units and lead to the overestimation of compute units needed for a given block and a loss in efficiency in the usage of compute units. This is a shortcoming for Solana TFM, as base fees do not incentivize transactions to use and request compute units effectively.

Absence of Privileged Transactions

Vote transaction fees in Solana are fees that must be paid by validators (privately) as they are included in the block. This creates an unfair system for validators, as sometimes vote transactions are overcharged relative to the amount of compute units consumed. This creates a centralizing economic effect as the total voting constant is fixed for all validators, while the rewards earned are proportional to the stake.

This list is not an exhaustive list of the shortcomings of Solans’s TFM rather focused on those related to the Solana fee market. To further understand the shortcomings of Solana TFM, check Solana & Ethereum Transaction Fee Mechanism by Eclipse.

Wrapping Up

In this report, we explored the Solana transaction lifecycle, examined its fee market, and discussed the shortcomings of the Solana transaction fee mechanism.