Solana’s fee market has been a persistent source of user frustration since the network became a high-activity environment in 2021. The original design used a single global fee market: every transaction competed for the same block space regardless of which accounts or programs it touched, which meant that congestion in any one application — an NFT mint, a token launch, a liquidation event — created fee spikes that affected every other transaction on the network simultaneously. A DeFi protocol swap would fail or become expensive during an NFT mint in which it had no direct involvement, simply because both were competing for the same undifferentiated block space.
SIMD-0096, the Solana Improvement Document that implemented local fee markets, changes this architecture fundamentally. Rather than a single global fee rate, transactions now pay fees based on the congestion of the specific accounts and programs they access. A mint that is creating massive demand for writes to a particular program’s accounts drives up fees for transactions touching those accounts; it does not affect the fee rate for a DeFi swap touching unrelated accounts. The fee market becomes local to the resources being contested rather than global to all block space.
The announcement of SIMD-0096 was received positively across the Solana developer community, and with good reason — the global fee market problem was real and well-documented. But the practical implications for protocol developers, traders, and infrastructure operators are more nuanced than the announcement framing suggested. Local fee markets solve one problem while introducing several new ones that the ecosystem needs to navigate.
How Priority Fees Work Under the New Architecture
Under the global fee market, priority fees were simple in concept: pay more than the base fee, get priority in block inclusion. The practical complexity was in setting the right amount — too low and the transaction failed during congestion; too high and fees were wasted. Various priority fee estimation services emerged to help applications estimate the current market rate and set fees accordingly.
Under local fee markets, the priority fee estimation problem becomes more complex because the relevant congestion metric is now specific to the accounts and programs a transaction touches. A transaction that writes to a highly contested token account — one involved in a popular DeFi protocol — needs to estimate the current fee rate for that specific account, not the network-wide fee rate. A transaction touching only uncontested accounts needs a much lower priority fee to achieve the same certainty of inclusion.
The implication for DApp developers is that blanket priority fee strategies no longer work well. An application that sets a fixed priority fee for all transactions — a common pattern before SIMD-0096 — will either overpay when accessing uncontested accounts or underpay when accessing contested accounts. The correct approach is to query fee estimates at the account level before each transaction, which requires infrastructure investment that many smaller DApps have not yet made.
Priority fee estimation services are updating their APIs to expose account-level fee data, but the ecosystem-wide tooling upgrade has a long tail. DApps that have not updated their fee estimation logic are, in the months following SIMD-0096 activation, either systematically overpaying or experiencing higher transaction failure rates on contested accounts than their users experienced before the fee market change.
MEV Under Local Fee Markets: What Changes
Maximal extractable value — the profit available to validators and searchers from reordering, inserting, or censoring transactions — is affected by local fee markets in ways that are not uniformly positive for the broader ecosystem.
Under the global fee market, MEV extraction was relatively blunt: searchers who wanted to front-run or sandwich a large DEX trade competed by paying high global priority fees, which raised the cost of all transactions during high-MEV events. Local fee markets change the structure: searchers now need to pay fees calibrated to the specific accounts involved in the target transaction, which in principle should reduce the collateral damage of MEV events on unrelated transactions.
In practice, the relationship between local fee markets and MEV is more complex. The introduction of account-level fee data creates new information that sophisticated searchers can use to identify high-activity accounts before submitting their own transactions — the congestion signal itself becomes an alpha signal for MEV extraction. Accounts showing elevated local fee rates are, by definition, accounts with high transaction demand, which is a proxy for accounts with high value flows worth capturing.
Jito, the Solana MEV infrastructure provider, operates a system of validator tip markets alongside the protocol fee market. Under SIMD-0096, the interaction between Jito tips and local fees creates a two-dimensional fee optimisation problem for searchers: they need to calibrate both the protocol-level priority fee for the specific accounts they’re touching and the Jito tip for block leader prioritisation. The equilibrium pricing of this two-dimensional market is still being discovered; strategies that worked well in the pre-SIMD-0096 environment are being recalibrated.
Validator Economics: Winners and Adjustments Required
Validators benefit from local fee markets in a specific way: fee revenue becomes more accurately correlated with the value of the block space being allocated. Under the global fee market, validators received elevated fees during any network congestion event; under local fee markets, they receive elevated fees specifically when the accounts that are generating the congestion are included in blocks. This more accurate matching of fee revenue to resource consumption should improve the long-run economics of block space allocation.
The near-term adjustment for validators is in scheduling. Solana’s banking stage — the component that accepts and sequences transactions from the incoming transaction pool — needs to correctly implement account-level fee prioritisation rather than global fee prioritisation. Validator client software has been updated to implement SIMD-0096, but the quality of that implementation varies across the validator set. Validators running older software or software that implements the local fee market logic imperfectly may be leaving fee revenue on the table or accepting transactions in a suboptimal order.
The competitive dynamic in the validator set means that validators running optimal SIMD-0096 implementations will, at the margin, capture more of the available fee revenue than validators running suboptimal implementations — creating selection pressure toward correct implementation over time. But in the months following activation, fee capture efficiency is unevenly distributed, which is a source of revenue variance for validators with the same hardware and stake weight.
How This Compares to Ethereum’s EIP-1559
The natural comparison point for Solana’s local fee markets is Ethereum’s EIP-1559, which replaced Ethereum’s first-price auction fee mechanism with a base fee plus tip structure in August 2021. The comparison is instructive but imprecise.
EIP-1559 addressed a different problem: Ethereum’s first-price auction created fee estimation uncertainty (users couldn’t predict what fee was required for inclusion) and volatile fee spikes during congestion. EIP-1559 introduced a protocol-level base fee that adjusts predictably based on block utilisation, with a tip added for prioritisation within the block. The base fee is burned, removing it from miner revenue and adding a deflationary mechanism to ETH supply.
Solana’s local fee markets address congestion localisation rather than fee predictability per se. Solana’s fee structure has always had a base fee component; the change is in how priority fees are scoped to resource contention. There is no equivalent to EIP-1559’s base fee burn mechanism in SIMD-0096 — the fee revenue, including priority fees, goes to validators and to the network’s burn mechanism at existing proportions. The comparison to Ethereum is therefore partial: both systems moved toward more market-efficient fee allocation, but the specific problems they solved and the mechanisms they used differ substantially.
What Solana and Ethereum share in the post-reform environment is a fee structure that requires application developers to do more work — querying dynamic fee data rather than using static fee parameters — in exchange for better user experience during congestion. The developer overhead is a real cost that smaller protocols may be slow to absorb.
What DApp Developers Should Do Now
For protocol and application developers on Solana, the practical response to SIMD-0096 has several components that are not all being implemented at the same rate across the ecosystem.
The immediate priority is updating priority fee estimation to use account-level data rather than network-wide data. The Helius, Triton, and QuickNode RPC providers have all published updated APIs that expose account-level fee estimates; the Solana SDK has been updated to support account-level priority fee queries directly. Applications that haven’t yet integrated these APIs are operating with fee estimation that is systematically miscalibrated under the new fee market architecture.
The second priority is transaction retry logic. Under the global fee market, a transaction that failed due to low fees could be resubmitted with a higher global priority fee. Under local fee markets, the retry strategy needs to account for whether the fee failure was due to account-level congestion or a different issue. Naive retry loops that simply increase the global priority fee on resubmission may not resolve local account congestion failures effectively.
The longer-term priority — relevant for protocols with complex cross-program invocations — is understanding the fee profile of each program the protocol touches and designing transaction flow to minimise exposure to contested accounts where possible. Some DeFi protocol architectures can be refactored to reduce the number of contested accounts touched per transaction; others have inherent account contention that cannot be architectured away and need to be managed through fee strategy instead.
What This Means for Solana’s Competitive Position
The local fee market implementation is a genuine network improvement that addresses a complaint that has followed Solana since its high-growth phase. The elimination of global fee spikes caused by unrelated activity removes one of the most common user friction points that drove transaction failures during peak demand. Silent churn from transaction friction is a measurable problem in crypto protocols, and reducing the frequency of inexplicable fee spikes during otherwise normal activity is a real product improvement.
The competitive significance depends on how well the ecosystem executes the transition. If the majority of Solana DApps update their fee estimation and retry logic within the next two to three months, the user experience improvement will be visible and attributable to the fee market change. If the ecosystem upgrade has a long tail — with many smaller apps running miscalibrated fee estimation for a year — the improvement will be uneven and the network’s reputation for reliability will remain mixed.
The comparison to Ethereum’s EIP-1559 rollout is instructive here too: the Ethereum ecosystem took six to twelve months after EIP-1559 activation for fee estimation across the application layer to be reliably calibrated. Solana’s faster-moving developer community may compress that timeline, but the challenge of coordinating a fee estimation upgrade across hundreds of independent protocols is real regardless of how capable the underlying developer community is.
FAQ
What is SIMD-0096? SIMD-0096 is the Solana Improvement Document that implemented local fee markets on the Solana network. It replaced the single global fee rate with per-resource pricing, meaning transactions pay priority fees based on the congestion of the specific accounts and programs they access rather than network-wide congestion.
Why did Solana need local fee markets? Solana’s original global fee market meant that congestion in any application — an NFT mint, a token launch — raised fees for every transaction on the network regardless of whether it touched the congested accounts. This created fee spikes and transaction failures for users whose activity was unrelated to the source of congestion.
What do DApp developers need to change? Priority fee estimation needs to use account-level fee data rather than network-wide fee rates. Transaction retry logic needs to handle account-level fee failures correctly. Developers should update to current Solana SDK versions and integrate account-level fee APIs from RPC providers like Helius, Triton, or QuickNode.
How does SIMD-0096 affect MEV? MEV extraction becomes more account-specific: fee spikes from high-MEV events are localised to the contested accounts rather than network-wide. However, account-level congestion data also provides new alpha signals for searchers. The two-dimensional fee optimisation (protocol priority fee + Jito tip) creates a more complex MEV extraction environment that is still being calibrated.
How does this compare to Ethereum’s EIP-1559? Both reforms moved toward more market-efficient fee allocation, but they solved different problems. EIP-1559 introduced predictable base fees that adjust to block utilisation and burn the base fee. SIMD-0096 localises priority fees to resource contention without a base fee burn mechanism. The developer overhead — adapting applications to dynamic fee data — is similar in both cases.
Sources
- Solana Foundation — SIMD-0096: Local Fee Markets specification
- Helius — Priority Fees: Understanding Solana’s Updated Transaction Fee Mechanics
- Jito — Local Fee Markets and MEV: Implications for Searchers and Validators
- Solana Developer Docs — How to use priority fees under local fee markets
- Blockworks — Solana’s local fee markets go live: how the ecosystem is responding
