The Truth about Solana Local Fee Markets

‍

‍

Many thanks to Eugene Chen and 0xIchigo for reviewing earlier versions of this work.

Actionable Insights

• Local Fee Markets (LFMs) enable Solana to set granular fees for individual pieces of state based on their level of contention. Transactions pay fees based on the specific state they write to, preventing localized hotspots from raising fees across the entire blockchain. 
• LFMs are essential for achieving Solana’s vision of a scalable unified base layer where all applications coexist seamlessly. Without LFMs, fee spikes in one part of the chain lead to increased fees for all transactions—a problem commonly observed in other networks that depend solely on global fee markets for blockspace pricing.
• As economic activity on Solana began to accelerate in late 2023, several critical flaws in the original implementation of LFMs became evident. The most notable being non-deterministic scheduler prioritization. Transactions were primarily ordered by arrival time at the block builder, with priority fees serving only as a secondary consideration.
• With Agave client update v1.18 in May 2024, a new transaction scheduler and a refined transaction priority formula were introduced. The scheduler builds a dependency graph to better manage the processing and prioritization of conflicting transactions across threads. This major update significantly improved the protocol’s ability to order transactions deterministically.
• A valuable metric for evaluating effectively functioning LFMs is the comparison of median and average transaction priority fees. Fees involving uncontested state (50% percentile median) are expected to remain low. Fees for contested state should surge as demand increases dragging up the average. Recent data confirms this pattern. In November 2024, the average fees for non-vote transactions reached an all-time high of over 0.0003 SOL. However, median fees remained steady at 0.00000861 SOL, approximately 35x lower.
• Today, Solana's LFMs are functional, but significant room for improvement exists. LFMs still struggle to function deterministically under high load. Issues lie in bottlenecks within the sub-optimal transaction processing pipeline. Once queues fill up under high loads, prioritization issues still arise. Transactions cannot be reordered until they reach the scheduler, disrupting the LFM mechanism. Moreover, there is no formal specification for how transactions should be ordered.
• The current priority fee APIs lack the sophistication needed to deliver deterministic results to developers. Each major RPC provider offers its own custom priority fee API, which could become a soft form of vendor lock-in. The core open-source RPC API implementation fails to consider critical network dynamics, such as Jito’s influence, leading to inaccurate fee estimations.
• Without a deterministic method for calculating priority fees, developers often take a cautious approach by overpaying to guarantee their transactions are processed. Alternatively, they may overuse Jito tips as an alternative mechanism, even for transactions where securing the top-of-block is unnecessary.
• Various strategies have been proposed to further enhance Solana's fee structure. These include exponential write lock fees and dynamic base fees. The network has yet to figure out ways to apply economic backpressure to disincentive spam while maintaining low fees for genuine human users.

Introduction

Fee markets are economic mechanisms designed to efficiently allocate scarce blockspace to the highest-value transactions through dynamic adjustment of transaction fees. A transaction's willingness to pay fees being a proxy for its value. LFMs refine this general concept by setting granular fees for individual pieces of state based on their level of contention. Two transactions are considered contentious when accessing the same state—either two writes or a read-and-write to the same account.

‍

With LFMs, transactions pay fees based on the specific state they write to, preventing localized hotspots from raising fees across the entire blockchain. Transactions accessing high-demand or contentious states incur higher fees, while those interacting with less in-demand state pay lower fees. This is important because Solana handles noncontending transactions better due to parallel execution.

‍

‍

Global fee markets, by comparison, apply a universal cost to access network state, meaning all transactions compete equally for inclusion regardless of the accounts they interact with. Ethereum’s fee model, implemented in EIP-1559, is a pertinent example of global fee markets. EIP-1559 adjusts a dynamic base fee based on network demand to maintain optimal compute (gas) usage per block. As block capacity fills, fees increase for all transactions. Wallets calculate fees based on the current base fee and the transaction’s gas limit. This approach is enforced in protocol and offers predictable fee calculations; however, it fails to isolate high-demand hotspots from the broader network. When fees spike, they do so for all transactions.

The issue of high demand for specific pieces of state is not exclusive to blockchains. This challenge mirrors the hotspot key problem, often called the "celebrity problem," commonly encountered in Web2 social applications.

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

‍

