Pricing Blockspace on Solana

This has also been cross-posted on Blackhawk Research.

10 min read

Introduction

When Solana launched its mainnet in 2020, it quickly became known as the chain with extremely low fees, presenting an alternative to the high gas prices present on other chains such as Ethereum. Today, Solana continues to offer the lowest gas costs amongst major L1s with a base fee of 0.000005 SOL per signature (approximately 1/100th of a cent).

In a certain light, Solana’s deterministically low transaction fees can be viewed as a successful bootstrapping/growth mechanism for users and liquidity. However, Solana’s deterministically cheap transaction fees can lead to adverse outcomes, particularly with regard to spam during NFT mints, IDOs, and airdrops. Since its launch, Solana has pushed major updates to mainnet to combat these issues including QUIC, stake-weighted quality of service, and local fee markets.

Even with these upgrades, it is unlikely that the current fee structure will work in perpetuity with increasingly economically rational and sophisticated actors entering the space. In turn, the economics of Solana must evolve – particularly around how it prices marginal blockspace – as the chain continues to mature and grow.

In this post, we will offer a comprehensive analysis of the current blockspace pricing mechanisms on Solana, examine the upgrades under active development, and propose different on-chain and off-chain strategies Solana could employ to achieve more accurate blockspace pricing.

Gas

Why Gas is Needed

The purpose of gas is to accurately price the current value of decentralized trust – the specific value of blockspace at a particular point in time – between two major stakeholders: trust suppliers (stakers/validators) and trust consumers (decentralized applications). Gas (fees) is needed for public blockchains to prevent spam and allocate scarce resources.

Credit: EigenLayer

Ethereum pioneered this concept of modular trust and was the first implementation of this new paradigm with its launch in 2015, allowing trust and innovation to be decoupled – Ethereum supplies the trust while the decentralized applications bring the innovation.

Gas on Bitcoin and Ethereum

Most blockchains (not Solana) work by having a mempool representing the transactions waiting to be included in future blocks. In order to express higher desire for inclusion, users participate in a priority gas auction (PGA). Typically, this manifests in a bidding/auction mechanism that allows users to express higher economic desire by paying more for inclusion in the next block. This leads to gas spikes, with users competing and outbidding each other for inclusion.

Gas (Fee) Architecture on Solana

Unlike most other blockchains, Solana does not have a mempool. Instead, pending transactions are sent to current and future block leaders via a protocol known as Gulf Stream. This pushes pending transactions to the edge of the network (validators executing state transitions, not a central mempool), with validators sending each other packets of transactions to execute.

Side note: RPCs can either send transactions directly to the assigned leader or indirectly via a different validator who then forwards those transactions to the current leader.

At a high level, Solana (without Jito, which we will cover later) uses first-come, first served (FIFO)/fair ordering to order transactions with some additional parameters including a priority fee to incentivize validators for inclusion.

Solana’s transaction fees consist of two components: base fees and prioritization fees.

Transaction inclusion graphic showing base fees, prioritization fees, and stake-weighted quality of service

Base Fees

The base fee is a statically set amount of 0.000005 SOL per signature (there is typically 1 signature per transaction). 50% of the base fee goes to the validator, while the other 50% is burned.

Prioritization Fees

These are optional fees set by the client (or by the wallet on the client’s behalf) that non-deterministically improve one’s transaction of being included in the block. Priority fees are calculated based on the expected compute usage (called “compute units” on Solana). Approximately 30% of non-voting transactions include priority fees.

Rational validators are incentivized to include transactions with priority fees as they are able to capture 50% of the total priority fee set by the client (the other 50% is burned).

However, this fee structure is not incentive compatible. Because 50% is burned, this incentivizes outside of protocol deals to be struck, with clients paying anywhere from 51-99% of the would-be priority fee directly to the validator, sidestepping the protocol-enforced burn mechanism. This would favor larger parties with deal infrastructure available to implement such mechanisms.

In practice, there is a JSON RPC endpoint that presents the recent prioritization fees paid that utilizes recent data as a proxy for current prioritization fees.

