Solana just changed how its base fees work at the protocol level, and the market-relevant detail is buried in a weekly engineering digest. The July 23, 2026 Solana Changelog confirms that the Resource and Inclusion Fees Solana Improvement Document has moved to accepted status — a change that splits every base fee into a fixed validator payment and a usage-based burn.
The mechanics: going forward, 2,500 lamports of each base fee are paid to the validator. The remainder is computed from the transaction’s requested compute units and then burned. The Solana Foundation describes this as “implementing a protocol-level buy-and-burn strategy on SOL tied to network usage” — meaning the more compute the network actually processes, the more SOL is destroyed. For a chain whose fee economics have long been criticized as too cheap to matter, tying burn directly to requested compute is a structural shift: it prices resource demand rather than transaction count, and it gives validators a predictable fixed component instead of a percentage of a volatile whole.
What shipped alongside the fee change
The same week brought a dense release slate across both major validator clients. Anza shipped Agave v4.3.0-alpha.2 and v4.2.0-beta.2, pushing the next major client version into public testing. The Firedancer team shipped v1.1.2 and v0.1102.40201 of its independent validator client. On the tooling side, more than a dozen program JS SDKs cut releases in one sweep — Token, Token-2022, Stake, System, Memo, Compute Budget, Address Lookup Table, Single Pool, Record, Program Metadata, ZK ElGamal Proof, Token Wrap, and Loader V3 among them — alongside LiteSVM v0.15.0 for testing.
That SDK wave matters more than it looks. Solana’s JavaScript stack fractured after the original web3.js was deprecated and revived, and the changelog notes LiteSVM will support the revived @solana/web3.js framework again — a concession that a large share of production codebases never migrated off it. Builders get back a supported test path for the framework they actually use.
Under the hood: deployment pain and proof-of-history memory
The forward-looking work reads like a list of Solana’s most common developer complaints. Agave is improving the program deployment CLI — the changelog is blunt that deploying a program to mainnet is “one of the main pain points of Solana program development.” Agave also changed how proof-of-history records are grouped, simplifying the types that store them so memory allocation leaves more headroom for processing user transactions. Firedancer is reworking its epoch boundary procedure, the step that prepares validator rewards and the upcoming leader schedule. And Superbank is adding support for archiving historical data via Parquet files, the columnar format most data teams already run, which lowers the barrier for anyone building analytics on chain history.
Program-level work rounds it out: the Subscription Program will allow immediate cancellation of a subscription — the missing piece for SaaS-style recurring payments on chain, where users expect to stop future charges instantly — and the Caravel framework is adding associated token account helper CPI invocations, a convenience wrapper around one of the most repeated patterns in Solana program code.
Nothing here requires action from token holders today, but validator operators should read the release notes before upgrading — the changelog explicitly flags version-specific changes across both the Agave alpha and the Firedancer point releases, and alpha-channel builds are for test environments rather than mainnet voting nodes.
The through-line this week is economic and operational maturation at the same time. A usage-tied burn gives SOL holders a mechanical link between network demand and supply; a fixed validator cut gives operators predictable revenue; and the client work chips away at the deployment and testing friction that keeps teams on other chains. None of it is a single flashy launch — which is precisely why the fee-structure change deserved a bigger headline than a changelog bullet.
