Solana is preparing to change how it charges for computing resources on the network.
Solana Improvement Document (SIMD-0553) would make its most resource-intensive users pay more while cutting the costs for simpler transactions. As a bonus, it would increase SOL’s burn rate in stages — and one day could even help make it deflationary.
Cavey, a researcher at Solana infrastructure firm Temporal and author of the proposal, tells Magazine that fees currently don’t reflect the real costs:
“If I submit a transaction that does nothing versus a transaction that burns 200 million CPU cycles, I’m charged the same amount.”
This proposal would change that by tying fees more closely to the resources each transaction requests. Rather than going to validators, the resource fee would be burned, removing SOL from circulation.
Of course, reducing validator income has not been welcomed by all. Contributor bji argues on github:
“I like the aspect of this proposal that gives tx submitters extra incentive to be accurate with CU limits. Everything else I’m meh to negative on. ‘More burn’ should not be a goal. Validator incomes should not be arbitrarily reduced.”
SIMD-0553 entered Solana’s new onchain governance process in early August and cleared its initial support phase on August 4.
It is currently in the support and discussion phase, which typically lasts seven epochs, or roughly two weeks. If it’s approved, it would change the incentives around Solana’s cheap blockspace.
So what’s the catch?
Wasting resources becomes expensive
Cavey says that Solana’s current fee structure creates a problem for developers.
Core Solana devs have spent years making the network faster, but applications have almost no financial incentive to stop wasting resources — an inefficient transaction costs the same as an efficient one.
Related: Ethereum, Solana led crypto hack losses in H1 2026: Blockaid
“By installing this resource pricing right now, suddenly app developers have to optimize,” Cavey says.
If the proposal is adopted, developers who reduce resource use could lower costs for end users and make their apps more attractive. Developers who consume more of Solana’s computing capacity would have to pay their fair share.
Solana Improvement Document (SIMD-0553). Source: Solana Foundation GitHub
Cavey says the proposal is particularly aimed at computationally wasteful arbitrage, where searchers can submit huge numbers of transactions that mostly fail, while paying very little.
In the past 30 days, he says, five of the traders with the highest failure rates 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.
A resource fee would push arbitrage searchers toward more informed and reactive strategies.
Stablecoin and token transfers could become roughly 20% cheaper, Cavey says. Temporal’s modeling also finds that vote transactions would cost around 12.3% less and oracle updates 16.9% less under the proposed model.
The trade-off?
Some trading activity would become considerably more expensive.
Temporal estimates that a high-priority swap routed through DFlow would cost 9.72% more under the proposed terminal fee rate, while a mid-priority OKX swap would cost 301% more and a pump.fun swap with zero priority would cost 3150% more.
That means some of the network’s heaviest users could see their transaction costs balloon, particularly traders using bots that submit large numbers of transactions.
Don’t worry though, as the fee increase is off a low base. Cavey argues that even the most compute-intensive transactions would cost around $0.05 under the proposed model, compared with the $2 to $5 fees a user might pay to swap $100 on a centralized exchange.
Who pays more, who pays less. Source: Temporal.xyz
The current proposal rejects a uniform increase to Solana’s existing 5,000-lamport fee, arguing that it would disproportionately hurt high-volume senders such as market makers while still failing to properly price resource usage.
Other costs to consider
“There have been a few people that have raised concerns about the parameters, but overall, everyone’s been very supportive,” Cavey says, citing validator income, higher costs for high-frequency users and increased complexity among the core issues.
One contributor, mschneider, asks why fees should be based on the resources a transaction requests rather than what it actually uses. “Units used seems more natural,” he says.
Cavey says there’s a reason the fee is based on the resources a transaction requests, rather than what it actually uses: it lets users know the cost upfront and allows validators to check they can afford it before processing the transaction. But it also means users can pay for resources they don’t end up using, giving developers an incentive to estimate their needs accurately.
Validators could initially see a small reduction in base-fee revenue by…
cointelegraph.com