WTF is Solana Fee Markets? ELI15 Explainer

Navigating Solana’s Feescape: MEV, Jito, Multidimensionality, and Beyond

27 min readFeb 29, 2024

$0.0025 — that’s the fee charged for transferring $1 or be it $100 million on Solana!

But, is it sustainable? It’s all determined by the Solana Fee Markets. Fee Markets are critical for any blockchain. It’s simply a market to determine fees, which are crucial to preventing spam and incentivizing validators. Think of it as a market, where A blockchain needs to balance fees, incentivize validators, fuel network growth, and not choke users with a $10 coffee transaction fee.

While Solana Fee Markets are often touted as “broken”, it’s an interesting piece of stuff in the intersection of tech and economics. In this report, we’ll closely examine Solana’s fee economics. We’ll examine its fee structure, compare it to other platforms, and analyze how it affects network performance and user experience. Ultimately, we’ll explore strategies to reduce spam and efficient resource management. **

This report assumes that you have a basic understanding of Solana and blockchains. If you have no idea what is Solana Fee Markets, let me tell you my friend, you’re in for a treat. Running low on time? just bookmark this to read later — justifies the weeks of effort put into this piece :)

What are Fee Markets?

Let’s start with the OG — Bitcoin. The bitcoin miners while not directly responsible for block selection, served as transaction processors, collaboratively propagating them across the network. Fee markets emerged as a mechanism for miners to prioritize transactions based on the offered fee, ensuring network resources were utilized efficiently. This foundational concept has since evolved, finding applications in notable blockchains like Ethereum and Solana. At its core, the modern fee market is a dynamic pricing mechanism for network resources, namely block space and transaction execution.

Crypto networks rely on fee markets to prioritize transactions based on the offered fee. This mechanism helps ensure network efficiency, deter spam transactions, and contribute to network sustainability. A careful balance is required between transaction speed, user cost, and overall network health.

“What makes the network?” is hard and endless to debate. Is it the users who do transactions? is it the set of validators or nodes who run the work? or is it the apps and protocols that are built on the network? By the end of this essay, we will try to give you a comprehensive overview of the technicalities and economics of what makes a network work with the example of Solana and other networks, and you can let us know what you think can be a proper definition of a network.

Is this fee revenue for the network?

While protocol designers don’t explicitly design fees as revenue streams, they certainly play a crucial role in network sustainability. Take Bitcoin, for example fees ultimately become the long-term security budget for the network. In this sense, fees function as revenue, directly benefitting miners (fully or partially, depending on the network).

So is block space a commodity?

Blockspace is similar to oil in that it holds value, but it does not generate profit on its own. Just like oil requires refining and usage to create gasoline, blockspace needs users and activity to unlock its potential. Although blockspace does not have a Profit and Loss of its own, miners, validators, and other players in the blockchain ecosystem utilize it to generate income. They do so by charging fees for transactions and activities that depend on block space, much like how oil companies refine and sell gasoline.

Evolution of Fee Market Economics

Miners in Bitcoin select the transactions in the block with the highest fees to be executed first.

These fees were compensation for securing the network and creating new blocks, especially important as block rewards diminish over time. Since the network’s primary function was transferring Bitcoin itself, transaction types were relatively uniform, allowing for somewhat predictable fee estimations.

Cut to Ethereum, with the introduction of “Smart Contracts” you can do any kind of programmable logic on-chain. This brings us to “Gas”, the combination of many things that exist in the network, like network bandwidth, network storage, and computation to make a unit of gas.

Transactions on Ethereum require “gas,” a unit representing computational effort like storage and bandwidth. What you pay in $ETH is fees (not gas), so there is an exchange rate between gas and ETH, which is essentially the gas price.

Miners compete to include your transaction in their blocks, you specify a maximum gas limit and miners compete with their gas prices, determining the final fee.

Challenges and the Rise of EIP 1559.

While the early fee market facilitated resource allocation, challenges like spam, DoS attacks, and network congestion emerged.

Surges in activity, like NFT drops or DEX spikes, overwhelmed the network, leading to a degraded network experience, transaction delays, and exorbitant fees.

The way the validators would select the TX would be based on the fee and the mempool would be flooded with these iterative bids that were for using a certain protocol like a DEX and a normal user doing a token transfer would suffer and would have no idea why is it happening.

