Solana Moves to Split and Burn Base Fees After 'Resource and Inclusion Fees' SIMD Is Accepted
Solana's Resource and Inclusion Fees improvement document reached "accepted" status, routing 2,500 lamports of each base fee to validators and burning the rest based on requested compute units.
A change to how Solana handles transaction base fees has reached "accepted" status, according to the July 23, 2026 Solana Changelog published on solana.com. The Resource and Inclusion Fees Solana Improvement Document (SIMD) reworks the base-fee mechanic that has, until now, been fully burned.
Under the accepted design, part of each transaction's base fee — a fixed 2,500 lamports — will be paid to the validator that processes it. The remaining portion is computed from the transaction's requested compute units and then burned. Solana's engineering write-up frames the burned share as "a protocol-level buy-and-burn strategy on SOL tied to network usage." In plain terms: the more compute a transaction asks for, the larger the amount of SOL destroyed.
"Accepted" is a governance milestone, not a mainnet activation. The changelog does not give an epoch, slot, or date for when the split takes effect, and it does not quantify the expected net change in SOL issuance or validator revenue. Those numbers weren't disclosed.
The same issue logged a batch of routine client and tooling releases. Anza shipped Agave v4.3.0-alpha.2 and v4.2.0-beta.2; Firedancer shipped v1.1.2 and v0.1102.40201. More than a dozen program SDKs were bumped, including Token Program JS SDK v0.15.0 and Token 2022 v0.13.0. Separately, Anza opened a bug bounty program ahead of the planned switch to Alpenglow on mainnet — the changelog gives no date for that migration either.
Key facts
- Resource and Inclusion Fees SIMD moved to "accepted" status — Solana Changelog, July 23, 2026 (solana.com).
- Fixed 2,500 lamports of each base fee routed to the validator; the rest burned, computed from requested compute units — same source.
- Solana describes the burn as a "protocol-level buy-and-burn strategy on SOL tied to network usage" — same source.
- Anza shipped Agave v4.3.0-alpha.2 / v4.2.0-beta.2; Firedancer shipped v1.1.2 / v0.1102.40201 — same source.
- Anza opened a bug bounty ahead of the Alpenglow mainnet switch — same source.
The real-world read
This is Solana's own engineering publication describing its own protocol change, so read the "buy-and-burn" phrasing accordingly — it's the project characterizing a burn mechanic in tokenomics-friendly language, not a neutral third party's assessment. What the changelog leaves out matters: there's no activation date, no modeling of how much SOL would actually be burned versus paid to validators at current volumes, and no discussion of whether shifting base fees toward validators changes their incentives. A "buy-and-burn" that scales with network usage sounds bullish, but the changelog offers no figures to size it — and "accepted" changes have slipped or been revised before shipping. Treat the deflationary framing as an intent, not a measured outcome, until it's live on mainnet and the numbers can be observed on-chain.
This is news coverage, not financial advice.
Sources
- Solana Changelog, July 23, 2026 (solana.com) — primary source for the accepted Resource and Inclusion Fees SIMD, the 2,500-lamport validator split and compute-unit-based burn, client/SDK release versions, and the Alpenglow bug bounty. Note: this is Solana's own developer publication describing its own protocol work; its characterizations are self-published, not independent.