Solana simulation evaluates SGP-0003 fee impact on major apps and routers
Key Takeaways
- •SGP-0003 would replace Solana’s flat base fee with a fixed inclusion fee and a variable fee based on requested compute units.
- •The simulation found that transactions request about 20% more compute than they actually consume on average.
- •Routers and aggregators such as Jupiter, Titan, and DFlow would likely face higher fees under the proposed model.
- •Optimized vote transactions for validators could become about 12.3% cheaper.
- •Projected daily fee burns could rise from about 648 SOL to between 1,500 and 9,000 SOL if the proposal is adopted.

Solana's fee model is set to become much more granular, and not every application is likely to benefit from the change. A simulation run by analyst @MostlyData_ estimates what SGP-0003 would do to transaction costs across the network, with the results pointing to clear winners, clear losers, and a sharply higher burn rate.
The governance proposal, introduced on August 3, 2026, alongside SIMD-0553, would replace Solana's flat 5,000-lamport base fee (one lamport is Solana's smallest denomination, a billionth of a SOL) with a two-part structure: a fixed 2,500-lamport inclusion fee paid to the block leader, plus a variable resource fee that starts at 0.1 lamports per requested compute unit and is burned entirely.
What the simulation found
The central finding is straightforward: Solana transactions are requesting significantly more compute than they actually use. On average, transactions request about 20% more compute units than they consume. That headroom exists for a practical reason: a Solana transaction that exceeds its requested compute limit fails, so applications pad their requests to avoid failed transactions. Under the current flat-fee model, that overestimation does not cost extra. Under SGP-0003, it would.
That gap affects routers and aggregators most heavily. The simulation estimated average fee increases of about 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 of less than 10% if resource pricing closely tracks actual consumption.
Validators could see one of the few direct benefits. Optimized vote transactions may become about 12.3% cheaper under the proposed model.
Burn rate would rise sharply
Solana currently burns about 648 SOL per day from signature fees. The simulation projects that SGP-0003 could increase daily burns to between 1,500 and 9,000 SOL per day. Burning transaction fees as a supply lever is not unique to Solana: Ethereum has destroyed the base fee on every transaction since its London upgrade introduced the mechanism in August 2021.
The proposal was introduced together with a separate measure to double Solana's disinflation rate from 15% to 30%. That would mean the network would both increase token burns and accelerate the reduction in new token issuance.
Applications would need to adjust
The proposal effectively creates a penalty for inefficiency. Applications that tightly calibrate compute requests would pay fees closer to the current flat rate, or potentially less. Applications that routinely over-request compute units would pay more for that buffer.
Central limit order book market makers face a particular tradeoff. These systems submit large numbers of transactions with substantial compute requirements, and even small per-transaction fee changes can add up quickly. The simulation identifies CLOB market making as a category that is especially exposed to the proposed pricing changes.
Routers such as Jupiter already account for a large share of Solana's DeFi transaction flow. Even a modest fee increase on each swap could affect end users or reduce margins for aggregator protocols.
None of these shifts are live yet: SGP-0003 remains a governance proposal, and the simulation models its proposed parameters rather than changes already adopted on the network.