Users seeking faster transactions engaged in “gas wars,” driving fees to exorbitant levels, sometimes reaching hundreds or even thousands of dollars during peak times.

Enter EIP 1559, a significant evolution in Ethereum’s fee market:

Recognizing these challenges, EIP 1559 aimed to solve these challenges with:

Dynamic base fee: Automatically adjusts based on network demand, mitigating congestion and ensuring predictable fees for users. This made the fees predictable and now if you do a transaction from Metamask you are shown the base fee on the Metamask wallet itself.
Priority fee: An optional tip for miners/validators to prioritize urgent transactions
Burning of base fee: Increases network scarcity and potentially boosts ETH value

on a side note: The recent shift in Ethereum from PoW to PoS impacted miner revenue, prompting the introduction of EIP-1559. Initially viewed as a fee market improvement, the narrative shifted towards “ultrasound money” and token supply reduction through burning fees.

In 2021, as Ethereum tackled scaling and fee challenges with EIP 1559, another player entered the scene. This new blockchain, boasting a unique consensus mechanism and lightning-fast transaction speeds, promised a smoother user experience. Within months, fueled by the booming DeFi summer of 2021, it emerged as a major contender: Solana.

Refer to this piece by Packy McCormick from Not Boring to explore more about Solana’s extensive history.

This section now delves deeper into Solana, exploring its technical and economic underpinnings and unpacking its impact.

The Solana

There are many ways to describe Solana, such as its fast transaction processing, use of local fee markets, and more. However, one of the most succinct definitions of Solana that I keep going back to is from the Quarterly Solana updates by Peter Horton at Messari.

Solana is an integrated, open-source blockchain with the goal of synchronizing global information at the speed of light.

Solana prioritizes ultra-fast transactions and high capacity. It achieves this through:

Unique timestamping: Proof-of-history (PoH) ensures transaction order without traditional mining.
Speeding up block building: Turbine protocol accelerates block confirmation.
Parallel processing: Shards handle transactions simultaneously, boosting throughput.

Upgrades like QUIC, QoS, and local fee markets further enhance performance and efficiency, however, this speed comes at a slight cost of sacrificing some verifiability.

The Key Components

Clients

Clients act as the software tools validators utilize to verify and secure transactions. Solana and Ethereum differ in their execution approach. Solana’s multi-threaded execution has drawbacks like software bugs that affect its uptime. Diverse clients can decrease the probability of such bugs. Ethereum has a higher uptime compared to Solana.

Currently, the Solana network is primarily dominated by two clients: one developed by the core team, Solana Labs, and another being Jito-Solana which is simply an extension of the Labs client (more on this later). Solana’s validators need to fix the clients used by the platform to address this challenge. If we look at the numbers the Solana Labs Client is alone responsible for over 68.55% of the network, followed by 31.45% of the Jito-Solana client.

Does Client Diversity Matter?

Client Diversity upholds the property of decentralization in a network. If some client node has the majority of the stake in the network (in a PoS blockchain) let’s say 70% and there comes a bug in it, that can bring down the block propagation, and transaction ordering and largely affect the functioning of the network.

While relatively older blockchains have tackled this issue better, we believe with the upcoming new clients like Firedancer and Sig, we can expect Solana to be sufficiently decentralized than before.

Solana’s block building Mechanism

Solana’s block-building mechanism, referred to as Leader Schedule, is an intricate system designed to guarantee a predictable, high throughput in the network.

Key Components:

Leader Election: Validators are assigned roles as leaders for specific slots (time intervals). This happens through a deterministic, verifiable random function (VRF) that ensures fairness and randomness.
Block Proposal: Each leader gets a chance to propose a block within their assigned slot. They collect transactions from the network and validate them according to the consensus protocol.
Gossip Protocol: Transactions are disseminated rapidly across the network using a gossip protocol, ensuring all validators have access to the same transaction pool.
Proof of History (PoH): Leaders include a cryptographic proof of elapsed time in their blocks, called PoH. This allows for efficient clock synchronization and prevents forks in the blockchain.
Vote and Finalization: Other validators vote on the validity of the proposed block. Once enough votes are received, the block is finalized and added to the chain.

Solana Fees