Stake-Weighted Quality of Service

Validators have limited bandwidth for receiving incoming packets for eventual block inclusion. Previously, this traffic was handled indiscriminately, making it relatively easy for validators to be spammed from outside sources.

Stake-weighted quality of service builds on QUIC and reserves pro-rata bandwidth rights for other validators based on stake weight (percent that a validator’s stake in the network represents). Slot leaders (validators assigned to that block) can then process transactions propagated from other validators based on their stake-weight first.

In practice, this means that pending transactions forwarded by other validators to the current slot leader are more likely to be included in blocks than any other incoming transactions. The logical consequence of this design is that RPC providers that do not have any stake themselves are incentivized to strike side deals with the larger validators. This is a centralizing force as it creates a network effect around large validators, who are able to solidify their position in the ecosystem because of their greater initial stake. Furthermore, those validators are also able to censor the incoming transactions to their liking (though this may not be optimal for them in the long-run).

Local Fee Markets

On Solana, one must express all the state that a given transaction touches and whether or not it is read/write. While this makes the developer experience more tedious, this allows Sealevel (Solana’s parallel smart contract run-time) to more efficiently process transactions as it is able to parallelize execution of transactions that do not touch the same state via simple locking mechanisms. Optimizations are handled at the virtual machine level – the SVM knows that reads can overlap (any number of transactions can read the same state) but writes cannot overlap (as they might depend on changed state).

In turn, hotspots can be created on a per-account basis, individually pricing state accordingly. Solana is effectively operating many intra-block state auctions per account for a given block. This is a new paradigm compared to other networks such as Ethereum/EVM which have global fee markets due to their purely sequential nature -- a consequence of transactions having read/write access to the entirety of global state.

Jito

Adjacent solutions such as Jito are not enshrined in the Solana protocol but have first and second-order effects on gas and MEV.

Jito is a private, venture-backed company that exists outside of the Solana protocol that runs a Flashbots-style out-of-protocol blockspace auction. They are one of the few teams on Solana with the specific mission to maximize the benefits while minimizing the negative externalities of MEV.

Jito provides the infrastructure for searchers to send transaction bundles (outside of Solana), which is then forwarded to validators running the Jito-Solana validator client.

Currently, the percent of the Solana network using Jito (~25%) is significantly less than the percent of the Ethereum network using Flashbots (~90%+). Some possible explanations for this include:

• Validators are not currently maximizing MEV rewards (unlikely to be the case network-wide).
• Validators are striking direct side deals with searchers and private order flow, siloing and internalizing MEV (also unlikely to be occurring at scale).
• Jito is a newer team with less social capital/trust and more validators will opt-in as Jito gains trust. Flashbots historically has had closer ties with the Ethereum network and has been around for longer.

Additional Thoughts and Considerations

• Dynamic pricing for blockspace (on a per-block, per-account basis) allows the market to find a maket-clearing price at a given point in time, achieving a more stable long-term equilibrium.
• Comparing relative block times and latency with respect to Ethereum and Solana is difficult as the Solana client builds and propagates blocks (or partial blocks known as shreds) continuously by default. On Ethereum, these are actually proposed as an atomic unit of a block. Regardless if you have 400ms block times or 12 second block times, the marginal time determined by co-location eventually comes into play. A recent paper demonstrates proposers on Ethereum would on average earn $10/second playing the timing game and delaying the proposing time. Attestation deadlines can serve to alleviate some of the negative externalities. Multiple concurrent block producers (we will explain this in a future post) can also help reduce the impact of co-location and latency.
• 58% of Solana’s compute is on failed transactions (60% of transactions are arbitrages, 98% of those transactions fail). This means that spam is incentivized – leading to a network-wide negative externality in the form of congestion/wasted blockspace – as it is positive expected value to spam the network in hope of inclusion (the value of the transaction that lands will pay for the gas costs of the others).
• Arbitrum recently faced similar spam challenges where searchers spammed the Arbitrum sequencer in hopes for an early slot in the block update. The current proposal includes priority fees, with a similar implementation to Solana’s priority fee mechanism.