Localized Fee Markets: Why Solana Has a Hundred Prices, Not One

The Moment I Stopped Asking 'What's the Fee Right Now?'

For weeks I had been asking my fee estimator the wrong question. Every time the bot prepared to send a transaction, I would peek at the priority fee field and wonder whether the network was "expensive" or "cheap" at that moment. Coming from a mental model shaped by Ethereum, that question felt like the right one. There is one gas market, one base fee, and you either pay or you wait.

Solana does not work that way. The realization didn't arrive as a single insight — it arrived as a series of weird data points. A meme coin would launch and the fee estimator's recommended priority would jump by orders of magnitude, but a simple SOL transfer five seconds later would still settle for essentially the same dust amount it always cost. A new NFT collection would mint, fees would spike on the relevant program, and the lending protocol I had open in another tab kept settling oracle updates for a fraction of a penny. There was no single "network busy" condition. There were dozens of micro-storms happening on individual accounts while the rest of the chain stayed calm.

This is what Solana calls a localized fee market, and it is one of the most consequential design decisions on this chain. Understanding it is not optional once you start writing software that has to compete for execution.

One Highway vs. a Hundred Toll Roads

The cleanest way to explain the difference is to compare it to driving in a major American city.

Ethereum's fee market behaves like a single interstate running through the middle of town. When rush hour hits the downtown exit, the entire highway slows down. EIP-1559's base fee is global — it rises and falls based on aggregate block demand. If one application generates a flood of transactions, the toll goes up for everyone, including the person trying to merge on twenty miles away. One congestion event affects every driver on the network.

Solana's design feels more like Los Angeles with its lane-by-lane HOV tolls and per-exit congestion pricing. A traffic jam on the off-ramp to Dodger Stadium does not raise the toll for someone heading to Long Beach. Each "account" — every program, every liquidity pool, every NFT mint authority — is its own toll lane. Only transactions that need to write to that specific account compete for priority on that account. As the Helius team put it in their analysis of the system, "someone sending a simple SOL transfer or swapping on a low-traffic pool during a major meme coin launch on Raydium pays essentially nothing extra," according to Helius's analysis of local fee markets.

This isn't a marketing line. It's a measurable phenomenon. Helius reported that in November 2024, the average non-vote fee on Solana sat around 0.0003 SOL while the median sat at roughly 0.00000861 SOL — a gap large enough to tell you that a small number of contested transactions were paying dramatically more than the rest of the chain, per the same Helius post. If the chain had a single global fee market, average and median would converge. Instead they sit roughly two orders of magnitude apart, which is the statistical fingerprint of fee isolation.

What "Local" Actually Means at the Protocol Level

The machinery underneath this behavior is worth understanding because it shapes how you write transactions.

A Solana transaction declares, in advance, every account it intends to touch and whether it will read or write to each one. The runtime uses these declarations to schedule transactions in parallel: two transactions touching completely disjoint sets of accounts can execute on separate threads with no interaction at all. Two transactions that both want to write to the same liquidity pool cannot — they must serialize, and only one can win at a time.

This is the mechanical basis for localized fee markets. When demand for write access to a specific account exceeds the supply of compute units that account can consume per block, somebody has to lose. That "somebody" is decided by priority fee competition. The accounts nobody else wants to touch don't enter into a competition at all.

The official Solana documentation lays out the constants that bound this system. The base fee is 5,000 lamports per signature, and priority fees are denominated in microlamports per compute unit, per Solana's core fees documentation. Helius's deep dive on fee mechanics adds the block-level constraints: 48 million compute units per block in total, but only 12 million per individual account, with a hard ceiling of 1.4 million compute units per transaction, according to Helius's fees-in-theory-and-practice writeup. That 12-million-CU-per-account limit is the bottleneck that creates write-lock contention in the first place. Once the most popular pool on the chain saturates its allotment, anybody else wanting to touch it has to outbid the existing demand or wait for the next block.