Solana’s value prop is low fees and it’s fast. But can it be economical to be both? how does it manage to incentivize validators? is it possible to be profitable in the long run?

there are three types of fees:

Vote fees: ~0.9 SOL/day — this is the fee every validator has to pay irrespective of their stake
Base Fee: 0.000005 SOL/tx (5,000 Lamports) — Fixed transaction fee for anyone to access the network resources. 1 SOL = 10⁹ Lamports
Priority Fee: Users can specify variable fees based on compute units used to determine transaction order in a leader’s queue.

Historically though most of the fees came through voting transactions (80–90%). After the recent rise in the activity, SOL prices going up, and many projects rewarding their users with airdrops or the anticipation of it, the on-chain activity has skyrocketed and so have the priority fees.

Similar to Ethereum’s 1559, Solana also burns 50% of fees and the remaining 50% goes to validators.

Are voting fees a threat to decentralization?

All validators, regardless of stake size, pay the same fixed fee to participate in consensus (voting). Voting fees contribute significantly to validator income, creating a feedback loop.

As it is Stake-Based, the larger validators, proposing more blocks due to their stake weight, earn more voting fees, further increasing their stake.

Smaller validators struggle to break even, potentially decreasing their participation and influence

Consequences:

High Minimum Stake Requirement: Profitability demands a hefty stake (>500k SOL), hindering smaller players’ entry. Use this calculator to try with different values.
Delegation Dilemma: Foundation’s delegation to smaller validators might not maximize decentralization.
Centralization Risk: If this trend continues, a few large validators could control a significant portion of the network.

Base Fees

Solana transactions have a fixed base fee of 0.000005 SOL (5,000 lamports) per signature that must be paid upfront. The fee is independent of the actual resources used to execute the transaction. Transactions require a specified number of compute units (CUs) upfront, and if the limit is exceeded, the transaction will fail.

When it comes to increasing profits, the most obvious solution is to raise the base fees. This would result in a multiplication of overall profit. However, the base fees are still very low (currently around 0.0005 cents), so it wouldn’t burden the user too much. However, it wouldn’t be a wise decision to do so while trying to build a fast, cheap, and monolithic chain in the long run.

There are a few ways to improve this:

instead of the base fees, we can use the dynamic “Priority Fees” to price the transaction.
Reduce spam and increase the efficiency with MEV — Jito
Using Firedancer to increase the supply of blockspace. (though that would come with the state growth issue for the massive amount of data generated)

Isolated Fee Market — The Key Difference

There were no priority fees when Solana got started. There was only the base fee of 5000 Lamports per signature per transaction. As the application layer started becoming more sophisticated and user demand kept growing, the Solana team realized that fixed fees for everything was a design flaw and started working on a redesign of their fee markets in late 2021. Priority fees were introduced and Solflare became the first wallet to implement them in their wallet in 2023.

Let’s take a step back and compare it to EVM to understand it from a high level.

In the EVM, each operation has a specific cost based on the computation required. For instance, sending ETH costs 21,000 gas, and a token approval costs ~45k. Gas units are multiplied by the base fee, which is a function of demand. Ethereum sets a block gas target of 15M gas units to control demand. If a block consumes more gas, the base fee increases; if less, it decreases. If demand increases, the price for computation increases.

Whether you are doing a transfer on ETH(ERC20), minting an NFT (ERC721), or doing a transaction on a DEX (Uniswap) you will pay the same base fee. and based upon the fees paid in all cases will depend upon the demand-based dynamic price of the base fee. For example, for transferring ETH which costs 21k gas you will have to pay 21,000 * 10 gwei = 0.00021 ETH (1 gwei = 10⁹ ETH). Now if the base fee becomes 30 gwei (3x increase), you will have to pay 0.00062 ETH for the same transaction.

Now you must realize that any demand increase through the chain can affect the whole chain and elevate the fees drastically. That’s where the concept of Isolated or Local fee markets comes in.

Solana Virtual Machine (SVM) has fixed transaction fees for all compute units (CUs), regardless of the amount i.e. 0.000005 SOL (5k Lamports). This type of allocation is inefficient and does little to deter spam. While it’s in an early stage SVM enables unique benefits like fee isolation, which allows for increasing fees for “hot” states while leaving other applications unaffected.