• Solana Fee Basics: Establishes a baseline understanding for readers on how transactions are processed on Solana today.
• Early Issues with Local Fee Markets: Explores the initial issues with early implementations of LFMs and their shortcomings.
• The Central Scheduler v.1.18 Update: Highlights a pivotal 2024 update that significantly improved the functionality of LFMs.
• Measuring Local Fee Market Effectiveness: Provides data relevant to understanding the state of LFMs as they operate on Solana today.
• Ongoing Issues and Areas for Improvement: This section discusses unresolved issues and areas that require attention for LFMs to achieve their full potential.
• Proposed Solutions: Reviews proposed solutions to refine LFMs and introduce better economic incentives for more nuanced blockspace pricing.

‍

Readers already acquainted with Solana's transaction fee structures 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 one signature. The priority fee is denominated in microlamports (i.e., a millionth of a lamport) per requested compute unit (CU). Fees are debited from the fee-payer account (the signer). The transaction is dropped if the payer has insufficient lamports to pay for the transaction. At the time of writing, 50% of both the base fee and priority fee is kept by the block builder as an incentive to include the transaction in the block. The other 50% is burned. Following the successful governance vote on proposal SIMD-096 in May of last year, this will change to 100% of priority fees being kept by the block builder. For example: 

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

‍

Validators have finite computational resources, and the protocol limits the total computational resources per block to 48 million CUs. This number was chosen empirically based on how much validators can reasonably process to arrive at 400 millisecond block times. The maximum CUs per account per block is limited to 12 million, and the maximum compute per transaction is set at 1.4 million CUs. Transaction messages are also limited to a maximum of 1,232 bytes in size, which is the minimum transmission unit of IPv6 (1280 bytes) minus headers. 

‍

To prevent the misuse of computational resources, each transaction on Solana is assigned a compute budget. 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 a `SetComputeUnitLimit` instruction, allowing more efficient resource allocation. The Agave client code base lists CU costs for various operations.

‍

Solana requires all transactions to specify a complete list of account addresses that will be read from or written to during the transaction. The maximum size of this list is 35 addresses, which can be extended through on-chain Address Lookup Tables. Building address lists creates additional overhead for developers but is the key to unlocking many of Solana’s optimizations, including parallel transaction execution and localized fee markets.

‍

Early Issues with Solana’s Local Fee Markets

“Local fee markets are a lie.” 

- Dec 2023, Ben Coverston, Temporal, Solana Tech Discord

‍

As economic activity on Solana began to accelerate in late 2023, several critical flaws in the original implementation of LFMs became evident. Around this time, Eugene Chen of Ellipsis Labs provided a comprehensive analysis of these challenges in the Umbra Research article, Solana Fees, Part 1. Below is a summary of the key points raised by Chen.

Lack of Incentives to Accurately Request CUs

Solana’s fee structure charges base fees per signature without considering the compute units (CUs) used or requested. Meanwhile, priority fees provide only a limited incentive to reduce CU usage during periods of congestion. This design leaves transaction senders with little motivation to optimize compute usage or match their CU requests to actual needs. Consequently, transactions frequently over-request CUs, creating inefficiencies in the network's scheduling process.

Incentives to Use Out-of-Protocol Priority Mechanisms

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

Non-deterministic Scheduler Prioritization

Neither Solana’s consensus nor the scheduler enforces strict transaction ordering based on priority fees. Transactions are primarily ordered by arrival time at the block builder, with priority fees serving only as a secondary consideration. Higher priority fees can increase the likelihood of inclusion with contested states, but the ordering process remains non-deterministic. Network jitter before reaching the transaction processing unit (TPU) and internal jitter within the scheduler introduce further unpredictability.

‍

This lack of determinism reduces the predictability and reliability of transaction execution, driving users to flood the network with transaction spam to improve their chances of faster inclusion. However, raising priority fees offers diminishing returns beyond a certain threshold, undermining their effectiveness as a mechanism for better transaction placement. Solana's shared blockspace has ultimately fallen victim to a classic "tragedy of the commons." Individual actors, acting in their own self-interest, have contributed to the overutilization and inefficiency of this public resource.

The Central Scheduler v.1.18 Update

The initial implementation of the Agave client scheduler provided only a loose guarantee that transactions with high-priority fees would have a better chance of being included in a given block. The leader’s Transaction Processing Unit (TPU) operates using six parallel threads: four handle non-vote transactions, with two reserved for vote transactions. Each of the four non-vote transaction threads maintains its own queue, where incoming transactions await grouping into entries for execution. Previously, transactions were randomly assigned to these threads, and the queues prioritized packets independently without awareness of the packets processed by other threads.