Helius also walks through a concrete numerical example: a transaction with one signature requesting 500,000 compute units at a priority of 50,000 microlamports per CU ends up costing 25,000 lamports, or 0.000025 SOL, per the Helius worked example. That tiny figure is what "normal" looks like. When write-lock pressure on a hot account kicks in, the priority-fee multiplier can climb by orders of magnitude — but only for transactions touching that account.

The SIMD Trail: How Solana Got Here

Localized fee markets did not arrive fully formed. They are the cumulative result of a sequence of governance proposals — Solana Improvement Documents, or SIMDs — each of which tried to fix a different gap.

SIMD-0110 was the first real attempt at a localized fee market in January 2023. Proposed by Tao Zhu from Anza and Solana co-founder Anatoly Yakovenko, it described an exponential moving average tracking per-account compute usage with a 25% target utilization, a 1,000 microlamport initial cost, and 1% adjustment per block. It never activated. The proposal was eventually deactivated after community discussion, but its core idea — that per-account demand should produce per-account pricing — survived into later thinking.

SIMD-0096 was the one that actually shipped, with the governance vote passing in May 2024 and mainnet activation arriving later that year. Its core change sounds almost boring on paper: priority fee distribution shifted from a 50% burn plus 50% to validators model, to a 100% to validators model. The motivation was anything but boring. As Helius bluntly put it, "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," per Helius's local-fee-markets piece. When half the priority fee was being incinerated, anyone competing for inclusion had a strong economic reason to route money around the protocol — directly to block builders — instead of through it. That dynamic was already visible in the explosive growth of out-of-protocol auctions. SIMD-0096 essentially admitted reality and brought the entire fee into the protocol where it could be observed and competed for transparently.

The technical implementation, documented in a Medium deep dive by Moon Simran, touched the FeeStructure.calculate_fee() and bank.distribute_transaction_fee() paths. From the outside, it looks like a one-line config change. From the inside, it shifted the entire economic gravity of the network.

SIMD-0123 followed in March 2025, addressing a side effect that SIMD-0096 had created. By directing 100% of priority fees to validators, the protocol had inadvertently cut native stakers out of one of the fastest-growing revenue lines on the chain. SIMD-0123 set up a smart-contract-based automatic distribution mechanism so that priority fee revenue accruing to validators flows down to the stakers who delegated to them.

SIMD-0228 is worth mentioning because it failed. The proposal aimed to introduce a market-based inflation mechanism tied to the staking rate, and it received only 43.6% validator support — below the threshold needed to pass. Solana governance is real governance: proposals lose. This one did.

SIMD-253, currently a proposal from Eclipse Labs, is the most ambitious of the bunch. It would introduce a dual-track system — per-account dynamic base fees plus a global dynamic base fee — designed to push the chain toward what the proposal author calls a "true" localized fee market. The target utilization is set at 85% (based on the current 12-million-CU per-account ceiling), the cache holds 1,600 accounts at a time, and a new RPC method called getPriorityFee would return recommended per-account fees on demand, per Eclipse Labs's SIMD-253 writeup. The proposal also commits to a discipline-incentive-compatibility property: per-account recommendations are guaranteed not to fall below global recommendations.

That last detail is important. It's an acknowledgment that the current localized fee market — for all its elegance — does not actually give users a reliable signal of what they need to pay.

"Local Fee Markets Aren't Real": The Critique That Stuck With Me

The most useful thing I read while trying to internalize all of this was the contrarian view. Eugene Chen from Ellipsis Labs published a piece titled, with characteristic bluntness, "Solana's Local Fee Markets Aren't Real," hosted on Solana Compass. His argument identifies three structural failures, and once you see them you can't unsee them.

The first is probabilistic inclusion. As Chen describes it, "a high-fee transaction sent late in a block's construction might not be included, regardless of its fee." Block construction on Solana is a streaming process, not a closed auction. If your transaction arrives at the leader after the leader has effectively committed the block, it doesn't matter how much you bid. You're in the next block, behind whoever shows up before you. Fee level is a necessary condition for inclusion, not a sufficient one.

