Solana Fee Update Boosts Token Burn by Charging More for Usage

Solana is moving toward a significant shift in how it prices and allocates blockspace. A new Solana Improvement Document, SIMD-0553, would replace the network’s current approach—where transaction fees are not tightly linked to how many computing resources a transaction consumes—with a model that charges according to requested resources and burns the resulting fees in SOL.

The proposal entered Solana’s onchain governance process in early August and passed the initial support stage on August 4. It is now in the support-and-discussion phase, which typically runs for seven epochs (about two weeks). If it clears the process, it could reshape incentives for both developers and high-frequency users by making inefficient transaction behavior more expensive.

Key takeaways

• SIMD-0553 would tie fees more closely to requested compute, so transactions that use far more resources would pay more than lightweight ones.
• Instead of sending the resource fee to validators, the proposal directs it to a SOL burn, removing tokens from circulation.
• Core Solana devs and application teams would have stronger financial incentives to optimize performance and reduce resource waste.
• Some high-volume trading and bot activity is expected to face substantially higher costs under the terminal fee model.
• Higher burn projections could, in theory, move SOL toward deflation—but only if network activity grows enough to outweigh daily issuance.

Charging for compute, not just sending transactions

At the center of SIMD-0553 is a critique of Solana’s current fee structure: according to Cavey, a researcher at Solana infrastructure firm Temporal and author of the proposal, the cost users pay does not reflect the underlying compute differences between transactions. In his explanation, submitting a transaction that does minimal work can cost the same as one that consumes a large amount of CPU cycles.

Under the proposed model, resource fees would be set according to the resources a transaction requests rather than a flat baseline. Cavey argues this would give developers a clear reason to optimize, because wasteful behavior would no longer be subsidized by the network’s simpler fee mechanics.

“By installing this resource pricing right now, suddenly app developers have to optimize,” Cavey said, in the context of how poorly specified incentives can persist when inefficient and efficient transactions cost the same.

For end users, the change is intended to be beneficial indirectly: applications that reduce their compute consumption could pass on lower costs, improving user experience and potentially expanding what apps can afford to run.

Impact on arbitrage and high-frequency trading

A major focus of the proposal is computationally wasteful arbitrage. Cavey points to a pattern where searchers submit large volumes of transactions that largely fail—effectively consuming resources while capturing only limited successful outcomes—yet pay relatively low fees under current pricing.

He cites activity from the prior 30 days involving the traders with the highest failure rates: five accounts allegedly submitted 11.5 million transactions, consuming 929 million compute units across 2,477 trades that generated $16,091 in profit, while paying just 78 SOL in fees.

SIMD-0553 is designed to alter that equation. By increasing the cost of failed or inefficient attempts in proportion to requested resources, it would push arbitrage strategies toward more accurate and responsive behavior rather than brute-force submission.

Temporal’s modeling, as described alongside the proposal, suggests certain areas of onchain activity could become cheaper: stablecoin and token transfers could drop by about 20%, vote transactions by around 12.3%, and oracle updates by roughly 16.9% under the proposed fee model.

However, the same analysis implies a clear trade-off: some swaps—especially when routed through specific venues and prioritized differently—could become more expensive. Temporal estimates include a high-priority swap routed through DFlow costing 9.72% more, a mid-priority OKX swap costing 301% more, and a pump.fun swap with zero priority costing 3150% more. Cavey’s broader framing is that the base could remain low in absolute dollar terms for the most compute-intensive transactions, but the relative change for certain active strategies would be dramatic.

That is also why the proposal rejects a uniform increase to Solana’s existing 5,000-lamport fee, according to the article’s description: the uniform approach, Cavey argues, would likely penalize high-volume senders such as market makers while still failing to accurately price resource consumption.

Burn mechanics and the deflation debate

Beyond cost calculation, SIMD-0553 aims to change what happens to the fees. Rather than routing the resource fee to validators, the proposal would burn those fees—meaning SOL would be removed from circulation.

The article notes that the current daily burn is around 648 SOL, and that the terminal fee rate in SIMD-0553 could raise burn to roughly 7,500 to 9,000 SOL per day if resource demand stays roughly the same. That would represent an estimated 12 to 14 times increase in burn compared with current levels.

Cavey argues the effect could eventually make SOL deflationary, though he frames it as conditional on network success and continued growth in activity. As the article points out, Solana currently issues about 60,000 SOL per day, so even a 9,000 SOL daily burn would not, by itself, make the token deflationary. A separate improvement document, SIMD-0550, is described as targeting faster curbing of inflation already scheduled.

Importantly, the proposal’s burn incentive is also intended to reduce motivations to generate unnecessary resource-heavy transactions, aligning economic behavior with the network’s performance goals.

Still, not all contributors agree on the balance between validator revenue and token burn. One contributor, bji, reportedly argues against “more burn” as a goal and questions whether validator income should be reduced arbitrarily, reflecting a wider tension in fee-market design: funding network operations while maintaining supply dynamics.

Concerns about fairness, usability, and system complexity

Some of the debate around SIMD-0553 centers on a technical fairness question: should fees be based on how many resources a transaction requests or on how much it actually uses?

Contributor mschneider raises that it might feel more natural to charge based on units used. Cavey’s response, as presented in the article, is that charging based on requested resources provides upfront cost visibility for users and lets validators verify they can afford the fee before execution. At the same time, the model creates incentives for developers to estimate their resource needs accurately, reducing the risk of overpaying for unused compute.

The proposal would also introduce new operational and user-facing considerations. Some contributors worry that a new fee model could make Solana harder to use. Cavey argues that most users won’t need to calculate fees directly because exchanges and applications typically handle fee calculation and routing. He also suggests automated traders are sophisticated enough to adapt to fee-structure changes.

On validator economics, the article describes an estimated initial reduction to base-fee revenue of around 4%. Cavey says parameters could be adjusted to offset that impact if needed, but the disagreement remains unresolved for participants who prioritize validator income over additional burn.

As Solana moves deeper into the governance timeline, the key question for token holders and ecosystem participants is how those trade-offs resolve: whether the community converges on parameters that achieve stronger resource alignment without introducing unacceptable complexity or unintended pressure on critical market infrastructure.