Solana’s Resource-Fee Shift Makes Compute-Budget Hygiene a User-Cost Issue

The development

Solana’s July 23 changelog says SIMD-0553, the Resource and Inclusion Fee proposal, has been accepted. Its linked GitHub pull request was merged on July 20. If activated, the specification would shift part of Solana’s fee model away from a flat per-signature charge and toward the resources a transaction asks the network to reserve.

Status check, August 3, 2026: the reviewed SIMD document is still labelled “Draft,” names three feature gates, and gives no confirmed mainnet-beta activation date. This is an analysis of an accepted specification, not confirmation that the new fee model is live.

From signatures to requested resources

The document describes today’s 5,000-lamport per-signature base fee as a 50/50 split between burn and the block leader. SIMD-0553 would replace that component with a 2,500-lamport base inclusion fee per transaction, paid entirely to the leader.

It would then add a separate resource fee, burned in full. The resource fee would be based on requested scheduler cost: signature verification, write locks, instruction data, the requested compute-unit limit, and requested loaded-account data size. Priority fees would remain unchanged and continue to go to the leader.

The resource-fee rate is designed to activate in stages: 1/10, 1/4, then 1/2 lamport per requested cost unit. The staged gates give the ecosystem a chance to observe estimates, wallet behavior, and application costs before the highest specified rate takes effect.

Why compute-budget hygiene becomes product work

The consequential detail is that the resource fee would use requested cost, not post-execution consumption. An application that asks for a generous compute-unit limit would pay for that requested capacity even if the transaction ends up using much less.

That turns a familiar engineering shortcut into a user-cost problem. Apps should simulate representative transactions, set realistic Compute Budget limits, and refresh those estimates when program logic changes. Wallets and SDKs should calculate fees against the feature set active for the bank being simulated rather than relying on a hard-coded 5,000-lamport assumption. The specification specifically points to getFeeForMessage and transaction simulation as the authoritative places to obtain total fees.

This also changes how teams should read a transaction’s fee. A higher fee would no longer necessarily mean a higher priority bid; it could reflect a larger requested resource footprint. Good interfaces should eventually distinguish inclusion, priority, and resource components instead of presenting one opaque total.

Incentives and safety trade-offs

The design keeps a guaranteed inclusion payment for the leader while burning the resource component. That separates leader compensation from the amount of compute, account data, and lock contention a transaction requests. It is a more direct attempt to make expensive-to-schedule transactions bear more of their network cost.

There is a trade-off. The specification says the minimum transaction fee could fall below today’s 5,000 lamports: 3,010 lamports at the terminal 1/2 rate, and lower at earlier stages. It explicitly notes that this reduces the cost of low-floor spam, even though such transactions are extremely cheap to execute. This is a design trade-off, not evidence of an active exploit.

Activation is also consensus-sensitive. The document says validator clients must support all three feature gates before mainnet-beta activation; nodes that do not implement the new fee calculation could diverge once a gate is enabled.

What builders should do now

No immediate migration should be assumed without an activation announcement. But preparation is concrete: remove fixed-fee assumptions, simulate with realistic limits, surface accurate fee estimates, and test transactions that omit Compute Budget instructions. For teams operating validators or infrastructure, fee-estimation behavior near epoch boundaries deserves particular attention because the active gate determines the applicable model.

SIMD-0553 is most interesting not as a burn narrative, but as a change in responsibility. If it reaches activation, efficient resource requests become part of protecting users from avoidable fees.