The second is multi-threaded execution ordering. The Solana scheduler processes transactions across multiple threads with independent queues. As Umbra Research summarized in their own independent analysis, "deterministic ordering by priority fee is not guaranteed, either by consensus or by the scheduler implementation," per Umbra Research's fee writeup. Two transactions targeting the same account, submitted at nearly the same time, can end up in different threads and execute in an order that has nothing to do with which one bid more.

The third is signaling failure. Because the chain doesn't give users a deterministic relationship between fee and outcome, they cannot calibrate their bids. They overpay when they don't need to and underpay when they desperately need their transaction in the next block. The fee market exists, but it doesn't communicate clearly.

There's a separate observation in the Helius local-fee-markets piece, attributed to Anza engineer Alessandro Decina, that fits into this same picture: "only one non-vote transaction thread (thread three) continues processing transactions, leaving the remaining threads idle." In other words, the validator is theoretically capable of processing roughly four times the throughput it actually delivers, but the scheduling architecture leaves most of its threads sitting idle on non-vote work. That's not exactly a fee market problem in the strict sense — but it shapes the supply side of the auction in ways that are invisible to anyone bidding for inclusion.

The Agave v1.18 scheduler update in May 2024 attempted to address some of this. The old design used four non-vote threads and two vote threads with independent queues, FIFO ordering inside each queue, and priority fees as a secondary sort. The new design uses a centralized scheduler, a prio-graph (DAG)-based dependency graph, deterministic ordering, and execution chains organized by priority fee while minimizing lock contention, per Helius's fees-in-theory-and-practice piece. It's a meaningful improvement. But Chen's critique still cuts: even with the new scheduler, the relationship between fee paid and outcome delivered is closer to a probability distribution than a contract.

When Priority Fees Meet MEV

Any serious discussion of Solana fees eventually runs into MEV. The two have grown so intertwined that priority fees account for over 97.5% of total transaction costs on the chain, with the base fee reduced to a rounding error, per the H1 2025 Helius ecosystem report.

The data from January 2025 is worth pausing on. According to the same Helius H1 2025 report, total real economic value (REV) — fees plus MEV tips — on Solana reached over $551 million that month, more than three times the equivalent figure on Ethereum. The launch of the $TRUMP meme coin on January 19, 2025 pushed the median Solana fee to 0.001531 SOL that day. By comparison, the median Ethereum fee was reported at $4.84 on the same day, with Base sitting around $0.011, also per the H1 2025 Helius report. Solana's fees were dramatically lower in absolute terms — by orders of magnitude relative to Ethereum — even on what was likely the busiest single day in the chain's history.

Jito-built MEV infrastructure is the other half of this story. A Medium deep dive on Solana MEV by NNAMDI KINGSLEY notes the global Jito block engine footprint — including locations like Amsterdam, Frankfurt, London, New York, Salt Lake City, and Tokyo — and the bundle mechanics, including a 200-millisecond discrete auction, a maximum of five transactions per bundle, and a 1,000-lamport minimum tip for spam prevention. The same piece reports that Jito tips alone reached roughly $25.16 million in a single day on January 20, 2025, and that Jito tips made up roughly 22% of validator rewards in Q1 2025 — between roughly 41.6% and 66% of total REV across recent reporting windows.

The darker side of this market is sandwich attacks. The Medium piece cited above estimates that sandwich attacks extracted between $370 million and $500 million from Solana users over a 16-month period. The same source describes 2025 as a year of meaningful cooperative response: Jito Foundation blocked public mempool access, Marinade Finance blacklisted more than 50 validators participating in the worst behavior, and the estimated reduction in sandwich profitability was on the order of 60–70%. Whether those numbers hold up under independent analysis is a separate question; what's clear is that the combination of priority fees and MEV tipping has made the auction for inclusion on Solana the most consequential auction happening anywhere in crypto right now.

What This Means for Anyone Building or Trading Here

Once you internalize that Solana fees are local rather than global, several things change about how you think about transactions.