‍

‍

Within this system, each thread cycles through its queue, attempting to lock and execute transactions. Once a thread completes its current cycle, it collects additional packets and starts the process again. This structure introduces challenges for the effective use of priority fees. For instance, while a high-priority transaction might be at the top of one thread’s queue, a different thread could simultaneously process a lower priority fee transaction involving the same account from the end of its queue. Priority fees influenced transaction ordering only within individual threads (intra-thread), not across all threads (inter-thread). As a result, each queue applied a hybrid ordering mechanism that blends first-in-first-out (FIFO) processing with priority fee considerations. However, no global ordering was enforced across threads.

‍

When a thread prepares to execute a transaction, it must first secure the required account locks. If the necessary write locks are unavailable, the transaction is re-queued. The random assignment of transactions to threads compounds this issue, as the same transaction type could end up in varying positions within the multi-threaded scheduling system. This stochastic nature of the scheduler introduces jitter, creating variability in where a transaction might be placed within a block.

‍

With Agave client update v1.18 in May 2024 came a new transaction scheduler, AKA the central scheduler. In this revised structure, the central scheduler builds a dependency graph, known as a prio-graph, to better manage the processing and prioritization of conflicting transactions across all threads. This major update significantly improved Solana’s ability to order transactions deterministically; transactions with higher priority fees being more likely to be included in blocks.

‍

‍

The prio-graph is a directed acyclic graph (DAG) dynamically updated as new transactions are added. Transactions are organized within the graph to form execution chains processed in time-priority order. For conflicting transactions, the priority fee determines the insertion order. This approach minimizes lock contention, enabling batches of transactions to execute smoothly and reducing delays caused by resource conflicts. Transaction precompilation verification has been offloaded to worker threads to enhance performance and allow for more efficient processing. 

‍

‍

The updated scheduler design significantly enhances scalability and flexibility, allowing potential increases in the number of threads without the risk of heightened lock conflicts. Furthermore, the centralized scheduling approach has improved reward generation, increasing earnings for many validator operators.

‍

For a more detailed breakdown of the central scheduler, readers can refer to our earlier Helius blog post covering the Agave 1.18 update.

More Effective Priority Calculation

In conjunction with the scheduler update, the transaction priority formula was refined to give an edge to transactions with lower compute demands, benefiting developers and transactions with minimal resource usage. 

‍

The revised formula is:

Priority = (Priority Fee * Compute Requested Units) + Base Fee / 

(1 + Requested Execution CUs + Signature CUs + Write Lock CUs)

‍

This new calculation accounts for all compute and operational costs tied to a transaction, ensuring priority levels accurately represent actual resource consumption. Consequently, simple token transfers or native SOL transactions without additional priority fees are guaranteed a baseline priority level within the queue. For more complex transactions, developers who neglect to specify a custom CU limit using the `SetComputeUnitLimit` instruction face a disadvantage in transaction prioritization compared to those who do.

Measuring Local Fee Market Effectiveness

This section will examine data relevant to Solana’s LFMs. 

Median Vs. Average Transaction Fees

With effectively functioning LFMs, fees for transactions involving uncontested states, such as simple stablecoin transfers, are expected to remain low. Meanwhile, fees for transactions accessing contested states, like speculative low-liquidity tokens, should surge alongside demand. A valuable metric for evaluating this dynamic is the comparison of median and average transaction priority fees. The median fee represents the fee paid by the 50th percentile user, reflecting typical costs, while the average fee accounts for all fees divided by the total number of transactions, highlighting overall trends.

‍

‍

Recent data confirms this expected pattern. November 2024 marked the highest level of economic activity on Solana to date, with average fees for non-vote transactions reaching an all-time high of over 0.0003 SOL. Despite this, median fees remained steady at 0.00000861 SOL, approximately 35x lower. This contrasts with April 2024, when a similar surge in economic activity caused average fees to rise above 0.0002 SOL, accompanied by a corresponding median fee increase to 0.00001862 SOL, roughly 10x lower. This divergence underscores the effectiveness of fee isolation in insulating typical users from cost spikes during periods of high demand and preserving user experience for non-speculative-driven use cases.

‍

