Quantifying the Impact of Compute Units on Solana Validator Rewards
Special thanks to Michael Hubbard at SOL Strategies, Max Sherwood at H2O Nodes, cfl0ws at Chainflow, and David Liang at Figment for reviewing earlier drafts of this research.
Actionable Insights
Raising the per-block Compute Unit (CU) ceiling from 50 M → 100 M (proposed in SIMD-0286) could add ≈ 0.0575 SOL in fee rewards per block for validators that consistently fill the additional block space.
The top ten validators on Solana, in terms of stake weight (≈ 21% of active stake), each produce 3k – 8k blocks per day. Assuming block production rate stays constant, they stand to gain an additional:
≈ 172 – 460 SOL daily
≈ USD 28.7k – 76.8k at 2025-06-11 prices
Despite these potential rewards, CU consumption explains only ≈ 2% of fee-reward variance; order flow, network congestion, and stake weight likely remain larger drivers.
Although current CU utilisation rates are similar across the majority of validators regardless of active stake (78-82% utilisation), this may change with a 100% increase in the CU limit, giving an advantage to well-resourced validators that can fully monetise the expanded block space, and potentially increasing the risk of centralisation.
Introduction
One of the most prominent debates in blockchain economics is block size (measured as gas limit in Ethereum, and Compute Units (CUs) in Solana). It modulates a number of things, including: speed of execution, aggregate activity that can be supported in a single block, what users pay at a given level of aggregate demand, and what validators (supply side) earn.
Recently, there have been multiple Solana Improvement Documents (SIMDs) proposing to increase the CU limit that is enforced for every block. The most recently implemented proposal was SIMD-0207, raising it to 50M CUs per block. With the recent release of Agave v2.2, this will be raised again to 60M (SIMD-0256) pending feature gate activation, and there is already a proposal to further increase it again to 100M CUs (SIMD-0286). The obvious question, and the one we answer here is:
If Solana lets validators produce blocks with twice the CUs, how much more in block fees can they earn?
Background
What are Compute Units?
Solana compute units (CUs) are a measure of computational effort required to execute a transaction or a portion of a transaction on Solana. They can be thought of as similar to gas on Ethereum. Their key features are:
Every instruction within a transaction uses a number of compute units.
The more complex an operation (a large loop, signature verification, or interacting with many accounts), the more CUs it consumes.
There are agreed limits imposed on how many CUs can be consumed by transactions in a single block. The current limit is 50M CUs.
The priority fee, paid by a user to incentivize inclusion of their transaction, is directly tied to the amount of compute units the transaction consumes.
Priority Fees & the MEV Supply Chain
Priority fees, calculated as computeUnitLimit * computeUnitPrice, allow users to incentivize validators to include their transactions in the blocks being produced. The more competition there is for block space, the more parameters like computeUnitPrice tend to increase. These fees can be adjusted by users, particularly when guaranteed inclusion is critical, as it is in many MEV strategies.
While Jito tips represent the most visible MEV revenue for validators, significant MEV also flows through priority fees from transactions submitted via private RPCs and direct connections, bypassing the Jito auction entirely.
Dataset & Preparation
We sourced metrics from our Solana Block Insights endpoint, aggregated over a 3,000 slot interval (≈ 20 min) to strike a balance between single‐block noise and daily over-smoothing. Each interval record includes:
Average CUs per slot
Average block fee rewards (base fees + priority fees)
Base Fees - Fixed at 5,000 lamports per signature for a transaction. Most Solana transactions have just one signature.
Priority Fees - An adjustable fee paid by the signer of the transaction to improve the probability of inclusion. Directly influenced by CU consumption.
We analyzed 1.2M intervals from epoch 749 to epoch 786 (February 28 to May 14, 2025) where validators successfully proposed blocks, excluding 5.3M intervals with zero compute unit usage (interval periods in which a given validator did not successfully propose blocks).
Analysis
To quantify the relationship between compute‐unit consumption and block fee revenue, we first fit an ordinary least‐squares regression of average fee rewards on average Compute Units and visualised a 10% random sample of intervals (Figure 1). This regression shows that each incremental CU is associated with ≈ 1.15 lamports of additional revenue, or 0.00115 SOL per million CUs.
To contextualize this: for a validator producing 1,000 blocks per day (≈ 1.83M SOL in active stake), completely filling blocks from 50M to 100M CUs would generate an additional ≈ 57.5 SOL daily (USD 9.6k). This assumes both the ability to source additional high-CU transactions and that the linear relationship holds at higher CU levels.
While the network has previously reached CU capacity limits—indicating demand could potentially scale to utilize 60M or 100M CUs per block—increased block space supply may outpace demand growth, resulting in lower per-CU pricing. Even if validators successfully utilize the full capacity of larger blocks, the marginal revenue per additional CU may decline due to this supply-demand imbalance.
However, this incremental effect alone explains just ≈ 2% of the variance in fee rewards. The low explanatory power of this model exposes that, while CU consumption does influence fee rewards, other factors such as block congestion, order flow, and stake size, to name a few, are likely to be more influential.
Figure 1: Compute Units vs Block Rewards
To guard against overfitting, we measured out-of-sample performance via:
5-fold cross-validation (random splits): mean R² = 0.018 with a standard deviation of 0.004 across folds.
Group-validator cross-validation (holding out entire validators): mean R² = 0.022 with a standard deviation of 0.009.
This shows that the effect generalises across random segments of the dataset, as well as across different validators held out from the training dataset. A validator-cluster bootstrap of the OLS slope (300 resamples) yielded a 95% confidence interval of [1.11 - 1.19] lamports per CU. Together, these findings support the practical rule-of-thumb that each additional CU is associated with approximately 1.15 lamports of fee revenue.
Compute Unit Deciles
The linear regression provides a strong starting point, but it doesn’t answer whether rewards per CU change at higher or lower levels of consumption. Examining mean rewards by deciles of CU consumption (Figure 2) reveals a broadly positive trend, supporting the incremental effect estimated by our regression.
Each decile contains approximately 120,000 observations from 1,300+ unique validators, ensuring robust statistical power and broad representation across the validator set. The standard errors are extremely small (< 0.0003 SOL) due to our large sample size of ≈ 120k observations per decile, making the error bars too narrow to see on this graph.
Figure 2: Mean Rewards by Compute-Unit Decile
However, the relationship is not strictly monotonic: rewards peak at decile 4 before dipping in deciles 5-6 and then rising again. This subtle nonlinearity highlights potential complexities in fee dynamics (bidding competition or network congestion effects at certain compute usage levels), which our linear model can't fully capture.
Distribution of CUs per Block
Stepping back, to look at the distribution of our dataset, we can see that validators cluster around ≈ 40–45M Compute Units (Figure 3), near the current cap of 50M CUs. This suggests most validators already fill blocks aggressively. This tight clustering limits the variation needed to explain rewards using Compute Units alone, but it also raises the question: Why are approximately 19% of blocks consuming fewer than 35M CUs?
Figure 3: Distribution of Average Compute Units
Validator Performance or Fluctuating Demand?
Two explanations worth exploring for why some blocks are not filled to capacity are:
A subset of inefficient validators are responsible for producing blocks with fewer CUs.
Fluctuating network demand produces periods in which the supply of high-CU transactions contracts, making it more difficult for validators to fill their blocks.
Figure 4: Distribution of Compute Unit Utilisation by Validator Stake Decile
Although some validators do produce more low-CU blocks than others (a low-CU block is defined here as consuming fewer than 35M CUs), all validators in our dataset had intervals over which their blocks consumed, on average, less than 35M CUs. Additionally, the correlation between CU consumption and active stake was negligible (0.094) suggesting that larger stake does not translate to higher CU blocks. In fact, as shown in Figure 4, the weighted average of CU consumption varies minimally (78.4-81.6%) across validator stake deciles.
Figure 5: 7 Days Compute Unit Usage with Per-Interval 25th-Percentile Envelope
The answer to the question of fluctuating demand is clearly demonstrated in Figure 5, showing average CU consumption across 3,000 slot intervals over the course of a week with a line highlighting the 25th percentile. Daily boundaries (UTC) clearly show cyclical demand spiking during US Eastern Time working hours (≈ 08:00-18:00). For validators, this means there will be periods where the supply of high-CU transactions will fall, and competition to produce more profitable blocks will increase.
Conclusion
While Compute Units explain only a small portion of the variation in block fee rewards, R² (≈ 2 %), the average effect remains robust and economically meaningful. Validators utilising the full capacity of a 100M CU limit stand to gain an additional 0.0575 SOL per block they produce. However, fluctuations in daily demand on the network means that validators face periods of increased competition for high-CU transactions, during which it is difficult to produce more profitable blocks.
Finally, as Solana pushes toward higher CU limits, validators face mounting operational challenges that could accelerate centralisation. Doubling the CU limit from 50M to 100M CUs isn't just a configuration change—it likely demands significant infrastructure upgrades, and may motivate more sophisticated transaction ordering systems, and deeper liquidity relationships to source high-value order flow. Our analysis shows that while most validators on average currently achieve similar CU utilization rates (78-82% of capacity), this equilibrium may not hold at higher limits.
The validators best positioned to capitalize on increased CU limits will be those who can:
Monitor and optimize their CU efficiency
Identify periods of high-CU transaction availability (as shown in Figure 5)
Benchmark their performance against peers to identify optimization opportunities
Track which transaction types and sources yield the highest returns per CU
As higher CU limits both increase operating costs and block rewards, having visibility into these performance metrics transitions from useful to critical for maintaining competitiveness.
—
At Rated, we provide Solana validators with granular metrics on CU consumption, block rewards, MEV flows, and other competitive benchmarking data. Our recently launched Block Insights endpoint is only one of the many tools we have built to help you understand and make better decisions about blockchain infrastructure. Learn more at rated.network/apis and docs.rated.network.
Ready to get started? Reach out to us at hello@rated.network or feedback.rated.network so we can further help you.