You stop asking what the network fee is. There is no such thing. The relevant question is what the fee is for the specific accounts your transaction needs to write to. If you're touching a quiet account, the fee is essentially the base fee plus a token amount of priority. If you're touching a hot pool during a meme launch, you might need to bid orders of magnitude higher just to land in the next block. The right tool for this question is the getRecentPrioritizationFees RPC method, which returns fees observed when specified accounts were locked as writable.

You stop trusting the open-source default. The Helius local-fee-markets piece is direct about the limits of the standard RPC implementation: "the core open-source RPC API implementation fails to consider critical network dynamics, such as Jito's influence, leading to inaccurate fee estimations." Each major RPC provider has shipped its own custom priority fee API in response, which the same Helius piece warns "could become a soft form of vendor lock-in." Whichever provider you choose, you should treat their fee recommendations as one signal among several, not as ground truth.

You think about whether to route through MEV infrastructure at all. If you're competing directly with arbitrage or sandwich bots, the on-chain priority fee auction is not the only auction in town. Routing through the off-protocol bundle infrastructure changes the economics — but it also changes the failure modes, since bundles can be rejected wholesale based on conditions that aren't visible from a simple transaction's perspective.

You watch the proposal track. SIMD-253, if it activates, would meaningfully change what fee estimation looks like by introducing a first-class getPriorityFee RPC method backed by both per-account and global signals. That's the kind of change that would shift how every serious participant on the chain thinks about fee strategy. Until then, the available tooling is the best signal we have, but it's worth knowing it's incomplete.

You watch the validator client mix. The H1 2025 Helius ecosystem report describes the client distribution at one recent epoch as roughly 83% Jito-Agave, 9% Agave, and 8% Firedancer, and reports memory optimization gains in TPU QUIC from 2.6 GB down to 124 MB along with a substantial reduction in gossip traffic. The client mix matters because each client's scheduler can produce slightly different ordering outcomes, which means the same priority fee bid can have slightly different effective behavior depending on which validator is leader. As Firedancer's share grows, that texture is going to keep shifting.

What the Localized Model Doesn't Solve

It's tempting to walk away from this with the conclusion that Solana's design is strictly superior to Ethereum's because fees stay local. That's an oversimplification.

The localized model solves one specific problem extremely well: it prevents one application's congestion from taxing everyone else on the chain. During the worst days of the meme coin era, that property has been worth its weight in lamports. A user opening a wallet, sending a stablecoin to a friend, or settling a routine DeFi operation doesn't pay the bot war's tax. That's a real win.

But the model does not solve the auction-design problem. It doesn't give users a deterministic relationship between bid and outcome. It doesn't fully resolve the off-chain coordination incentive that SIMD-0096 was supposed to neutralize. It doesn't make MEV go away — it just moves the contest into a more transparent venue. And it leaves the validator architecture in a state where, by the most vocal critics' read, much of the network's theoretical capacity is sitting idle while the relevant accounts saturate.

The critique and the design are both correct. Solana's localized fee market is one of the most interesting auction designs in production crypto, and it has real gaps that the next round of proposals — SIMD-253 chief among them — are trying to close.

Key Takeaways

• Solana fees are local, not global. Only transactions that need to write to a contested account compete for priority on that account. A meme coin launch doesn't tax a routine SOL transfer.
• Average and median fees can sit roughly two orders of magnitude apart. That gap is the statistical fingerprint of fee isolation — and it's exactly what you'd want a localized market to look like.
• The SIMD trail tells the story. SIMD-0110 (inactive) introduced the idea, SIMD-0096 (active) brought priority fees fully into the protocol by ending the 50% burn, SIMD-0123 (active) pushed those fees down to stakers, SIMD-0228 (failed) tried for dynamic inflation, and SIMD-253 (proposed) would deliver a proper dual-track per-account-plus-global fee signal.
• The critique is legitimate. Probabilistic inclusion, multi-threaded ordering, and signaling failure mean that paying more doesn't deterministically buy you inclusion. The auction is real, but it's noisy.
• Fees are mostly priority fees now. Base fees are a rounding error. The interesting market is the priority fee market layered with the off-protocol bundle market, and the two interact in ways that aren't captured by any single RPC method today.