Solana Governance: SIMD-553 Targets Compute Unit Mispricing That Distorts Transaction Scheduling

Solana SOL$71.33-1.1% co-founder toly retweeted an analysis of governance proposal SIMD-553 early on June 18, drawing wider attention to a technical debate that has been building since the proposal was filed on June 4. The underlying issue is concrete: the fraction of requested compute units that transactions actually consume is, in the words of on-chain data analyst Umberto (@MostlyData_), "ridiculously low," and that gap has real consequences for how Solana's scheduler prioritizes transactions.

What the Proposal Does

SIMD-553 is authored by @cavemanloverboy, a researcher who has contributed several fee-market proposals to Solana's improvement process. The proposal takes Solana's existing 5,000-lamport per-signature base fee and splits it into two components:

• A base inclusion fee of 2,500 lamports per signature, paid entirely to the block leader.
• A resource fee calculated as requested_cost_units × 0.5, burned 100%.

The full transaction cost formula under the proposal becomes: (2,500 × num_signatures) + (requested_cost_units × 0.5) + priority_fee.

The resource fee rate of 0.5 is a starting parameter, not a fixed value. The proposal charges for requested compute units rather than consumed ones, giving senders a direct financial incentive to request accurately while preserving fee predictability (since post-execution fees would create uncertainty for transaction simulation).

The Mispricing Problem

Solana's cost model assigns compute units to every transaction before execution. Programs declare an upper bound on what they expect to use via the ComputeBudgetProgram instruction. The scheduler treats that requested ceiling as a proxy for how much block space the transaction will occupy.

The problem: in practice, many transactions request far more compute than they consume. A transaction that requests 200,000 compute units but uses 40,000 still crowds out scheduling capacity as if it needed all 200,000. Because the current base fee is a flat 5,000 lamports per signature regardless of how many compute units are requested, there is no price signal to discourage over-requesting.

Umberto's June 17 analysis put it plainly: "The fraction of requested cost units that is actually consumed is ridiculously low. While the broader economic implications of the proposal still require careful analysis, we should at the very least demand a much better alignment between requested and consumed cost units."

The cavemanloverboy response, posted the same day: "We are simply adding an incentive to request correctly, and to reduce CUs."

Estimated Impact on SOL Economics

The proposal estimates current daily SOL burn from the signature fee at roughly 648 SOL. The resource fee would increase that to an estimated 7,500 to 9,000 SOL per day, a roughly 12-14x increase from this source, though still modest relative to SOL daily inflation of approximately 60,000 SOL.

The effect on individual transactions varies sharply by type. Simple votes under legacy settings would see dramatic cost increases; votes optimized with ComputeBudgetProgram instructions to specify an accurate compute limit would remain manageable. Low-compute transactions (simple transfers and many basic DeFi operations) would become slightly cheaper as the inclusion fee drops from 5,000 to 2,500 lamports. Compute-heavy, zero-priority traffic (the type of batch or bot activity that requests large compute budgets) would face substantially higher fees.

Reviewers and Objections

The PR has attracted four formal reviewer responses from core client engineers since it was filed, with force-pushes incorporating feedback occurring through June 15-17.

Riptl from the Firedancer client team approved the proposal on June 6, providing one of the two required sign-offs for merge eligibility. Three Anza engineers are actively engaged but have not yet approved.

Apfitzge raised a scope question: the current per-signature model treats different signature types inconsistently, and apfitzge argues the proposal is an opportunity to move to a flat per-transaction inclusion fee rather than perpetuating the per-signature structure, which would be a broader change than what SIMD-553 currently specifies.

Tao-stones, an Anza cost model specialist, noted that simple votes under the older SIMD-0458 specification carry 218,443 compute units; under the more recent CBP optimization path they cost approximately 4,500 units. That distinction matters because it determines whether validators face a 21x fee increase on their vote transactions or something manageable.

Bw-solana flagged three unresolved questions: how the proposal interacts with Alpenglow (Solana's forthcoming consensus upgrade), whether cost units are the right measurement standard for the resource fee, and how the 0.5 multiplier was selected. Anza has stated it requires alignment on these three points before its own approval.

MaxResnick has objected to moving away from the 5,000-lamport base entirely, preferring to keep the existing structure. Developer gwalen raised user experience concerns about adding a third protocol-level fee component.

Broader Governance Context

SIMD-553 is one of several active proposals reshaping Solana's fee economics simultaneously. SIMD-550 from Helius engineers proposes doubling the disinflation rate to reduce SOL issuance. Anza's Constellation proposal (SIMD-0322) would restructure transaction ordering itself, with direct implications for how priority fees are set and captured.

The three proposals address different layers of the same system: what gets issued (SIMD-550), how block space is allocated (SIMD-0322), and what transactions pay for that allocation (SIMD-553). Whether they are complementary or create new interactions, particularly with Alpenglow (which changes the vote mechanism and therefore the vote-fee calculus), is an open engineering question that several reviewers have raised.

SIMD-553 requires at least one approval from Anza and one from Firedancer before it becomes merge-eligible. With riptl's approval in hand and three Anza engineers actively engaged, the proposal is in substantive review rather than early-stage consideration. The debate reached a wider audience on June 18 when toly's retweet surfaced Umberto's analysis beyond the technical working group, a pattern that has preceded significant community discussion on earlier governance proposals.

Umberto's measured conclusion: "I don't think the data supports a definitive conclusion yet. One thing is clear, though: requested cost units are significantly mispriced, and that's a serious issue when it comes to transaction scheduling."