Fee Economics, Spam Reduction, and MEV on Solana
Notes on Optimizing the Blockspace Allocation Dilemma
The current state of fee economics on Solana is unoptimized and partially arbitrary, which means there’s plenty of room for optimization and innovation. Solana is a proof-of-stake network and validator nodes are the heart of the blockchain. Validators process transactions and construct blocks continuously, allocating and organizing blockspace.
Validators primarily run the native Solana and Jito-Solana client, with Firedancer just beyond the horizon. As an incentive for validators to offer their compute resources, half of transaction fees are rewarded to validators while the other half is burned. Fee rewards are given to the leader, which rotates every four blocks. Currently, fees on Solana are comprised of two parts:
Base Fee: a fixed value at 5000 lamports per signature, used as a baseline for compute resources and blockspace.
Priority Fee: a variable fee “tip” that users can submit with their transaction in hopes of increasing the likelihood of their transaction landing on the next block
Fees are simply a way for people to pay for blockspace. In an ideal system, there is harmony between transaction costs, and transaction quantity per block. Blockspace is a finite resource in which priority inclusion has variable utility to people at different times.
Thinking like a Validator
What does continuous block production look like? If you are a validator building continuous blocks, you have finite blockspace and want to consider transactions as they come in. Suppose your queue is empty to begin with and a transaction that pays a low fee comes in. Since that’s the only transaction in, and we are building continuously, the scheduler chooses a thread at random for the transaction and we process it and include it in the block.
Suppose at one slice in time, there’s three threads that contain one small transaction without priority fees each. Now a high priority fee transaction comes in. The scheduler may randomly choose one of the three threads and not the one empty thread to queue the transaction. Now, three simple transactions have been added to the block, and the high priority fee transaction is likely to be included in the block but is not guaranteed to be first in the ordering.
This is a contrived example, but illustrates the state of transaction processing by validators and the incentive for spam over paying priority fees because of the non-determinism of the latter. Furthermore, it is clear that continuous block production without receiving the entirety of fees is sub-optimal for the validator. As a MEV searcher, it is strictly more advantageous to discretize block building and being able to wait for more information before deciding the construction and ordering of the next block.
CU Pricing
On Solana, blockspace is measured in Compute Units (CUs). There is a 48M CU limit per block, with a 12M CU limit for a single account write within a block. This theoretical limit exists because there are four threads, and two transactions accessing the same state would have one write-locked into a future execution cycle.
In the current state of fee markets, the base fee represents payment for these CUs. However, since the base fee is fixed, transactions that request a high allocation of CUs pay the same base fee as transactions that request low allocation of CUs, and transactions that use high amounts of CUs pay the same as transactions that use low amounts of CUs. This creates an environment where there is no incentive to accurately estimate your CU usage when sending transactions and results in overestimation and inefficient block construction.
Solana vs Ethereum
A famous criticism of Ethereum is its high gas fees to process transactions in times of peak demand. This is due to a global fee market on Ethereum. Different smart contracts that have nothing to do with each other all compete for the same blockspace. If there is a high demand NFT mint, the increased competition and increased priority fees bleed into the entire Ethereum ecosystem, raising prices for everyone, even if their transaction involves a low-demand smart contract.
Solana is able to maintain a low median fee due to localized fee markets at the program level. An anticipated NFT mint on Solana would see transaction fees increase for transactions that involve a certain program and leaves other transactions unaffected. This causes spikes in maximum and average fees paid during peak demand, while keeping the median fee relatively low.
On Ethereum, 100% of the base fee is burned, while 100% of the validator tip is rewarded to the validator. In comparison, Solana’s 50/50 burn/reward model incentivizes validators to take tips in off-chain agreements.
Network Performance
Solana’s priority fee is non-deterministic, meaning paying a higher priority fee does not guarantee that your transaction will be included in the next block nor the order if it is included.
In a previous example, we saw how small, cheap transactions were able to beat out a high priority fee transaction in block ordering just by reaching the scheduler first. This is apparent in the vast majority of failed arbitrage transactions that consume a majority of compute resources. With current fee economics, arbitrageurs are incentivized to spam transactions because of the low cost of failure.
User Experience
I think it can be universally agreed that users want cheaper fees. During peak demand, it is not hyperbole to be paying $20 on a $50 transaction on Ethereum. Furthermore, users want predictable fees and a system where paying more deterministically increases their likelihood of block inclusion.
The type of user also varies along with the expected experience. A regular person trying to send money to their family in a different country has a different expectation of their transaction going through than the co-located arbitrageur who expects the majority of his atomic arb transactions to fail.
Validator Incentives
Current validator incentives are half of both base and priority fees. For validators that run the Jito-Solana client, they earn 100% of the Jito reward. The Jito client discretizes block building into auctions where transactions are gathered and fees carry more weight as the validator has time to evaluate more transactions against each other to find the optimal structure of the block.
MEV on Solana
Maximum Extractable Value (MEV) is not as mature on Solana as Ethereum due to continuous block building architecture. MEV comes from the ability of the leader to rearrange the ordering of transactions within the block. Without discretized wait times, validators are forced to build the block sub-optimally with the least possible information in exchange for speed.
MEV searchers run nodes to read the state of the entire network. To be the fastest reader, it’s valuable for them to run nodes with a large stake or to read from a validator with a large stake because of the state distribution mechanism. Ultimately, top validators and top MEV searchers will become one and the same due to the latency advantage.
When a searcher identifies an advantageous opportunity, they can send transactions to execute. Of various strategies, they can spam a large amount of transactions in hoping a few land, they can attach an attractive priority fee to increase the likelihood of inclusion and ordering non-deterministically, they can send transactions to a Jito-bundle auction, where fees carry more weight, or they can send out transactions optimistically for opportunities that do not manifest yet but could.
Multidimensional Markets
The idea that fee markets on Solana are localized is true to some degree. Increasing dimensionality of markets reduces the size of localities. For example, in a unit square, if a theoretical local fee market consumes one quadrant, a quarter of the total market, adding another dimension reduces the market to one eighth of the total market. This allows for higher specificity and increasingly local markets.
Example: Suppose men and women pay different fees. When lots of women are trying to execute transactions, their fee market is localized and the fee that men pay is not affected. Then suppose we consider men and women who either are tall or short. Now, if short women express high transaction demand, neither men nor tall women are affected by higher fees. By adding dimensionality, we increase the fidelity of localization and prevent peak demand price shocks from spilling into unintended markets.
On Solana, we have the dimension at the program level. Due to the architecture for parallelized execution, transactions specify which accounts they write to, which locks that account, and overlapping transactions are queued to be executed in a later cycle. Adding dimensionality for accounts will further localize fee markets and charge users for state access of write-locked accounts.
Proposed Solutions
For the various problems and incentive misalignments with the current fee market implementation, there have been several ideas that may fix some issues.
Dynamic Base Fees: A variable base fee that depends on CUs to properly price different transaction resource usage. Increasing the base fee would likely keep payment transactions relatively stable but make things like CLOBs more difficult to implement as repeated update transactions would be much more expensive.
Dedicated Block Space for Privileged Transactions (Votes): One type of mandatory transaction in blocks are vote transactions. Validators pay for their vote transactions which has a higher relative cost for low-stake validators as the fee is fixed and the rewards are stake-weighted.
A New Scheduler: Validators run four non-vote processing threads for transactions. The current implementation of the scheduler receives transactions and randomly assigns them to one of the four threads, each of which has its own queue. This introduces scheduler jitter that non-deterministically impacts the inclusion and ordering of submitted transactions based on its relative importance in the thread that it lands in. It is important to note that changes to the scheduler logic should be scalable with the number of threads used in transaction processing to keep hardware scaling viable in the future.
If the scheduler has access to write-locks on a thread level, it can make sure that un-parallelizable transactions are not dispersed between multiple threads and clogging up the verification pipeline.
Some may propose a greedy algorithm scheduler for Priority Fee/CU ordered by ascending block size will incentivize accurate estimation of CUs, but now prioritizes small transactions over large ones, possibly significantly increasing the delay for large transactions only.
Conclusion
The state of fee markets on Solana is not yet mature and there are plenty of unoptimized sections in the lifetime of a transaction and validator logic. Ultimately, disincentivizing spam and making the priority fee more deterministic is paramount for better fee economics.
An overhaul of the fee economy is complicated and is a heavy lift with untested effects on the validator economy and user experience. However, certain incentive alignments and low-hanging fruit can be solved and make Solana fee markets make more sense to everyone and incentivize rational and predictable behavior from validators and users.
More Resources
Umbra Research: “Lifecycle of a Solana Transaction”, “MEV on Solana”, “Solana Fees, Part 1”, “Toward Multidimensional Solana Fees”