Introduction

SOL value accrual has come into focus in recent months. The issue has two sides: how SOL tokenholders can capture more value from Solana’s rising network activity, and whether Solana should accelerate the path toward the 1.5% terminal inflation rate to avoid unnecessary issuance. Since SIMD 96 redirected 100% of priority fees to block producers, the SOL burn has become insignificant. At the same time, issuance remains the dominant source of staking yield, diluting unstaked SOL holders and leaving tokenholder economics heavily dependent on inflationary rewards.

This report looks at the current state of SOL net emissions and tokenholder value accrual, with a focus on three proposals that could improve SOL economics: SIMD 547, which would introduce a resource-based burn; SIMD 550, which would accelerate Solana’s path to terminal inflation; and SIMD 123, which would enable in-protocol priority fee sharing. We also estimate how much burn SIMD 547 could generate under current activity levels and future scaling scenarios and discuss why execution remains the key risk to this roadmap.

SOL Net Inflation: Emissions vs. Burn

SOL follows a fixed disinflationary emission schedule. The network’s inflation rate was initially set at 8%, declining by 15% per year until reaching a terminal rate of 1.5%. As of May 31, 2026, SOL inflation is approximately 3.8%.

Historically, Solana has gone through two major fee-burn regimes: before SIMD 96 and after SIMD 96.

Before SIMD 96, 50% of transaction fees were burned and 50% were paid to the block producer. This meant that when priority fees rose during periods of congestion or elevated activity, SOL tokenholders directly benefited through a larger burn.

SIMD 96 changed that. Passed through validator governance in May 2024 and implemented in February 2025, SIMD 96 removed the burn on priority fees and redirected 100% of priority fees to block producers. Importantly, 50% of base fees are still burned, but base fees are so small that the burn has become economically insignificant.

The impact of SIMD 96 is visible in the data. In Q4 2024 and January 2025, Solana was burning more than 10,000 SOL per day during periods of elevated onchain activity. Since SIMD 96 was implemented, the burn has fallen to roughly 700 SOL per day. 

As an important note, the original goal of SIMD 96 was to discourage out-of-protocol transaction-inclusion arrangements and create a more level playing field for independent validators. But the change also produced two major side effects: (1) higher net inflation and (2) lower value capture for SOL tokenholders.

SIMD 96: Unintended Consequences

The first impact of SIMD 96 was higher net inflation. Before its activation, priority fee burn had become a meaningful offset to SOL issuance, peaking at roughly 23% of monthly emissions in January 2025. Across 2024, the average monthly offset was closer to 8%, with Q4 running meaningfully higher due to elevated onchain activity.

This was especially relevant because SOL inflation was higher at the time, falling from roughly 5.6% at the start of 2024 to around 4.8% by January 2025. Put simply, the burn was offsetting a meaningful amount of issuance when SOL’s issuance burden was still materially higher than it is today.

The second impact was on tokenholder net income. Before SIMD 96, 50% of priority fees were burned. That burned portion accrued economically to all SOL tokenholders through supply reduction, while the remaining 50% accrued to the validator. After SIMD 96, 100% of priority fees accrued to the block producer, with no in-protocol mechanism to share those fees with stakers.

This is where SIMD 123 becomes important. SIMD 123 would create an in-protocol mechanism for validators to share priority fees and other block rewards with stakers. We argued as early as December 2024 that SIMD 123 should be activated in tandem with SIMD 96 for exactly this reason. But 18 months later, SIMD 123 still has not been activated on mainnet.

Many large validators, including Helius and Jupiter, already share priority fees with stakers through third-party mechanisms, often via Sanctum-supported LSTs such as hSOL and jupSOL. However, these arrangements are validator-specific and harder to track than in-protocol revenue sharing. As a result, most staking revenue analysis still excludes priority fees from staker revenue.

That helps explain why tokenholders’ share of Solana REV has fallen sharply, from 68% in January 2025 to 27% today. As mentioned, the true figure is likely higher because many validators share priority fees with stakers through third-party mechanisms, but those flows are difficult to track without an in-protocol standard.

SIMD 123 would be a favorable tailwind for SOL tokenholders because it would allow priority fees to be shared in protocol. However, it still has dependencies before activation, including SIMD 232 and SIMD 291, both of which come with their own prerequisite work. 

SIMD 232, which would allow validators to specify custom commission collector accounts, remains in review, while SIMD 291 is pending testnet activation on Agave 4.1 per Anza’s feature gate tracker. 

SIMD 547: Resource-Based Fee

