Solana's Fixed Transaction Fee Remains 0.000005 SOL, Despite Potential Inefficiencies

Solana, a blockchain known for its high-throughput and fast transaction processing, has a unique fee structure that sets it apart from other networks. The transaction lifecycle in Solana begins with a user signing a transaction in their wallet or interface, which is then sent to a Solana RPC server. These servers act as entry points, verifying the leader schedule and forwarding it to the current leader. The leader is responsible for validating and organizing signed transactions within its designated slot before execution. Solana validators use a block-building algorithm called Prio-Graph, which prioritizes transactions based on priority fees and vote transactions. The RPC server establishes a fast and secure connection to the leader node’s Transaction Processing Unit (TPU) using Quick UDP Internet Connections (QUIC). The TPU processes transactions in multiple stages: SigVerify strategy, Banking stage, and Broadcast stage. Solana has no mempool and instead uses gulfstream, meaning transactions are locally ordered in each thread’s queue. Transactions specify which state must be read-locked and write-locked, and those unable to obtain the required locks are re-queued. Validators synchronize their states inside Solana clusters to maintain a consistent ledger. A block is deemed complete when 31 or more verified blocks have been constructed onto it.

Solana’s transaction fees are designed to be low-cost and fast. Each signed transaction on Solana incurs a fixed transaction fee of 0.000005 SOL, regardless of the transaction amount. This static fee model contributes to Solana’s high-throughput and cost-efficient architecture, allowing thousands of users to perform bundles of transactions without incurring heavy transaction fee costs. Unlike other blockchains, where network congestion or transaction complexity can lead to high fees, Solana’s fixed fee structure ensures that users experience low-cost and fast transaction speeds. However, this fixed transaction 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.

Compute units (CU) in Solana measure the computational resources needed for a transaction to be executed. Each transaction is deducted from the compute unit budget, with a maximum limit of 1.4 million compute units and a default limit of 200,000 compute units per instruction. Solana’s transaction fees are based on compute units, meaning that transactions using 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.

Ask Aime: How does Solana's unique fee structure and transaction lifecycle impact its scalability and cost-effectiveness in the blockchain industry?

Solana’s fee system is composed of two types: base fees and priority fees. Base fees are fixed at 0.0000005 SOL per transaction and are paid upfront without regard for the amount of compute units needed. These fees are split 50/50, with 50% burned to reduce supply and 50% rewarded to the validator who processed the transaction. Priority fees, on the other hand, are optional additional fees paid by users to validators to increase the probability of their transaction being processed and included in the block. These fees are non-deterministic and do not guarantee inclusion in the block due to factors like block space limits, high-competing bids, compute unit constraints, and leader behaviors. The incentives for validators to accept priority fees exist outside the Solana runtime, which is only responsible for enforcing transaction execution rules.

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. 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.

Solana’s base fee has a fixed transaction fee of 0.000005 SOL (5,000 lamports) per transaction, independent of the resources used to execute the transaction. Users can add optional priority fees to improve their inclusion probability. Priority fees are priced per CU requested for a transaction. Transactions can set the maximum amount of CUs they are allowed to consume, with a max of 1.4M CUs per transaction. If no SetComputeUnitLimit instruction is provided, the transaction’s CU limit is calculated as the number of instructions in the transaction multiplied by 200k CUs. The priority fee on Solana is determined by the amount of compute units a transaction requests and the price the user is willing to pay per CU.

Despite its advantages, Solana’s transaction fee mechanism has potential shortcomings. The base fees do not account for the use of compute units, leading to overestimation and inefficiency in compute unit usage. Additionally, vote transaction fees are paid by validators, creating an unfair system where vote transactions are sometimes overcharged relative to the amount of compute units consumed. This centralizing economic effect occurs because the total voting constant is fixed for all validators, while the rewards earned are proportional to the stake. These shortcomings highlight the need for further improvements in Solana’s fee market to ensure fairness and efficiency.