On Ethereum, once the transaction has been approved by the user it waits to be executed in a memory pool (also mempool in short). They are picked up by the validators in the highest fee-paying order for the block. The global mempool is created when validators share their mempools. This is where the maximum extractable value (MEV) is generated. MEV searchers use bots to identify transactions that can be frontrun or backrun for profit. For example, a searcher can buy X token before a big transaction completes and sell it after that for an instant profit

The most important thing is, that SVM can process transactions in parallel. This multithreaded nature of Solana means you can execute transactions using multiple cores (just like the cores in a CPU). EVM is single-threaded, while SVM enables parallel execution by requiring each transaction to specify the data it modifies beforehand.

This act of specifying the data beforehand is known as declaring the “State”. It is a snapshot of balances, smart contracts, and transaction orders. A state change happens when changes are made to the digital ledger of a blockchain. So you are forced to list what accounts a tx gonna interact with upfront, if a tx tries to interact with an account that’s not a part of the list then the tx might be invalid.

Reason: Multiple threads, and this declaration of accounts to be interacted with help to avoid any conflicts or overlaps during execution.

Journey of a Transaction

Once a user signs a transaction in their wallet, the wallet sends the transaction to a Solana RPC server. Anyone can run an RPC server, including validators. When the RPC server receives the transaction, it checks the leader schedule (which is created every two days) and forwards the transaction to the current leader and the next two in line.

Execution: The leader processes your transaction and records it locally.
Propagation: The leader shares the transaction with other validators.
Confirmation: Once enough validators agree (voting), the transaction is considered “confirmed” and you get a status update.
Finalization: The transaction becomes “final” after 31 more confirmed blocks are built on top, providing extra security.

The leader is responsible for creating a block for the current slot, which lasts about 400 milliseconds. They are assigned four consecutive slots to do this.
Leader Validates: The leader, responsible for creating the current block, receives your signed transaction. They verify its signature and perform preliminary checks.
Scheduling Options: While most validators use the standard Solana client’s scheduler, they can choose their block-building algorithms for flexibility.
Multi-threaded Execution: The default scheduler runs multiple threads (usually four for non-voting tx), each with a queue of transactions waiting their turn.
Priority: Transactions get assigned to a queue based on priority fee (fee paid per compute unit) and arrival time. This means higher-paying transactions or those waiting longer might get processed sooner.
No Global Order: There’s no single line for all transactions. Each thread’s queue has its own order.
Locking and Execution: When a thread processes a transaction, it tries to acquire the necessary account locks (like getting a library book before reading). If successful, it executes the transaction. If not, it waits and tries again later.

Let’s take a look at an simpler example from an article from Umbra research to understand how it works through various transactions

Transaction Labels:

Each box represents a transaction with labels indicating the “books” it needs (accounts).
Think of these accounts as specific sections in the library containing information relevant to the transaction.

Execution Threads:

Imagine two cashiers working in parallel (threads 1 and 2).

Thread 1:

Tries to “check out” books [a,b,c], [d], then [c,j], and finally [f,g].
It successfully gets [a,b,c], [d], and [f,g], but fails to acquire [c,j] (someone else might be reading!).

Thread 2:

Attempts to “check out” books [w], [x,y,z], [c], and [v].
It manages to get [w] and [x,y,z], but encounters the same issue with [c] as thread 1, and also can’t access [v].

Remaining Transactions:

Any transactions that couldn’t get their needed resources (books) are put back in line for another attempt later.

when multiple transactions need the same resource (book), they can’t “read” or “write” at the same time. This is where write-locks come in. The first transaction requesting a specific resource gets the lock, while others wait for their turn.

Market Possibilities:

This parallel processing with write-locks opens the door for interesting fee market dynamics. Imagine a popular book (“hot state”) that everyone wants to access. Normally, transactions are processed in order (FIFO). However, with Solana’s priority fees, where transactions can “pay” to jump the queue for “hot” resources.

Think of it like offering extra to the cashier (validator) to access the popular book faster. This doesn’t replace the normal queue but lets urgent transactions with higher fees get prioritized for specific resources.

More the demand for certain programs or accounts (compute units requested), so is the priority fee for them. In this example:

