The Truth About Solana’s Local Fee Market

Actionable Insights

• Local Fee Markets (LFMs) enable Solana to set fine-grained fees for individual states based on how competitive the state is. Transactions pay fees based on the specific state they write to, preventing local hotspots from driving up fees across the entire blockchain.

• LFMs are critical to achieving Solana’s vision of a scalable, unified base layer where all applications coexist seamlessly. Without LFMs, a surge in fees on one part of the chain would cause fees to increase for all transactions — a common problem with other networks that rely solely on a global fee market for block space pricing.

• As Solana economic activity accelerated towards the end of 2023, several key flaws in the original implementation of LFMs became apparent. The most notable is the non-deterministic scheduler priority. Transactions are ordered primarily based on the time they arrived at the block builders, with priority fees being only a secondary consideration.

• In the May 2024 Agave client update v1.18, a new transaction scheduler and an improved transaction priority formula were introduced. The scheduler builds a dependency graph to better manage the processing and priority of conflicting transactions across threads. This major update significantly improves the protocol’s ability to order transactions in a deterministic manner.

• A valuable metric for evaluating effectively functioning LFMs is to compare median and average transaction priority fees. Fees involving uncontested status (50th percentile median) are expected to remain low. Fees for disputed states should surge as demand increases, driving up the average fee. Recent data confirm this pattern. In November 2024, the average fee for non-voting transactions reached an all-time high of over 0.0003 SOL. However, the median fee remained at 0.00000861 SOL, which is about 35 times lower.

• Today, Solana’s LFMs are functional, but there is still significant room for improvement. Anza engineers’ analysis of the banking phase thread workload showed that scheduler errors prevented validator clients from utilizing their full capabilities. Therefore, the Agave client operates at only a fraction of its potential. Furthermore, there is no formal specification on how transactions should be ordered.

• Current priority fee APIs lack the sophistication required to provide deterministic results. Each major RPC provider offers its own custom priority fee API, which can lead to a kind of soft vendor lock-in. The core open source RPC API implementation did not take into account key network dynamics, such as the impact of Jito, resulting in inaccurate fee estimates.

• In the absence of a deterministic way to calculate priority fees, developers often take a cautious approach by overpaying to ensure their transactions are processed. Alternatively, they may overuse Jito tips as an alternative mechanism even for transactions that are not required to secure the top of a block.

• Various strategies have been proposed to further enhance Solana’s fee structure. These include index write lock fees and dynamic base fees. The network has not yet found a way to exert economic counter-pressure to disincentivize spam while keeping fees low for real users.

Introduction

The fee market is an economic mechanism that aims to efficiently allocate scarce block space to the highest value transactions by dynamically adjusting transaction fees. The fee a transaction is willing to pay is a proxy for its value. LFMs refine this general concept by setting fine-grained fees for individual states based on how competitive the state is. When two transactions access the same state (either two write operations or reads and writes to the same account), they are considered to be in dispute.

With LFMs, transactions pay fees based on the specific state they write to, preventing local hotspots from driving up fees across the entire blockchain. Transactions accessing high-demand or controversial states incur higher fees, while transactions interacting with lower-demand states pay lower fees. This is important because Solana is better at processing undisputed transactions because it supports parallel execution.

In contrast, the global fee market imposes a universal cost on accessing the network state, meaning that all transactions compete equally for inclusion in a block regardless of which account they interact with. Ethereum’s fee model, implemented in EIP-1559 , is a relevant example of a global fee market. EIP-1559 adjusts the dynamic base fee based on network demand to maintain optimal computation (gas) usage with each block. As blocks fill up, the fees for all transactions increase. The wallet calculates the fee based on the current base fee and the gas limit of the transaction. This approach is enforced in the protocol and provides predictable fee calculations; however, it fails to isolate high-demand hotspots from the broader network. When fees surge, fees on all transactions surge.

The problem of high demand for specific states is not unique to blockchain. This challenge is similar to the hot key problem, often referred to as the "celebrity problem", which is common in Web2 social applications.

Through this article, we aim to provide an accessible analysis of Solana LFMs. The work is divided into the following sections:

• Solana Fee Basics: To establish for the reader a basic understanding of how transactions are currently processed on Solana.

• Early Problems with Local Fee Markets: Explores initial problems and flaws in early implementations of LFMs.

