SIMD-547 Would Multiply Solana's Daily SOL Burns Up to 100x Through Resource-Based Fees

A new Solana SOL$62.67-5.7% Solana governance proposal would replace the network's flat per-transaction fee with a charge tied to the actual computational resources each transaction consumes, and burn every lamport collected.

SIMD-547, submitted by @cavemanloverboy of the Temporal team in late May, proposes charging 0.1 lamports per cost unit consumed across four resource categories: compute units requested, data loaded, write locks, and serialized bytes. All fees collected this way would be burned rather than paid to block producers, separating resource pricing from validator compensation.

SOL SOL burns currently run around 648 SOL per day, a figure the proposal's contributors describe as far below the value the network generates. At the proposed 0.1 lamports per cost unit rate, the GitHub discussion projects daily burns of 10,800 to 64,800 SOL depending on network throughput, a 16x to 100x increase from the current baseline, against a daily issuance of roughly 60,000 SOL at the current 3.8% annual inflation rate. The proposal considers a rate range of 0.1 to 1.0 lamports per cost unit, with 0.25 discussed as a possible initial calibration.

How the Mechanism Differs from Existing Fees

The proposal operates on a different layer than the 2,500-lamport base transaction fee, which remains unchanged. It also differs from SIMD-0110, which responds to contention on individual hot accounts. SIMD-547 applies globally across every transaction and is designed for longer-cycle fee signaling rather than per-account congestion responses.

The proposal charges requested rather than consumed cost units, meaning fees are calculated based on the resources a transaction declares it will use before execution, not what it actually uses. The authors argue this is necessary for async transaction scheduling and lets wallets compute fees predictably at signing time.

Solana co-founder Anatoly Yakovenko endorsed the proposal with a "+1" on the GitHub thread and reposted it on X.

Technical Review Advances This Week

The proposal entered a more intensive review phase this week. On June 5, @cavemanloverboy posted empirical analysis of Solana's cost-unit distribution, showing that 99% of transactions would be priced within a factor of ten of each other at the proposed rate, a direct response to concerns that CU variance between transaction types makes the metric unreliable for fee pricing.

On June 6, core contributor @apfitzge raised a structural implementation question: whether priority fees and the new resource fees should use the same cost-unit measurement, or whether consolidating signature fees into the cost-unit model would simplify the fee structure further.

Several questions remain open in the thread. A contributor identified as t-nelson called cost units "garbage" for pricing purposes, citing three-order-of-magnitude variance across different transaction types. A separate thread participant noted that the hard ceiling imposed by the 60-million-compute-unit block cap limits maximum burns to roughly 1,300 SOL per day at current block capacity, per the GitHub discussion, far below the projections for higher-throughput scenarios.

Validator Economics and Dependencies

Because vote transactions also consume compute units, implementing SIMD-547 before the Alpenglow consensus upgrade would double vote costs for validators. The proposal explicitly requires Alpenglow activation as a prerequisite to avoid that outcome.

Priority fees, the primary revenue stream for validators, are not affected by this proposal. The 100% burn applies only to the new resource-based fee layer. Some participants in the thread advocate pairing the resource burn with a reduction in the existing base fee to partially offset the added cost.

This proposal takes a different path to reducing net SOL issuance than the companion SIMD-0550, which targets the inflation schedule directly by doubling the disinflation rate. SIMD-547 makes no changes to the emission schedule; it increases the burn side of the ledger in proportion to actual network usage.

No governance vote has been scheduled. The proposal is expected to move toward formal SIMD document creation once the technical discussion converges.