We observe a strong correlation between median and average transaction fees when analyzing similar data from an EVM-based network, such as Coinbase-operated Ethereum L2 Base, which lacks LFMs. Average and median fees move relatively in unison due to a rise in global base fees when demand increases. Additionally, the gap between the median and average transaction fees is notably smaller. For instance, on December 5th 2024, average transaction fees on Base surged to $0.1115, while median fees also rose, reaching $0.0228—approximately five times lower.

‍

Reverted Transaction Rates

Another helpful trend to examine is the rate of reverted transactions. During periods of high economic activity in April and May 2024, Solana users widely reported degraded user experience as the chain suffered under the weight of heavy spam. Lack of determinism reduced the predictability and reliability of transaction execution, driving users to flood the network with transaction spam to improve their chances of faster inclusion. 

‍

Searchers frequently submit transactions for opportunistic trades without considering the probability of success. Arbitrage transactions with inappropriately low priority fees are still valid. The protocol will process them after other higher-priority fee transactions, and they will likely revert due to slippage logic. 

‍

Reverted transactions peaked in April 2024, accounting for 75.7% of all non-vote transactions. This percentage dropped significantly following the rollout of key updates, including the Agave 1.18 central scheduler.

‍

‍

A cohort analysis from Blockworks Research covering the past seven days (January 6–13, 2024) reveals varying revert rates across various activity levels. Addresses performing 1–5 daily transactions (predominantly retail users) experience a revert rate of 1.4%, which increases to 4.6% for those with 6–50 daily transactions. Notably, addresses conducting over 10,000 daily transactions see revert rates soar to 66.7%. Furthermore, high-activity addresses with over 100,000 daily transactions (bots) are responsible for 95.2% of all reverted transactions. For December 2024, the overall revert rate for all non-vote transactions was 41.2%, which indicates that a large portion of the network’s computing resources are consumed by processing failed arbitrages.

‍

‍

Ongoing Issues and Areas for Improvement

Despite significant improvements, LFMs still struggle to function deterministically under high load. Today, the primary issue lies in bottlenecks within the sub-optimal transaction processing pipeline. Under heavy load, limits such as the QUIC connection table are quickly reached, causing performance degradation.

Once queues fill up under high loads, prioritization issues arise. Transactions cannot be reordered until they reach the scheduler, disrupting the LFM mechanism. Addressing this challenge is one of the most critical ecosystem engineering priorities. Transaction pipelines require intensive optimization to handle higher transaction volumes more efficiently.

‍

Prioritization becomes ineffective if transactions are delayed in the pipeline due to processes such as duplicate removal, signature verification, and fee validation. Regardless of the scheduler's capabilities, it cannot act on transactions stuck in queues, making prioritization efforts moot.

Observability

The current fee APIs for estimating predictable transaction landing lack the sophistication needed to deliver deterministic results. Each major RPC provider offers its own custom priority fee API, while the core open-source RPC API implementation remains suboptimal. It fails to consider critical network dynamics, such as Jito’s influence, leading to less accurate fee estimations. 

Helius offers the `getPriorityFeeEstimate` RPC method, which provides fee recommendations based on historical data from both global and LFMs. Developers can input either a serialized, signed transaction or a list of account keys involved in the transaction. The method supports custom priority fee levels, categorized into six percentiles: min, low, medium, high, very high, and unsafe max. The medium (50th percentile) is set as the default recommendation. Fees are calculated using data from the 50 most recent slots.

{
  "jsonrpc": "2.0",
  "id": "helius-example",
  "method": "getPriorityFeeEstimate",
  "params": [
    {
      "transaction": "LxzhDW7T...", // Base58 encoded serialized
      "options": {
        "recommended": true
      }
    }
  ]
}

Above: Example payload for getPriorityFeeEstimate using a base58 encoded serialized transaction.

Without a deterministic method for calculating priority fees, developers often take a cautious approach by overpaying to guarantee their transactions are processed. Alternatively, they may overuse Jito tips, even for transactions where securing the top-of-block is unnecessary. These tips are frequently used as a stand-in for priority fees. Notably, most tips observed in 2024 are not tied to traditional MEV activities, such as arbitrage or sandwiching, but are aimed at achieving faster transaction inclusion. Validators reap the rewards of this inefficiency by collecting higher block rewards and MEV commissions.