• Central Scheduler v.1.18 Update: Highlights a major update in 2024 that significantly improves the functionality of LFMs.

• Measuring the Effectiveness of Local Fee Markets: Providing data relevant to understanding the state of LFMs on Solana.

• Continuing Issues and Areas for Improvement: This section discusses unresolved issues and areas that require attention in order for LFMs to achieve their full potential.

• Proposed Solutions: Review proposed solutions to refine LFMs and introduce better economic incentives for more nuanced blockspace pricing.

Readers already familiar with Solana’s transaction fee structure may wish to skip the following section on fee basics.

Solana Fee Basics

Solana transactions consist of two fees - the base fee and the priority fee. The base fee is currently fixed at 5,000 lamports per signature. Most Solana transactions have only one signature. Priority fees are measured in microlamports (i.e. one millionth of a lamport) and are calculated per requested compute unit (CU). The fee is debited from the account of the person who paid the fee (the signatory). If the payer's lamports are not enough to cover the transaction fee, the transaction will be discarded. At the time of writing, 50% of the base fee and priority fee are retained by block builders as an incentive for including transactions in blocks. The remaining 50% was destroyed. Following a successful governance vote last May, proposal SIMD-096 would change this to 100% of the priority fee being retained by block builders . For example:

A transaction has one signature and requests 500,000 CUs. The sender sets a priority fee of 50,000 micro-Baud per CU requested. The total fee for this transaction is 5,000 Landports + (500,000 requested CUs * 50,000 micro Landports per requested CU) = 25,000 Landports, or 0.000025 SOL.

The validator's computing resources are limited, and the protocol limits the total computing resources for each block to 48 million CUs. This number was chosen empirically based on the volume that validators can reasonably handle to achieve a 400ms block time. The maximum CUs per block per account is limited to 12 million, while the maximum computation limit per transaction is set at 1.4 million CUs. The size of transaction messages is also limited to a maximum of 1,232 bytes, which is the minimum transmission unit of IPv6 (1280 bytes) minus the header.

To prevent the abuse of computing resources, Solana allocates a computing budget for each transaction. By default, the network sets a maximum limit of 200,000 compute units (CU) per instruction. However, transactions can specify a custom compute unit limit by including the SetComputeUnitLimit directive, allowing for more efficient resource allocation. The Agave client repository lists the CU costs of various operations.

Solana requires that all transactions must specify a complete list of account addresses that will be read or written during the transaction. The maximum size of this list is 35 addresses, and can be expanded via an on-chain address lookup table. Building the address list introduces additional overhead for developers, but is key to unlocking many of Solana’s optimizations, including parallel transaction execution and localized fee markets.

Early Problems with Solana’s Native Fee Market

“The local fee market is a lie.”  - Ben Coverston, Co-founder, Temporal

As economic activity on Solana accelerated towards the end of 2023, several key flaws in the original LFMs implementation became apparent. At this time, Eugene Chen of Ellipsis Labs provides a comprehensive analysis of these challenges in the Umbra Research article, Solana Fees, Part 1. Here is a summary of the key points Chen made.

Lack of incentives to accurately request CUs

Solana’s fee structure charges a base fee per signature, regardless of the number of computational units (CUs) used or requested. At the same time, priority charges provide only limited incentives to reduce CU usage during congestion periods. This design leaves transaction senders with little incentive to optimize compute usage or match their CU requests with actual demand. As a result, transactions often over-request CUs, leading to inefficiencies in the network scheduling process.

Incentives to use extra-protocol priority mechanisms

Burning 50% of the priority fee incentivizes transaction senders to bypass the protocol by colluding with block builders and arranging off-chain payments to gain priority access. This behavior is evident in the growing presence of Jito auctions. Validators running the Jito-Agave client benefit from higher fee income and can efficiently distribute these profits to delegated stakers through Jito MEV commission rewards. As the adoption of Jito-Agave clients increases, Jito packages prove to be a superior transaction delivery service in many scenarios.

Non-deterministic Scheduler Priorities

Neither Solana’s consensus nor its scheduler enforce strict transaction ordering based on priority fees. Transactions are ordered primarily by the time they arrived at the block builders, with priority fees being only a secondary consideration. Higher priority fees can increase the likelihood of being included in a disputed state, but the sorting process is still non-deterministic. Network jitter before reaching the transaction processing unit (TPU) and jitter within the scheduler further increase the unpredictability.