States “A” and “B” have low demand (compute) and transactions use the fixed base fee.
State “C” is moderately popular (“warm”) and some transactions pay priority fees for faster processing.
State “D” is highly sought after (“hot”) and transactions compete with priority fees through bidding. But the Account reached the maximum CU utilization limit for that block so despite paying significantly more fees the transaction couldn’t get included in this block.

From a fee perspective: unlike ethereum, they are not only bound by the fees, but also these accounts and the fees. If you are interacting with an account that has too much interaction (congestion), even if you pay the fixed base fee, there is a chance that you might still not get included in that block.

Imagine a block like a big container that can hold 48 million Compute units (CU). Each account is like a box inside this container, needing a certain amount of processing power to function. Blocks are built continuously, with leaders constantly adding new ones with a 400ms interval.

Here’s the key point:

No single account can take up more than 1/4th of the container (12 million CU), even if it’s super active (“hot state”). This ensures other accounts don’t get squeezed out and fees stay reasonable.

Why is this important?

Unlike Ethereum, where fees can skyrocket during high demand, Solana keeps things fairer by limiting individual account usage.
This allows parallel processing through 4 threads within the container, ensuring smooth operation even during high on-chain activity.
There can be 6 threads, but only 4 are reserved for non-voting tasks.

The blue line shows the effectiveness of priority fees at a time of high demand. (Image credits: Helius Blog)

As a result; the users not interacting with that hot state won’t have to pay the high fee. They can ensure a smooth network experience; thanks to the local fee market.

Solana and the mempool both have their own sets of advantages and disadvantages. The disadvantage of using the mempool is that it can lead to slow transaction speeds and gas wars. On the other hand, Solana’s design can lead to spam due to the increased probability of transactions being included in the block.

There have been several upgrades, but still, there are a lot of failed transactions and they have increased quite a bit with the increased chain activity from December of the last year.

The current scheduler mechanism doesn’t guarantee transaction ordering based on the fees and inclusion in the same block, as the scheduler assigns a thread to the transaction randomly. So different tx can land at position even without any network jitter.

Jitter and its downstream effects

You are sending a text message. Ideally, it arrives instantly. But sometimes, delays or disruptions (jitter) can occur. The same happens on Solana with transactions. Lately, due to increased activity (airdrops, DEX activity, etc.), jitter has been higher. Normally, you pay a “priority fee” to get your transaction processed faster. But with jitter, your transaction might land randomly within a block, potentially negating your fee advantage. This could explain why claiming JUP recently felt slow.

In a lottery where the prize is getting your transaction processed quickly. With high jitter and many users sending transactions, it becomes less about paying the highest fee and more about sheer luck (sending multiple transactions).

When one system fails (high fees due to jitter), people find alternatives. In this case, if priority fees become unreliable, users might resort to sending more transactions, hoping for a faster slot. The currency becomes how many TXs you can send and not priority fees.

MEV

Since paying high fees isn’t a guarantee to get included in a block on Solana, MEV searchers resort to a different tactic: spamming the network with numerous transactions. They hope that at least one of these transactions is picked by the validator for inclusion in a block, allowing them to extract MEV.

In two days (1 epoch = 432,000 slots) on Solana, over half the processing power (58%) goes towards failed attempts to snag arbitrage opportunities. And out of them, only 2% succeed (Source: Jito Labs). These compute wasted just because of these identical arbitrage transactions.

These profitable arbitrage opportunities are extracted rarely by the validators themselves, but instead, the external entities called “Searchers” are searching for these MEV opportunities and trying to land them on Chain before the opportunities go away.

MEV stands for “Maximal Extractable Value” which refers to the amount of value that can be extracted by the entity with the monopoly power of organizing the block, also known as the leader.

This concept applies to both Ethereum and Solana blockchains. In Ethereum, transactions are ordered in the mempool by the amount of gas offered, with the highest gas transactions being placed into the block until the block is full.

On Solana, the block operates using the scheduler mechanism previously discussed. Latency plays a big role here on Solana. The states get updates very quickly and the continuous block production makes it more difficult to run auctions without having a “speed bump”. The speed bump is simply the time used to run those block space auctions before the TXs get executed. Auction time for Jito is currently at 200ms.

Although validators are rarely the ones who extract these profitable arbitrage opportunities, external entities known as “Searchers” are actively searching for MEV opportunities and attempting to capture them on a chain before the opportunities disappear.

