Solana simulation evaluates SGP-03 fee impact on major apps and routers

Solana’s fee model is about to get a lot more granular, and not every application will love the math. A simulation run by analyst @MostlyData_ quantifies what SGP-0003 would actually do to transaction costs across the network, and the results paint a picture of winners, losers, and a dramatically larger burn rate.

The governance proposal, introduced on August 3, 2026, alongside SIMD-0553, would retire Solana’s flat 5,000-lamport base fee in favor of a two-part system: a fixed 2,500-lamport inclusion fee paid to the block leader, plus a variable resource fee starting at 0.1 lamports per requested compute unit that gets burned entirely.

What the simulation actually found

The core finding is blunt: Solana transactions are ordering way more food than they eat. On average, transactions request about 20% more compute units than they actually consume. Under the current flat-fee system, that overestimation costs nothing extra. Under SGP-0003, it costs real money.

That mismatch hits routers and aggregators hardest. The simulation pegged average fee increases at roughly 0.000068 SOL for Jupiter, 0.00010 SOL for Titan, and 0.00012 SOL for DFlow.

Only about 28% of transactions would see a fee increase below 10% if resource pricing accurately reflects consumption.

There is a bright spot for validators. Optimized vote transactions could become approximately 12.3% cheaper under the new model.

The burn math changes dramatically

Currently, Solana burns around 648 SOL per day from signature fees. The simulation projects that SGP-0003 would push daily burns to somewhere between 1,500 and 9,000 SOL per day.

The proposal was introduced alongside a separate measure to double Solana’s disinflation rate from 15% to 30%, meaning the network would simultaneously increase token burns and accelerate the reduction of new token issuance.

Who wins and who adjusts

The proposal essentially creates a tax on inefficiency. Applications that carefully calibrate their compute requests will pay fees closer to the old flat rate, or possibly less. Applications that habitually over-request CUs will pay a premium for that safety margin.

Central limit order book market makers face an especially interesting calculus. These operations submit high volumes of transactions with significant compute requirements, and even small per-transaction fee increases compound quickly into material cost changes. The simulation highlights CLOB market making as a category particularly exposed to the new pricing.

Routers like Jupiter already dominate Solana’s DeFi transaction flow. A fee increase, even a modest one per swap, could ripple through to end users or compress margins for aggregator protocols.