This lack of certainty reduces the predictability and reliability of transaction execution, incentivizing users to flood the network with transaction spam to improve the chances of faster inclusion. However, increasing priority fees has diminishing returns after a certain threshold, undermining its effectiveness as a mechanism for better trade placement. Solana’s shared blockspace ultimately fell victim to the classic “tragedy of the commons.” Individual actors, motivated by their own interests, have led to overutilization and inefficiency of this public resource.

Central Scheduler v1.18 Update

The initial implementation of the Agave client scheduler only provided a loose guarantee that transactions with high priority fees had a greater chance of being included in a particular block. The leader’s transaction processing unit (TPU) runs with six parallel threads: four processing non-voting transactions and two reserved for voting transactions. Each non-voting transaction thread maintains its own queue where pending transactions are grouped for execution. Previously, transactions were randomly assigned to these threads, and the queues independently prioritized packets without regard to packets processed by other threads.

In this system, each thread loops its queue, trying to lock and execute transactions. Once the thread completes the current loop, it collects additional packets and starts the process over again. This structure creates challenges for the effective use of priority fees. For example, while a high priority transaction may be at the top of one thread's queue, another thread may be simultaneously processing a low priority fee transaction involving the same account that is at the end of its queue. Priority fees affect transaction ordering only within a single thread (intra-thread), not across all threads (inter-thread). Therefore, each queue applies a hybrid sorting mechanism that combines first-in-first-out (FIFO) processing with priority cost considerations. However, no global ordering is enforced between threads.

When a thread is ready to execute a transaction, it must first acquire the required account lock. If the required write lock is not available, the transaction will be requeued. This problem is exacerbated by the random assignment of transactions to threads, since the same transaction type may end up at different positions in a multithreaded scheduling system. The randomness of this scheduler introduces jitter, causing variability in where transactions are placed in blocks.

A new transaction scheduler, the Central Scheduler, was introduced in May 2024 with the Agave client update v1.18. In this revised structure, the central scheduler builds a dependency graph, called a precedence graph, to better manage the processing and priority of conflicting transactions across all threads. This major update significantly improves Solana’s ability to deterministically order transactions; transactions with higher priority fees are more likely to be included in a block.

The priority graph is a directed acyclic graph (DAG) that is dynamically updated as new transactions are added. Transactions are organized in the graph into execution chains that are processed in chronological priority order. For conflicting transactions, the priority fee determines the insertion order. This approach minimizes lock contention, allowing transaction batches to execute smoothly and reducing delays caused by resource conflicts. Transaction precompile validation has been offloaded to a worker thread to improve performance and enable more efficient processing.

The updated scheduler design significantly enhances scalability and flexibility, allowing the potential increase in the number of threads without increasing the risk of lock conflicts. Additionally, the centralized scheduling approach improves reward generation, increasing profitability for many validator operators.

For more detailed information on the central scheduler, readers are referred to our previous Helius blog post covering the Agave 1.18 update .

More efficient priority calculation

Along with the scheduler update, the transaction priority formula has been improved to give advantages to transactions with lower computational requirements, benefiting developers and transactions with the least resource usage. : : : : : : : : : : : : : : :

Since there is no deterministic way to calculate priority fees, developers often take a cautious approach by overpaying to ensure their transactions are processed. Alternatively, they may overuse Jito tips even on transactions that are not required to secure the top of the block. These tips are often used as an alternative to priority fees. Notably, most of the tips observed in 2024 were not related to traditional MEV activities such as arbitrage or pinch-hitting, but were instead aimed at enabling faster transaction inclusion. Validators gain this inefficiency by charging higher block rewards and MEV commissions.

Another challenge arises when developers fail to implement logic to dynamically adjust their priority fees in response to fluctuating on-chain conditions. During major events, such as large market fluctuations, the fees to access a specific state account can skyrocket. Applications that lack a dynamic fee mechanism will face difficulties in these situations because their static fee settings will not be sufficient to ensure timely execution.

Proposed Solutions

Various strategies have been proposed to further enhance Solana’s fee structure. These proposals aim to optimize the allocation of network resources and mitigate the incentives for spam.

Exponential Write Lock Fees

