Introduction
Fee mechanisms are an important feature of blockchains. Network maintainers like validators have finite resources, so it’s important to charge for scarce resources in a way that reflects cost to the network. Fees also create incentives for participants of the network, such as users, application developers, and validators.
In this series, we will explore Solana’s current fee mechanism, formalize the design space for a fee mechanism, and analyze some proposed changes to Solana’s fee mechanism.
This piece is the first in the series. Here we explain how Solana’s fees work today, focusing on transaction-based fees.
Definitions
These are Solana-specific definitions required to understand the fee mechanism.
Signature: at least one, and usually exactly one included per transaction.
Lamport: the smallest atomic unit of SOL. 1 SOL is equal to one billion (10^9) lamports.
Compute unit (CU): a unit of compute, per Solana-BPF instruction, intended to approximate the cost to execute the instruction. Similar to gas units on Ethereum.
CU used: the number of compute units used to execute a transaction. Only known post-execution.
CU requested: specified by the transaction; if the transaction exceeds this compute budget during execution, execution halts and the transaction fails. The maximum CU requested (and used) per transaction is 1,400,000 CUs.
Account:a single piece of state on the Solana blockchain.
Scheduler: the continuous block building mechanism, included by default in the Solana client built by Solana Labs.
Solana’s Fees
Transaction Fees
Today, a Solana transaction includes two fees: a base fee and a priority fee.
The base fee is fixed per signature at 5000 lamports (0.000005 SOL, $0.0003 at $60/SOL) per signature; the vast majority of Solana transactions have one signature.
The optional priority fee is specified in the transaction, and is denominated in microlamports per CU requested. Note that this is not per CU used, because CUs used is not known until a transaction is executed. Transactions with higher priority fee are non-deterministically prioritized by the scheduler. The specific mechanism is described in Lifecycle of a Solana Transaction.
Fees are debited from the fee payer at the beginning of transaction execution. If the payer cannot pay the required fee, execution is skipped, the transaction is deemed invalid, and is not included.
For both the base fee and priority fee, 50% is kept by the leader as an incentive to include transactions in blocks, and 50% is burned.
In this example transaction, the transaction requests 600,000 compute units, and sets a priority fee of 2500 microlamports per CU requested. Because the transaction has one signature, the total fee for the transaction is 5000 lamports + 600,000 CU requested * 2500 microlamports / CU requested = 6500 lamports, or 0.0000065 SOL.
State Fees
Solana additionally charges a fee to create new state called rent exemption (legacy term). The current cost of rent exemption is a static 6.96 SOL per MB. When a new account is created, the fee is assigned to the account; when the account is removed, its rent exemption fee can be recollected.
Commentary
Incentives for Efficiency
Because the base fee is not sensitive to CU used or CU requested, there is no incentive on the base fee to optimize compute usage, nor to request CUs close to how many are actually used. In practice, many transactions on Solana request far more CUs than end up being used. This creates inefficiencies in the scheduler.
In the above example transaction, the transaction requests 600,000 CUs but uses less than 250,000.
While the priority fee does include an incentive to reduce CUs requested and therefore CUs used, this incentive is weak most of the time and only comes into effect during times of congestion. One simple modification would be to expand the base fee to also require a fee per CU requested. This would incentivize developers and transaction senders to reduce their compute usage, and request only the resources required.
Incentive Compatibility
A mechanism is incentive compatible if all participants in the mechanism achieve their best outcome by acting according to their true preferences. In the context of a fee mechanism, this means roughly that the validator maximizes fees by running the default block building algorithm, and that transaction senders maximize welfare by submitting transactions with priority fees according to their true willingness to pay.
Solana’s fee mechanism is not incentive compatible for validators and transaction senders today. As described above, 50% of the transaction fee is kept by the leader and 50% is burned. Because not all of the fee goes to the leader, this creates an incentive for a transaction sender to collude with the leader: instead of specifying a priority fee to get priority inclusion, the sender can instead create a side deal with the leader to pay the priority fee out-of-network, cutting out the burn while still receiving priority.
Validators running such a mechanism in theory receive more fees and thus can offer higher rewards to their delegated stakers, creating a centralizing force.
Besides direct vertical integration, the main way we see this side deal in the market today is through Jito auctions. Validators running Jito-Solana (a modification to Solana Labs’ client) break the continuous block building mechanism, running a blockspace auction in the first half of their slots.
We have not observed other such side deals in the market today. This is because:
- The validator client and its scheduler are difficult to modify, so the cost of creating such an arrangement requires a high fixed cost. Out-of-protocol software like Jito-Solana and delegated block building arrangements like PBS on Ethereum amortize the fixed cost across all participating validators.
- The vast majority of validator revenue comes from inflationary rewards, not transaction fees, so the benefit is relatively low.
Local Fee Markets
Unlike most other blockchains, Solana requires transaction senders to specify which pieces of state are required to execute the transaction. This unlocks parallel transaction execution and localized fee markets, where different pieces of state have different fees based on how contentious a particular piece of state is. A localized state hotspot does not need to increase contention or fees across the entire blockchain.
One common misconception about Solana is that it features local fee markets today. While it is the case that a transaction that pays higher priority fee is more likely to get included higher in the block, and that contested state is likely to require higher priority, this behavior is non-deterministic and a result of the implementation of Solana’s default scheduling algorithm. We explore this more in Lifecycle of a Solana Transaction.
In particular, this behavior is not enforced by consensus, and deterministic ordering by priority fee is not guaranteed, either by consensus or by the scheduler implementation. Solana’s continuous block building and block propagation prevents deterministic ordering, unless large changes (e.g. deterministic ordering and asynchronous execution) are implemented.
A consensus-enforced, predictable base fee for state access, based on historical contention, could improve efficiency and UX for accessing highly contested state. This would increase the cost of spam, while additionally incentivizing transaction senders to lock the minimal amount of state they actually require. It would not address the root cause of spam, which comes from continuous block building (so latency is important) and jitter. We will explore this design later in this series.
Externalities
Because transactions are primarily ordered by when they reach the leader (scheduler), and this order is subject to both network jitter and jitter due to the parallelized scheduler implementation, there is incentive to spam transactions when the sender wants one to be included as quickly as possible. Such transactions bring a negative externality on the network in the forms of spam landing on-chain (as of January 2023, 58% of Solana’s on-chain compute is used on reverting transactions) and spam reaching the leader.
From Jito Labs
Conclusion
In this piece, we described how Solana’s fee mechanism works today, and its implications on the network. We have hinted at some properties that an ideal fee mechanism would satisfy, such as accurate hints to the scheduler (CU requested), incentive compatibility, and true localized fee markets. In the next piece, we will define a formalism for the goals the fee mechanism should optimize for. This will be used to analyze the current fee mechanism, as well as proposed modifications to the mechanism, with more rigor than has been expressed here.
To collaborate with us, please reach out to collaborators@umbraresearch.xyz.