There are many ways to do profitable MEV extractions. The Most common type of arbitrage is simple atomic arbitrage.

Atomic Arbitrage

For example: there are two DEXs on Solana:

Orca: Where the current price for 1 SOL is 100 USDC.
Phoenix: Where the current price for 1 SOL is 99.99 USDC.

Atomic Arbitrage Opportunity: Many traders notice this price discrepancy. They can execute an atomic arbitrage trade for a small profit, exploiting the temporary price difference. Here’s how it would work:

Atomic Transaction: The trader creates a single transaction that contains the following instructions:

Sell 1 SOL on Orca for 100 USDC.
Immediately buy 1 SOL on Phoenix for 99.99 USDC.

This atomic transaction is sent to the Solana network as a bundle, ensuring all instructions execute or none of them do (atomic). This prevents the risk of buying SOL on Orca and then not being able to sell it at the expected price on Phoenix.

2. Execution: If successful:

The trader pockets a profit of 0.01 USDC (minus transaction fees).
The prices on the DEXs will slightly adjust, moving closer to equilibrium.

However, only one of these transactions can be successful, as the others represent failed arbitrage opportunities. Since validators cannot prioritize or choose transactions before they enter the queue, they might process and validate a large number of these unsuccessful transactions, wasting valuable validator resources.

A similar strategy can apply to NFT mints. Though they might not be atomic, they can be sold for a profit once the mint goes live.

Frontrunning — Sandwich attack

You go to Jupiter and buy the Shitcoin at the market price, you click swap. The way you may lose out on the opportunity /get the worst fill, one of them being sandwich attacks.

If you have set your slippage to let’s say 5% and if someone can place a tx before you and after your tx, you will get the worst fill possible and they will make the profit on top of that.

Margin Trading Protocols through Liquidations

Liquidations are a crucial mechanism to maintain the health of the margin trading protocol and protect lenders from potential losses. Here’s how it works:

Margin Position Approaches Insolvency: When a trader’s borrowed funds (position value) come too close to the value of their collateral due to adverse price movements, the position becomes at risk of default.
Liquidation Trigger: If the value falls below a specific threshold (e.g., 80% of collateral value), liquidation becomes eligible.
Third-Party Liquidators: Anyone can participate in liquidations, incentivized by the potential to earn a profit.
Liquidation Process: The liquidator uses a permissionless transaction to:

Close out the unhealthy position (buy or sell the borrowed asset depending on the position type).
Receive a portion of the collateral at a discount (e.g., 5–10%). This discounted price compensates the liquidator for the service and potential risks involved.
Remaining Collateral: After the liquidation, any remaining collateral is returned to the original borrower.

A significant amount of Solana’s processing power is wasted due to failed attempts at capturing MEV opportunities, specifically through redundant arbitrage transactions. This inefficiency raises concerns about scalability and resource management.

At present, searchers are the ones who are dominating Solana’s MEV game. However, if the leader is using the native Solana setup, searchers have to rely on spam and priority fees, which is not a fair or simple deal. Moreover, half of the fees get wasted, which limits the leader’s MEV capture to only 50%. This is an inefficient process for validators who are trying to claim what is rightfully theirs.

Jito — A feature and a bug

Jito tackles the challenge of inefficient MEV capture on Solana and aims to democratize its access. It achieves it through

1. Enhanced Efficiency and Profitability:

Jito builds upon the existing Solana Labs’ client, adding functionalities (a few thousand lines of code) to optimize MEV capture for validators.
Bundled transactions: Jito introduces bundles for transaction execution:
Sequential execution: Ensures specific order for critical MEV opportunities like liquidations and arbitrage.
Atomic execution: All transactions within a bundle are executed together as a single unit. This ensures that either all the transactions happen, or none do. Imagine booking a flight and a hotel simultaneously: you only want the flight confirmed if you also get a hotel room.
Deduplication and filtering: To address the problem of wasted resources, Jito uses a relayer that receives transactions from the validator. This relayer performs the following actions within a short timeframe (200ms speed bump):
It removes identical transactions submitted by various parties and discards irrelevant transactions.

2. Improved Searcher Participation:

Identifying valuable transactions: Jito’s block engine actively analyzes the mempool and identifies highly profitable transactions benefiting both the network (MEV) and the validator (through a 5% tip). These transactions are then grouped into bundles for efficient processing.
Auctioning and flexibility:
Pre-built bundles: Jito’s engine auctions off these bundles to the highest bidder, ensuring the most valuable opportunities go to those willing to pay the most.
Searcher independence: Searchers still have options:
Construct their own bundles: They have a 200-millisecond window to create custom bundles for specific MEV opportunities.
Bid on existing bundles: They can participate in the auction for pre-built bundles if they find them appealing.

Fees

Searchers are the ones who are dominating Solana’s MEV game. However, if the leader is using the native Solana setup, searchers have to rely on spam and priority fees, which is not a fair or simple deal. Moreover, half of the fees get wasted, which limits the leader’s MEV capture to only 50%. This is an inefficient process for validators who are trying to claim what is rightfully theirs.

But with the Jito-Solana client, searchers can slide in some value to the leader through Jito bundle auctions, where the competition is all about who’s willing to pay more, not who’s the fastest. Here’s the cool part — 100% of those bundle tips? They’re all heading straight to the validator and their stakers (JitoSOL).

Jito’s approach offers several benefits:

Reduced wasted resources: By filtering out redundant and unnecessary transactions, Jito helps to optimize network usage and improve overall efficiency.
Improved MEV capture: Bundled transactions with sequential and atomic execution allow users to better exploit MEV opportunities that require specific ordering or all-or-nothing execution.
Jito’s user-friendly interface and features aim to make MEV capture more accessible for a wider range of participants, not just specialized players.

Why a bug — Is it a threat to decentralization?

While Jito aims to democratize MEV, introducing a relayer that filters and prioritizes transactions raises potential centralization concerns.

Reliance on a relayer: If the relayer becomes compromised or experiences downtime, it could disrupt MEV capture and transaction processing for Jito users.
Potential for bias: The relayer’s filtering criteria could introduce bias in favor of certain MEV strategies or users, potentially hindering the intended democratization goal.

It is because MEV tends to benefit larger, more centralized players who have the resources to extract and maximize this value, potentially undermining the level playing field and the decentralized nature of the network.

Solana’s decentralization is a concern due to its design which may favor high-stakes large validators. This could lead to these entities exploiting the network to their benefit, particularly through MEV. Actions taken by projects on the platform, such as the Solend DeFi protocol, have sparked debates about decentralization. It is important to address centralizing forces, including those related to MEV, to maintain the network’s sustainability.

To keep it sustainable, multidimensional fee markets are being considered as a potential solution to the limitations of single-resource fee markets. This approach aims to create a more efficient and fair system by pricing various resources involved in transaction processing.

Multi-dimensional Fee Marktes

Existing Fee markets are one-dimensional. For instance, Ethereum’s fee market is built around a single fungible unit of account i.e. gas. This single resource (gas) is assumed to be a proxy for many underlying non-fungible resources (e.g., bandwidth, computation, and storage). The gas prices were a rough approximation of the underlying resources used.

Multidimensional Fee Markets are a growing area of research, where they individually price these different non-fungible resources rather than combining them into one unit. EIP-4844 is a straightforward two-dimensional fee market, as data blobs have their fee market independent of Ethereum execution gas.

What are they?

They simply consider multiple factors like

Computational resources: Transactions requiring more processing power incur higher fees.
Data storage: Storing data on the blockchain comes at a cost.
Network congestion: Fees increase during periods of high demand to incentivize validators to prioritize transactions.
Transaction type: Different types of transactions (e.g., simple transfers vs. complex smart contract interactions) might have different fee structures.

Benefits:

More granular pricing: Allows for fairer and more efficient allocation of resources by reflecting the actual cost of different transactions.
Improved scalability: This can help alleviate congestion by discouraging resource-intensive transactions during peak times.
Flexibility: Enables tailored fee structures for different needs and use cases.

Local fee markets = Multi-dimensional? Not really. Local fee markets focus on account-specific factors, reflecting the resources involved in interacting with different accounts. Multidimensional markets expand further, with a wider range of resource considerations.

How Solana can benefit from multi-dimensional fees

Solana’s localized fee markets have significantly improved the network. But how do we efficiently allocate resources (compute, storage, memory) in Solana’s dynamic network? Traditional fee structures struggle, leading to:

Unfair costs: Users pay the same despite different resource needs.
Bottlenecks: resources with high traffic get congested.

While multi-dimensional fees offer individual resource pricing, “load balancing” across them requires another layer of sophistication:

Dynamic Program-Level Fees:

Balancing across programs: Fees can adjust based on program behavior, not just individual transactions. Programs that consume more resources pay higher fees, incentivizing developers to optimize.
Validator service fees: Validators can offer premium services like Zero-Knowledge Proofs (ZKPs), oracles, or bridges, charging dedicated fees for each.
Solana’s unique ability: Only Solana’s multi-threaded architecture allows the creation of such dynamic fee structures.
Granular pay based on parallelism: Users can opt for higher fees to execute transactions with more CPU cores (parallelism), maximizing throughput for resource-intensive tasks.
Tighter coupling: By closely linking program execution to physical resources, Solana can enable more granular fee markets that reflect real-time demand.

Source: Tarun Chitra Breakpoint Talk 2023

From this research done on dynamic pricing, it was found that:

Fees that matched the exact cost of utilizing network resources (marginal cost) performed best. These optimal prices incentivized producers to include transactions that maximized overall benefit, regardless of individual user preferences.

What can be done in Solana’s case?

Solana’s Extension:

Program-level resource utilization: Consider resource usage (CPU, storage, etc.) at the program level.
Call frequency parameter: Account for how often a program is called when setting the gas price.
Per-program fees: Enable fairness and efficiency beyond just throughput optimization (though challenging in modular contexts).
Localized fee markets & gradient descent: Leverage Solana’s local fee markets to implement a simple “gradient descent” algorithm.
Reduced variance for users: Minimize user-facing fee spikes and ensure a smoother experience.

To get deeper into these points check out this research paper on “Dynamic Pricing for Non-fungible Resources” and this talk by Tarun from Gauntlet at breakpoint 2023.

Possible steps to extend Solana’s existing fee market

1. Multi-dimensional Pricing with Account-Based Factors:

Solana could integrate account-specific information into fee calculations. This could involve considering:

Account age and historical activity: Older, more established accounts with consistent usage might receive lower fees.
Account type and purpose: Differentiate fees for smart contracts, regular accounts, and specific use cases (e.g., NFTs).
On-chain resource consumption: Adjust fees based on actual computational usage and storage needs.

2. Credits and Loyalty Incentives:

Solana could implement a credit system similar to the “Fee credits” concept proposed by Dev and Alpin from the Osmosis team. Users could earn credits through specific application behaviors, actions, or staking, which could then be used to offset transaction fees. Additionally, loyalty programs might reward frequent users with lower fees or priority access.

3. Dynamic Fee Adjustments and Market Mechanisms:

Similar to existing dynamic fee adjustments based on network congestion, Solana could implement more nuanced algorithms that consider multiple factors. This could involve:

Predictive pricing based on historical data and current demand.
Auction-based systems for specific resources or congested accounts.
Fee smoothing mechanisms to avoid sudden price spikes.

4. Integration with Layer-2 Solutions:

Exploring fee solutions on Layer-2 scaling solutions built on Solana could offer separate fee structures depending on the use case and desired speed. This could allow for more flexibility and cater to different user needs.

Closing Thoughts — Solana Fee Markets Need an Overhaul:

Solana’s approach to scaling blockchains and design choices are very different from Ethereum, and so will Fee Markets. Simply copying the Fee Markets from Ethereum is not a solution, but there are valuable lessons to be learned there. Multidimensional resource pricing is an interesting approach and Solana is attempting to do this at the individual account level to build on top of the “local fee markets”.

I also believe that with Firedancer kicking in Q3 2024, the Solana Fees debate will get heated up and we will see a plethora of research and experimentation on this topic. We are optimistic that Solana will eventually figure out a robust fee mechanism, which will pave the way for more sustainable chain economics going forward!

If you made it so far, thank you for reading it till here. It would mean the world to me if you can share it, justifies the weeks of efforts that went into this one. If you have any queries, feel free to reach out to me on Twitter (X) — @inSitesh

References and Further Reading:

Solana Fee Market by Eclipse
Fee market in theory and in practice
Solana Fees by Umbra Research
Most of the referenced resources are hyperlinked; If I missed any feel free to reachout