SIMD-0110, proposed by Tao Zhu (Anza) and Anatoly Yakavenko in January 2023, proposes a new mechanism for managing congestion by imposing dynamic fees on disputed accounts. This mechanism tracks the exponential moving average (EMA) of compute unit (CU) utilization of write-locked accounts and increases the fee for write-locked accounts with persistently high utilization.

To implement such a system, the Solana runtime maintains an LRU (least recently used) cache of the public keys of disputed accounts and their corresponding compute unit pricers (CUPs). CUP monitors the account's EMA CU utilization and provides updated charge rates when queried.

This mechanism dynamically adjusts the write lock fee. If the account's EMA CU utilization exceeds the target threshold, the write lock charge rate increases. Conversely, if utilization is below target, the expense ratio decreases. Initial parameters include:

• A target utilization of 25% of the account's maximum CU limit.

• The initial write lock fee rate is 1,000 microlabors per CU.

• The fee adjustment rate for each block is 1%.

An account's write lock fee is calculated by multiplying its fee rate by the CU requested by the transaction. Under this system, the total transaction fee is the sum of three components: the base signing fee, the priority fee, and the write lock fee. Write lock fees will be 100% destroyed.

When released, SIMD-0110 sparked heated discussions within the community. However, the proposal is currently inactive and marked as closed.

Dynamic Base Fee

Another long-term solution to improve Solana’s LFM is to introduce a global and per-account Dynamic Base Fee (DBF). Jarry Xiao and Eugene Chen of Ellipsis Labs are notable proponents of this approach.

While the priority fee is optional, the basic fee is mandatory. Currently, Solana’s base fee is fixed at 5,000 LPS per signature. A user submitting a simple token transfer pays the same base fee as a searcher doing a complex multi-venue swap or attempting to perform complex MEV arbitrage. The base fee does not accurately reflect the computational usage of the transaction.

With dynamic base fees, arbitrage transactions with inappropriate base fees can be considered invalid and discarded before reaching the scheduler. Increasing the base fee would encourage spammers to send fewer transactions.

The base fee will eventually reach equilibrium and transactions will be priced according to the value of the block space market. As the base fee rises, it will eventually reach a marginal cost where sending a transaction is no longer worth the opportunity cost of the transaction. Fees cannot be too high; otherwise, user activity will be affected. A maximum value that is too high for a robot but generally acceptable to users is ideal. Under such a system, accounts sending transactions for inclusion would burn all of their SOL.

Solana’s fast block times enable aggressive algorithms to set base fees. During periods of high demand, fees can adjust rapidly — perhaps doubling every block — to reflect network congestion. Instead, fees can be reduced more gradually as demand decreases. Due to Solana’s short block times, fee reductions are still relatively rapid, ensuring the network quickly adapts to changing conditions.

A similar example of economic counter-pressure is the Metaplex Candy Machine program , which implemented a bot tax in 2022 as an anti-spam mechanism. The robot tax is an optional charge on invalid transactions. Typically this will be a relatively small amount to avoid affecting genuine users who may have made a genuine mistake. This tax proved effective; the minting snipers were quickly depleted and the spamming ceased.

Conclusion

Solana’s LFM is functional, but there is still a lot of room for improvement:

• Enhancing the priority fee mechanism: The priority fee RPC call needs improvement. Ideally, developers would have an easy, deterministic way to set fees that would ensure a transaction is included within the next few blocks.

• Economically disincentivize spam: Networks must find ways to exert economic counter-pressure on bots during periods of high economic activity, while keeping fees low for real human users.

• Educate developers: Developers need to stop setting static application transaction fees and reduce reliance on off-protocol mechanisms like Jito for regular transactions.

• Further optimize the scheduler: The transaction scheduler needs further optimization to ensure that all worker threads are utilized during high demand periods.

As Solana co-founder Anatoly Yakovenko points out, these challenges are primarily “engineering problems” — solvable with the proper technical focus.

其他资源

• Solana Fees, Part 1 - Umbra Research

• Toward Multidimensional Solana Fees - Umbra Research

• Local Fee Markets are Necessary to Scale Ethereum - Eclipse Labs

• Solana's Local Fee Markets Aren't Real | Eugene Chen - Lightspeed Podcast

• Solana Banking Stage and Scheduler - A.Fitzgerald