SIMD 547 proposes a new resource-based base fee that is fully burned. The burn would not be tied to priority fees, as it was before SIMD 96. Instead, it would be tied to the cost units requested by each transaction. Cost units are broader than compute units alone, incorporating compute, data loaded, write locks, heap, and other resource inputs.

The mechanism proposed by Temporal, though still subject to discussion, is to charge and burn a fee per requested cost unit. The simplest version starts at 0.1 lamport per requested cost unit, but Cavey has since noted that the parameter could reasonably fall in a 0.1–1.0 lamport range, with 0.25 lamports as a possible starting point. Cavey also floated a more dynamic version where the lamport-per-cost-unit parameter adjusts with recent block utilization, though the simplest version remains a static fee. Because the burn scales linearly with this parameter, a 0.1 lamport estimate should be viewed as conservative; a 0.25 lamport setting would imply 2.5x higher burn, while a 1.0 lamport setting would imply 10x higher burn.

Since 1 SOL equals 1 billion lamports, the fee would be small at the transaction level but potentially meaningful in aggregate. The design also avoids the main issue with simply increasing Solana’s flat base signature fee. A uniform base fee hike would disproportionately affect validators and market makers, who submit high transaction volumes and often pay mostly base fees. That could hurt validator economics and weaken Solana’s market structure.

A resource-based base fee is more targeted. Transaction ordering on Solana is based on priority fee per CU, which has already pushed sophisticated actors, particularly market makers, to optimize transactions such as oracle updates to consume as few resources as possible. As a result, the incremental fee increase for these low-resource transactions should be small. Cavey estimated that some market maker updates would see only a low-single-digit percentage increase in fees, around 3%, assuming a 0.1 lamport per cost unit parameter.

By contrast, retail swaps and other higher-resource transactions would pay more. For example, a Pump swap could become several hundred percent more expensive under the proposed fee. However, Solana transaction fees are already far below one cent, so even a 600% increase in a tiny transaction fee may still be nearly invisible to the end user, especially at fee levels where users appear relatively price insensitive.

Benedict Brady’s research on payment for order flow on Solana is a useful example: Axiom users have paid a large premium for transaction landing relative to lower-cost alternatives, suggesting that users often prioritize speed and execution certainty over minimizing already-small fees. SIMD 547 would redirect some of that willingness to pay toward SOL burn rather than leaving all the value capture to applications and transaction landing services.

In aggregate, this is where the mechanism becomes interesting. The fee may be negligible for individual users and manageable for optimized market maker transactions, but across hundreds of thousands of blocks per day, it can meaningfully increase SOL burn and improve tokenholder value capture. That said, the lamport parameter needs to be set carefully. If it is too high, it could make high-frequency activity such as market maker oracle updates more expensive and potentially weaken the market structure the proposal is trying to preserve.

Of note, SIMD 547 is intended to activate after Alpenglow. Before Alpenglow, applying this mechanism could meaningfully increase vote transaction costs, which would hurt smaller validators. After Alpenglow, validator votes will disappear, removing this concern. 

Quantifying the Effects of SIMD 547

To quantify the potential impact of SIMD 547, we analyzed a stratified random sample of 10,000 Solana slots over the 30-day period from May 1 to May 31, 2026.

Our empirical analysis focuses on requested CUs as a proxy for the resource base that SIMD 547 would charge against. Reserved CUs were estimated from each block’s transaction data using Helius RPC. For transactions with an explicit Compute Budget SetComputeUnitLimit instruction, we used the requested compute unit limit. For transactions without an explicit limit, we inferred the reserved compute budget from runtime logs where available and used RPC cost units as a fallback for transactions without compute-unit log entries. Block-level reserved CUs were then computed as the sum of transaction-level reserved CUs.

Aggregating the data, we found that Solana transactions requested an average of 132M CUs per block, compared to 29M CUs consumed. In other words, requested CUs were approximately 4.65x higher than consumed CUs. The reconstructed reserved CU metric closely matched Solscan’s explorer value in a validation check against a visible Solscan block, differing by only ~0.024%.

This distinction matters because SIMD 547 would charge the proposed resource-based burn on requested resources, not consumed resources. On Solana, transactions can reserve compute upfront by specifying the maximum amount of compute they may need, even if they ultimately consume much less during execution. Today, over-requesting compute is relatively cheap. Under a resource-based burn, that inefficiency would carry an explicit cost, creating a direct incentive for applications and sophisticated users to optimize their requested compute limits.

One important caveat is that SIMD 547 would technically charge requested cost units, not just requested CUs. Cost units include compute, but also things like loaded data, write locks, and heap. Our analysis uses requested CUs as a close proxy, so the estimates should be directionally right but not exact.

SIMD 547: Current State Burn Estimate

