⁤Solana stands out in the blockchain ecosystem for its remarkable combination of scalability, speed, and efficiency, quickly becoming a cornerstone for decentralized applications (dApps) developers. ⁤⁤This blog post dives into the intricate workings of Solana's Fee Market, the nuances of Maximum Extractable Value (MEV), and the forward-looking advancements that promise to shape its future. ⁤⁤Our goal is to give you a thorough overview, citing the most recent studies, to shed light on both the limitations and opportunities within Solana.

Introduction to Solana

At its core, Solana is engineered for excellence. Solana uses a unique consensus mechanism called Proof of History (PoH) to achieve high throughput and low latency. This along with several other features make it well-suited for developing dApps, including:

• Smart contracts: Solana supports smart contracts, which are programs that run on the blockchain. Smart contracts can be used to create a wide variety of dApps, such as decentralized exchanges, lending platforms, and prediction markets.

• Low fees: Solana has very low transaction fees, which makes it affordable to develop and use dApps on the network.

• Fast transaction times: Solana can process transactions in less than a second, which makes it ideal for applications that require fast confirmation times.

• Scalability: Solana is designed to be scalable, and it can handle a high volume of transactions without compromising performance.

Solana is still a relatively new blockchain, but it has quickly become one of the most popular platforms for developing dApps. Its high performance, low fees, and scalability make it an ideal choice for a wide variety of applications.

Understanding the Solana Fee Market

Solana's fee market is instrumental in maintaining the network's efficiency and accessibility. It is a system that determines how much users pay to have their transactions processed on the Solana blockchain, which includes two components:

1. Base Fee: This is the minimum charge that adjusts dynamically with network activity levels. It's designed to guarantee everyone can access the network fairly, regardless of how much they're willing to pay. The fee is fixed at 5000 lamports (which equals 0.000005 SOL, or $0.0003 if SOL's price is $60) for each signature, and typically, Solana transactions require just one signature.

2. Priority Fee: This is an optional extra fee you can pay to speed up your transaction, calculated in microlamports based on the computing work you expect it to need. The actual work is only known after completion, but paying more can move your transaction up in the processing queue. Transactions with a higher priority fee are prioritized non-deterministically.

Here is a simple analogy to help you understand the Solana Fee Market:

Imagine you are at a concert and you want to get to the front of the stage. You can either wait in the regular line or you can pay a higher price to skip the line and get to the front of the stage sooner. The Solana fee market is like the line at a concert. The base fee is like the regular line, and the priority fee is like the higher price you can pay to skip the line and get to the front of the stage sooner.

Just like at a concert, the price of skipping the line can change depending on the demand. If the concert is sold out, the price of skipping the line will be higher. The same is true for the Solana fee market. If the network is busy, the base fee and priority fee will be higher.

Solana's fee structure is designed to ensure network sustainability and reward validators. Here's how it works:

• Combined fees: The total fee for a transaction is the sum of the base fee and the optional priority fee (if included).

• Fee burning: 50% of all collected fees are burned, meaning they are permanently removed from circulation, reducing the SOL supply and potentially increasing its value over time.

• Validator rewards: The remaining 50% of the fees are distributed as rewards to the validators as a reward for their role in processing transactions and securing the network.

This balanced approach to fee allocation supports a healthy economic ecosystem within Solana, incentivizing validator participation while ensuring the network remains strong and efficient for users and developers alike.

The Current State of Solana

According to recent data, Solana has experienced a surge in transaction volume of $21.1 million surpassing its other competitors.

Daily Transactions Source: Artemis terminal

The average transaction fee on Solana stands at $0.00025, significantly lower than other leading blockchains like Ethereum. This low-fee structure has positioned Solana as a cost-effective and efficient platform for decentralized applications and smart contract execution.

Solana Average Transaction Fee Source: Dune Analytics

Why Does It Matter?

Understanding Solana's fee market is crucial as it directly impacts the network's performance and user experience. The fee market has several benefits:

• It ensures that the network remains secure and scalable, even during periods of high demand.

• It allows users to control how much they pay to have their transactions processed.

• It creates a competitive environment for validators, which helps to keep fees low.

How Does It Work?

The Journey of a Solana Transaction Source: Paul Timofeev

Solana ensures quick and efficient transaction processing through a well-organized system. Validators, the operators of blockchain nodes, play a key role in this process by validating, processing, and executing transactions directly on the blockchain. In return for their computational efforts, they earn block rewards and transaction fees.

Let’s break down how Solana transactions work:

1. Transaction Creation: A transaction is initiated, for example, by a user or a decentralized application such as Jupiter. This transaction usually involves actions like token transfers or smart contract interactions.

2. Wallet Approval: The transaction is sent to a wallet, such as Phantom, for approval. The user reviews and approves the transaction, confirming their intention to execute the specified actions.

3. RPC Submission: After approval, the transaction is sent to the wallet's RPC (Remote Procedure Call), which acts as a middleman between the wallet and the Solana network.

4. Validator Processing:

   • The RPC submits the transaction to a validator, which are Solana network nodes validating transactions.

   • The validator then forwards the transaction to another validator, which in turn passes it to the leader.

   • The leader, currently elected in the proof of stake system, constructs the current block. Within the validator and leader, there exists a network layer for quick transaction processing, including throttling mechanisms that may result in dropped transactions.

   • Following this stage, the transaction enters the scheduler, also known as the banking stage internally. This can be visualized as the block builder, responsible for organizing transactions into a block, executing them, and transmitting them to the network.

   • The transaction is then queued for execution, with intricate multi-threaded queuing processes involved.

5. Threading and Queuing:

   • Solana's system for managing transactions is designed to handle several at once, thanks to its multi-threaded queuing process. This setup allows it to process and execute transactions in parallel as they come in. However, a transaction might get delayed if it needs to access data that another transaction is currently using.

   • Solana includes lists of data access requirements in its transactions, identifying what data needs to be read or written during their creation. This approach helps in executing transactions simultaneously. While multiple transactions can read from the same data concurrently, only one transaction can modify (write to) a piece of data at any given moment.

https://x.com/blockworksres/status/1651995042083655680?s=20

Uncovering the Complexities of Solana Transactions

Exploring Solana transactions uncovers various challenges and key factors critical to ensuring the network runs efficiently. Here are some of the major complexities of managing transaction fees on Solana.

1. Pricing Mechanism: High demand and limited block space drive up transaction fees, with priority fees becoming crucial for faster processing. Fee increases can be widespread or localized to high-demand events, like DEX promotions. Transactions outside these hotspots may pay lower fees if space permits. However, lowering the limits on how much block space an account can use might restrict these high-demand areas further but could also lead to higher fees across the board.

2. Blockspace failure:

   A significant portion of transactions, approximately 58%, is labeled as failed transactions, attributed to spam, arbitrage transactions, and liquidations. This raises concerns about the inefficient use of blockspace. This highlights the need to reduce spam and improve the efficiency of transaction inclusion.

3. Validator Centralization Concerns:

   There’s a concern about validator centralization, where sophisticated validators can extract more value and attract more stake, potentially leading to centralization. However, the current impact of this centralization force on Solana is considered relatively small.

   A few people making profits from MEV (Maximum Extractable Value) can lead to more control in fewer hands, risking the network becoming centralized. This means one group could gain too much influence, making the network less secure. Unlike Ethereum, where those finding MEV share their earnings, Solana's focus on speed means a few benefit more, keeping most of the profits. This creates a situation where a small number controls a large part of the wealth and power.

Fee Architecture: Block Building Difference on Solana vs Ethereum

Let’s first understand the difference in block building between Solana and Ethereum. On Ethereum, blocks consist of user transactions from the mempool, with an algorithm that orders transactions by gas fees. This leads to gas spikes, with users competing and outbidding each other for inclusion.

In contrast, Solana continuously builds blocks as transactions arrive, with the leader creating and executing blocks in real time. For instance, consider a scenario where a block has already reached its maximum limit of 48 million CU’s. Now, suppose a user attempts to add a transaction to the block that provides a large reward to the validator. This transaction won't be included in the current block because it's already full. Instead, it will be added to the queue for the next block.

This continuous block-building process, as compared to Ethereum's discrete block-building, may lack some assurances. However, it offers advantages like swift user pre-confirmation, not limited by block time.

While short block times aid in quicker confirmation and finalization, the key advantage of Solana lies in its continuous block building, potentially enabling pre-confirmation as fast as a single round trip between the client and the leader.

Solana's Approach to Compute Unit Limits and Priority Fees

Solana enforces per-block (48 million) and per-account (12 million) limits on compute units for transaction computation measurement. These restrictions aim to prevent any single program from dominating block space. Coupled with Solana's default scheduler's multi-threaded design, only up to 25% of transactions within a block can relate to a highly sought-after state. The goal is to ensure that users dealing with less popular states do not need to raise their priority fees significantly for secure inclusion, as compared to users handling popular states.

Source: Dune Analytics

From the data shown, we see the median and average transaction fees on the Solana blockchain network. By comparing these two figures, we can get an idea of the level of demand for priority fees. In other words, it helps us understand how much users are willing to pay to have their transactions processed quickly on the network.

Although Solana aims for a localized fee market, the current setup lacks a genuine local fee mechanism due to issues such as consensus enforcement gaps, non-assured fee inclusion, and fixed resource constraints.

• Block Builder in Solana and Ethereum

  The Block Builder in both Solana and Ethereum has the liberty to propose any valid block. There isn't a rule in consensus that mandates blocks must contain the highest paying transactions. This is purely an incentive for the block builder or the validator.

• Transaction Processing and Priority Fee

  In Solana, as transactions come in, they get queued and a single priority fee can be set on the transaction. These transactions get scheduled for execution and sometimes they might get blocked and have to be re-queued. Transactions with a higher priority fee are more likely to get executed but there are exceptions based on specific circumstances.

• High Contention State and Priority Fee

  For a high contention state (e.g., a popular NFT mint), the priority fee to get in will be higher than for an uncontested state. This is due to the high demand to access that state. But even here, there's no real notion of a market as users don't have an idea of what priority fee to set to get their transaction in.

In recent times, blocks in Solana have seen saturation due to increased activity. This has exposed the downsides of this priority fee mechanism, which can lead to inefficiencies and an incentive to spam.

Probable solution: Need for a Controller Mechanism

A consensus-driven control mechanism for base fees could significantly enhance user experience.

• The first issue lies in pricing the base fee based on signatures, which is somewhat simplistic or optimistic, as a more nuanced approach might be more appropriate. Drawing from EIP 1559, modifying the base fee according to target and maximum utilization may prove to be a viable approach. This adjustment could help alleviate the sudden increase in priority fees during block congestion, thus minimizing inefficiencies in the system.

• The second issue involves the base fee being influenced by CUs. The cost model is used to calculate the number of compute units (CUs) required to execute a transaction. Each CU has a corresponding fee, which is set by the network validators. By multiplying the number of CUs by the fee per CU, the total transaction fee is determined. This ensures that transactions involving these programs are charged fairly and consistently.

• Also, SIMD-110 is a proposal to introduce an exponential fee for write-lock accounts by introducing economic back pressure where it tracks the Exponential Moving Average (EMA) of contentious accounts' compute unit (CU) utilization per block. If an account's CU utilization remains high, the cost to write-lock that account increases exponentially. So, this would discourage spam activities, ensure efficient network resource utilization, and prevent continuous block congestion caused by failed spam transactions.

Maximum Extractable Value

It is crucial to understand the interconnected nature of fee structures and value extraction mechanisms in blockchain networks where traders look for profitable transactions. So, Maximum Extractable Value (MEV) is like an "invisible tax" that validators can levy on users – essentially, the maximum value they can extract from processing transactions when creating a block on a blockchain network.

Solana MEV

Solana's MEV ecosystem is less advanced than Ethereum's, with lower activity and liquidity. Network upgrades aim to prevent spam and penalize bot users, maintaining transaction rates over 4000 TPS.

A competitive MEV extraction landscape is expected with growing network usage. Traders compete fiercely for valuable transactions on Solana, prioritizing speed over fees due to its fast block generation. Accessing the state quickly is vital for successful trades.

Traders and MEV Extraction

Traders use bots to monitor and execute profitable trades. Arbitrage and liquidations are common MEV extraction methods on Solana. Arbitrage exploits price differences across platforms, requiring swift action on low-latency networks like Solana. Profits can be made through numerous transactions daily, not just through arbitrage.

Arbitrage Opportunities and MEV Profits

Arbitrage entails profiting from price differences for the same trading pair across different platforms. A trader's mistake on Solana led to a windfall for arbitrage bots and validators due to a surge in WIF price and a subsequent swarm of bots exploiting the opportunity. While most MEV profits arise from arbitrage transactions, other avenues also exist.

Other MEV Externalities

Sandwich Attacks: When a user sets a high slippage tolerance, bots can force the user to get the worst price that they set. This is done by landing a transaction in front of and behind the user’s transaction, pushing the price to the point where the user gets the worst fill possible. The bot then profits from this.

Back-Running: This usually happens due to poor routing. After a user’s transaction lands, back-running bots equalize the prices among all the different pools that have the same coin, making a profit from that. In theory, this profit could have gone to the user in the form of better execution of the trade.

The Jito - Solana Validator

Jito operates independently from the Solana protocol as a private company supported by venture capital, conducting auctions for blockchain space like Flashbots.

Dedicated to enhancing the positives and reducing the negatives of MEV on Solana, Jito offers a platform for sending grouped transactions (external to Solana) to be processed by validators using the Jito-Solana client.

This setup allows for ongoing block creation, with an auction system that lets transactions compete for space, aiming to streamline transaction handling and cut down on unnecessary data, thus offering a streamlined alternative to Solana's standard block creation approach.

Source: Dune Analytics

From the graph, we can see that users pay validators a tip through Jito to improve the execution of transactions. By measuring the amount of tips paid to validators, one can indirectly assess the potential financial opportunities available on the Solana network.

Applications and MEV

Building on the foundation of Solana's MEV landscape, a key question arises: How can applications leverage these mechanisms to their benefit?

Proposals suggesting fees go to applications rather than validators are considered opinionated and raise questions about the sovereignty of block space and the idea of who owns the contested block space and who deserves the economic benefits. Applications are encouraged to explore strategies that reduce their exposure to MEV:

1. Pool-Based Lending Mechanism: Aave and Compound have implemented a pool-based lending mechanism where external liquidators come in before a position goes underwater for the protocol, preventing the protocol from losing money from bad debt. Initially, this system compensated liquidators with a fixed fee, typically around 5% or 2% of the loan's value.

2. Dynamic Fee Associated with Liquidations: Euler Finance has a lending protocol similar to Aave but with a dynamic fee associated with liquidations. The more underwater a position is, the more incentive you give the liquidators, but that incentive starts very small. This reduces the liquidation bonuses that are paid and results in the validators or the network receiving less of this value, and more of it is kept by the protocol itself.

3. Improvements: The application developers can reduce the amount of leakage to MEV through application-specific measures. However, this hasn’t been studied much on the Solana side because the MEV marketplaces are much less mature and the total amount of MEV is a lot lower.

Future Developments on Solana

As Solana's MEV grows, competition rises, risking decentralization. MEV benefits seekers but threatens protocol sustainability. Centralization looms, but solutions like blockspace auctions may preserve decentralization:

• SIMD O109 proposal suggests adding a built-in tipping mechanism to Solana that allows users to send tips in SOL to the current leader. Since 50% of the Solana network uses the Jito-Solana validator for dynamic tipping based on transaction profitability. This mechanism aims to address the growing practice of out-of-band tipping schemes used by validators to prioritize transactions.

• The upcoming Firedancer update, with its block pre-packing algorithm, will simplify validators' compute unit calculations and block packaging. This enhancement has the potential to strengthen Solana's fee market model. Ethereum's rollup-centric roadmap may not achieve similar efficiency levels due to its fee model and structure.

• The new scheduler design in Solana aims to improve transaction processing efficiency and reduce failed account locking during competitive events like NFT mints or token launches. By efficiently organizing and prioritizing transactions, the scheduler helps in handling transaction congestion and optimizing block production.

• Taking inspiration from EIP-4844, introduced to handle large data amounts not accessible by EVM execution but whose commitment can be accessed. Rollups are vital for scaling Ethereum due to high transaction fees on L1, and data sharding is a long-term solution, but this EIP suggests a temporary transaction format aligned with sharding principles to reduce fees until full data sharding is implemented. Solana could assist in reducing fees for users and addressing MEV concerns by streamlining data handling and transaction processing.

In conclusion, Solana's fee architecture, priority fee system, MEV landscape, and upcoming developments showcase both opportunities and challenges in optimizing network efficiency, user experience, and decentralization. The solutions proposed in this blog post represent just a starting point; together, as a community, we have the potential to conceive and implement many more strategies to navigate and overcome current challenges. By collaborating and sharing insights, we can continue to advance Solana's ecosystem, making it more robust, user-friendly, and decentralized for everyone involved.

References:

• What is MEV and how does Solana solve its MEV issues: Chainstack

• Analyzing MEV Instances on Solana — Part 3: Chorus One

• Jito, the Ruler of Solana MEV: Four Pillars

• MEV on Solana: Umbra Research

• Solana Fee Market: Eclipse

• Latency and Profits: MEV On Solana: Paul Timofeev

• Solana Fees in Theory and Practice: Helius

• Solana's Local Fee Markets Aren't Real: Light Speed

• Solana Fees, Part 1: Umbra Research