Another challenge emerges when developers do not implement logic to dynamically adjust their priority fees in response to fluctuating on-chain conditions. During major events such as significant market movements, fees for accessing specific state accounts can spike dramatically. Applications lacking dynamic fee mechanisms will struggle in these scenarios, as their static fee settings are insufficient to ensure timely execution.

Proposed Solutions

Various strategies have been proposed to enhance Solana's fee structure further. These proposals aim to optimize network resource allocation and mitigate incentives to spam.

Exponential Write Lock Fees

Proposed in January 2023 by Tao Zhu (Anza) and Anatoly Yakavenko, SIMD-0110 puts forward a novel mechanism to manage congestion by imposing dynamic fees on contentious accounts. This mechanism tracks the Exponential Moving Average (EMA) of compute unit (CU) utilization for write-locked accounts and increases the cost of write-locking accounts that consistently exhibit high utilization.

To implement such a system, the Solana runtime maintains an LRU (Least Recently Used) cache of public keys for contentious accounts and their corresponding Compute Unit Pricers (CUPs). CUPs monitor an account's EMA CU utilization and provide an updated cost rate upon query.

The mechanism dynamically adjusts write-lock fees. The write-lock cost rate increases if an account's EMA CU utilization exceeds a target threshold. Conversely, if utilization falls below the target, the cost rate decreases. Initial parameters include:

• A target utilization of 25% of the account’s maximum CU limit.
• An initial write-lock cost rate of 1,000 micro-lamports per CU.
• A cost adjustment rate of 1% per block.

The write-lock fee for an account is calculated by multiplying its cost rate by the transaction's requested CUs. Under this system, total transaction fees are the sum of three components: the base signature fee, the priority fee, and the write-lock fee. Write-lock fees are 100% burnt.

At its release, SIMD-0110 sparked lively debate within the community. However, the proposal is currently inactive and has since been marked as closed.

Dynamic Base Fees

Another longer-term solution to improving Solana’s LFM would be introducing global and per-account dynamic base fees (DBFs). Jarry Xiao and Eugene Chen of Ellipsis Labs are notable proponents of this approach.

While priority fees are optional, base fees are mandatory. Currently, Solana’s base fee is fixed at 5000 lamports per signature. Users submitting simple token transfers pay the same base fee as those making complex multi-venue swaps or searchers attempting to execute complicated MEV arbitrages. Base fees do not accurately reflect a transaction's compute usage.

With dynamic base fees, an arbitrage transaction with inappropriate base fees can be considered invalid and dropped before reaching the scheduler. Raising base fees encourages spammers to send fewer transactions.

Base fees will eventually settle to an equilibrium, and transactions will be priced based on the value of the blockspace market. Because the base fee is escalating, it will ultimately reach marginal cost where sending the transaction is no longer worth the opportunity cost of the trade. Fees can not become too high; otherwise, user activity will be impacted. A maximum that is too high for bots but generally acceptable to users is ideal. Under such a system, accounts that spam transactions for inclusion will burn all their SOL.

Solana's rapid block times enable aggressive algorithms to set base fees. During periods of high demand, fees can be adjusted swiftly—potentially doubling with each block—to reflect network congestion. Conversely, as demand decreases, fees can be reduced more gradually. Thanks to Solana's short block times, fee reductions still occur relatively quickly, ensuring the network adapts rapidly to changing conditions.

An example of a similar form of economic backpressure is the Metaplex Candy Machine program, which instituted a bot tax as an anti-spam mechanism in 2022. The bot tax is an optional charge for invalid transactions. Usually, this would be a reasonably small amount to avoid affecting real users who have made a genuine mistake. This tax proved effective; mint snipers were quickly drained, and spamming halted.

Conclusion

Solana's LFMs are functional, but significant room exists for improvement:

‍

• Enhancing Priority Fee Mechanisms: Priority fee RPC calls need improvement. Ideally, developers should have a simple, deterministic way to set fees that guarantee transaction inclusion within a few subsequent blocks.
• Economically Disincentive Spam: The network must figure out ways to apply economic backpressure against bots during periods of high economic activity while maintaining low fees for genuine human users.
• Educating Developers: Developers need to stop setting static application transaction fees and rely less on out-of-protocol mechanisms like Jito for routine transactions.
• Optimizing the TPU Pipeline: The transaction processing pipeline requires further optimization to ensure transactions reach the scheduler faster to be correctly prioritized during periods of high demand.

‍

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

Additional Resources

• 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

‍