Using the 30-day average of 132M requested CUs per block, 216,000 blocks per day, and a fee of 0.1 lamport per requested unit, the estimated burn would be:

132M requested CUs per block × 216,000 blocks per day × 0.1 lamport per CU = 2,851 SOL burned per day.

This would still be below the >10,000 SOL per day burned during peak activity in Q4 2024 and January 2025. However, it would represent roughly a 4x increase from today’s burn rate of approximately 700 SOL per day. Relative to roughly 66,500 SOL issued per day today, this would offset about 4.3% of daily issuance.

Importantly, 0.1 lamport should be viewed as the conservative end of the proposed range. Cavey has since suggested that 0.25 lamports per requested unit could be a reasonable starting point, while 1.0 lamport could represent a more aggressive upper bound. Because the burn scales linearly with the parameter, the same current-activity estimate would imply roughly 7,128 SOL burned per day at 0.25 lamports, or about 10.7% of daily issuance, and roughly 28,512 SOL burned per day at 1.0 lamport, or about 42.9% of daily issuance.

The 0.1 lamport case would only partially offset issuance, but it shows how the mechanism works. The more important point is that SIMD 547 scales with three variables: the lamport parameter, network usage, and network capacity.

The first variable is the fee parameter itself. Moving from 0.1 to 0.25 lamports increases burn by 2.5x, while moving from 0.1 to 1.0 lamport increases burn by 10x. The second is network usage: if more activity occurs on Solana and more cost units are requested, more SOL is burned. Put differently, more Solana usage would translate into more SOL burned.

The third variable is network capacity. Today, Solana’s block limit is 60M CUs. SIMD 286, which has already been merged and is pending activation, will increase the block limit to 100M CUs. Over time, Solana is also expected to continue increasing throughput through both higher per-block capacity and shorter slot times. Today, Solana targets roughly 400 ms slots, or approximately 216,000 blocks per day. If slot times eventually fall to 200 ms, the number of daily blocks would roughly double to 432,000.

That is the underrated part of SIMD 547. Because the burn is tied to requested resources, it does not just scale with today’s demand. It also scales with the final fee parameter and Solana’s future throughput ceiling.

Scenario Analysis

To illustrate the mechanism’s potential range, we model three simplified scenarios.

These scenarios vary both network capacity and the lamport-per-unit parameter. The first scenario uses the conservative 0.1 lamport assumption. The second and third use 0.25 lamports, which Cavey has suggested could be a reasonable starting point. We exclude the more aggressive 1.0 lamport setting from the main scenarios, though burn would scale linearly if the parameter were set higher.

These scenarios assume transactions become more optimized than they are today, with requested CUs falling to 2.5x consumed CUs versus the current observed ratio of 4.65x. They also assume blocks run at 80% utilization. This is intentionally simplified and should be read as sensitivity analysis rather than a forecast. 

Scenario 1: 60M CU Blocks, 400 ms Slots, 0.1 Lamport

In the first scenario, Solana remains at the current 60M CU block limit and 400 ms slot target. Assuming 80% block utilization and transactions requesting 2.5x more CUs than they consume, requested CUs would average 120M per block. At a conservative 0.1 lamport per requested unit, this would translate to roughly 2,592 SOL burned per day, offsetting about 4.5% of one-year forward daily issuance.

Scenario 2: 100M CU Blocks, 400 ms Slots, 0.25 Lamports

In the second scenario, Solana scales to 100M CU blocks while maintaining the current 400 ms slot target. Assuming 80% block utilization and the same 2.5x requested-to-consumed CU ratio, requested CUs would average 200M per block. At 0.25 lamports per requested unit, this would translate to roughly 10,800 SOL burned per day, offsetting about 18.9% of one-year forward daily issuance.

Scenario 3: 100M CU Blocks, 200 ms Slots, 0.25 Lamports

In the third scenario, Solana scales to 100M CU blocks, and slot times fall from 400 ms to 200 ms, roughly doubling the number of blocks produced per day to 432,000. Assuming 80% block utilization, the same 2.5x requested-to-consumed CU ratio, and a 0.25 lamport fee, this would translate to roughly 21,600 SOL burned per day, offsetting about 37.9% of one-year forward daily issuance.

These scenarios are directional estimates for illustrative purposes only. The actual burn would depend on network usage, block fullness, compute optimization, slot times, and the final parameter chosen by the proposal. But they show how the mechanism becomes more meaningful as Solana scales.

The Issuance Debate

SIMD 547 addresses the burn side of SOL net emissions, but burn alone is unlikely to fully solve the SOL net emissions problem. The other side of the equation is issuance. Solana’s inflation rate remains around 3.8%, with the terminal 1.5% rate still about six years away under the current schedule. Over the past year, at least three proposals have attempted to reduce SOL issuance.

The most prominent was SIMD 228, introduced by Tushar Jain and Vishal Kankani of Multicoin Capital. SIMD 228 proposed dynamically adjusting SOL issuance based on the staking participation rate, with a target staking ratio of 50%. The core idea was to make emissions more market-oriented: if too much SOL was staked, inflation would fall; if too little SOL was staked, inflation would rise.

We were broadly supportive of SIMD 228. However, the proposal failed to pass in March 2025. In our view, the main reasons were perceived complexity and the direct impact on validator and staker nominal income. (See this thread for more details.)

In retrospect, another potential issue with SIMD 228 is that it was proposed during a period of elevated onchain activity, when it was easier to argue that fee-based income (priority fees and Jito tips) could replace issuance as the dominant source of validator and staker revenue.

Since then, the decline in REV has complicated the argument that fee-based income can quickly replace issuance as the dominant source of validator and staker revenue. Issuance remains the majority of staking yield today, while priority fees remain hard to account for cleanly without SIMD 123.

After SIMD 228 failed, Galaxy and Helius proposed simpler approaches.

Galaxy introduced SIMD 279 in April 2025. Rather than replacing the fixed emissions schedule with a dynamic staking-ratio curve, the Galaxy proposal introduced Multiple Election Stake-Weight Aggregation, or MESA. Under MESA, validators would vote across multiple possible disinflation rates, and the stake-weighted aggregate would determine the new emissions curve. The goal was to preserve predictability while allowing the market to choose how quickly SOL should reach its 1.5% terminal inflation rate.

The strongest and most recent issuance-side proposal is SIMD 550, introduced by Lostin and Ichigo from Helius in November 2025. SIMD 550 proposes doubling Solana’s disinflation rate from 15% to 30% while keeping the 1.5% terminal inflation rate unchanged. In practice, this would preserve Solana’s existing inflation framework while accelerating the path to terminal inflation and reducing cumulative SOL emissions over the coming years.

We believe SIMD 550 deserves serious consideration. Compared with SIMD 228, which introduced a more complex issuance curve tied to staking participation, SIMD 550 is simpler and easier to evaluate: it keeps the current emissions model intact, but gets SOL to terminal inflation faster (about 2.9 years as opposed to 5.8). The tradeoff is clear: lower nominal staking yields and validator issuance revenue. However, this may be increasingly acceptable as Solana matures and the network looks to reduce the issuance burden on SOL tokenholders.

In this regard, SIMD 550 could act as an issuance-side complement to SIMD 547. SIMD 547 would improve value capture by increasing burn, while SIMD 550 would reduce the amount of new SOL entering circulation. Neither proposal is sufficient on its own, but together they point toward a more complete tokenomics roadmap: lower issuance, more activity-linked burn, and better alignment between Solana network growth and SOL tokenholder value accrual.

Conclusion: Stronger Economics for SOL

Ultimately, improving SOL value capture requires progress on both sides of net emissions: increasing SOL burn and reducing SOL inflation. SIMD 547 addresses the burn side by introducing a resource-based fee tied to network activity, while SIMD 550 addresses the issuance side by accelerating Solana’s path to terminal inflation. We support both proposals and believe they should be put to a vote. Neither proposal is a complete solution on its own, but together they would strengthen SOL’s economics through more activity-linked burn, less new issuance, and tighter alignment between Solana network usage and SOL tokenholder value accrual.

SIMD 123 is also necessary to complete the value-capture picture, as it would allow stakers to capture priority fees in protocol rather than relying on opaque or validator-specific offchain arrangements. The main risk is that much of Solana’s tokenomics roadmap remains just that: a roadmap. The 100M CU increase has been merged but not activated, SIMD 123 still has dependencies, 200 ms slots remain in the discussion stage, and Alpenglow has not shipped yet and is a prerequisite for SIMD 547 to avoid materially increasing vote transaction costs. In other words, execution is as important as it has ever been for Solana. These proposals may point in the right direction, but SOL value capture will only improve if they move from discussion, dependency chains, and pending feature gates into mainnet implementation.

 

The information contained in this report and by Blockworks Inc. and related affiliates is for general informational purposes only and is not intended to provide legal, financial, or investment advice. The report should not be construed as an offer or solicitation to buy or sell any security, token, or financial instrument and does not represent any recommendation or endorsement of any investment or financial product or service. Blockworks Inc. and related affiliates are not registered as a securities broker-dealer or an investment advisor in any jurisdiction or country.