Solana Resource and Inclusion Fees: How SIMD-0553 Changes Transaction Costs

How Solana transaction fees work today

Before examining SIMD-0553, it is necessary to understand the fee model a normal Solana transaction currently encounters.

For legacy and version-0 transactions, the basic structure contains two economic components: the base fee and an optional prioritization fee.

The base component currently charges 5,000 lamports for each qualifying signature counted by the fee calculation. Half of that base fee is burned and the other half becomes revenue for the block-producing validator.

The prioritization fee is separate. It is used to increase the economic attractiveness of including and scheduling a transaction when the leader is choosing among competing work.

The current 5,000-lamport signature charge

For a simple single-signer transaction, the familiar baseline is 5,000 lamports before an optional priority fee is added.

With the current 50/50 base-fee distribution, 2,500 lamports are removed from circulating supply and 2,500 lamports go to the validator responsible for the block.

A transaction containing multiple counted signatures can pay more because the base charge scales with the applicable signature count.

This is important because SIMD-0553 did not merely change the amount being burned. It proposed changing what the baseline fee was measuring.

The current priority fee

For legacy and version-0 transactions, a client can specify a compute-unit limit and a compute-unit price through Compute Budget instructions.

The priority fee is calculated from the requested compute-unit limit and the selected micro-lamport price per compute unit.

The resulting priority fee is paid entirely to the validator. It is not split with the burn mechanism under the current fee model.

This means applications already have one reason to avoid carelessly over-requesting compute when a non-zero CU price is used. The priority fee is based on the requested limit rather than the amount of compute the transaction actually consumes.

Failed transactions can still pay fees

A common misconception is that Solana charges fees only when the intended state transition succeeds.

That is not generally how transaction fees work. The network performs work to verify and process a transaction even when program execution later returns an error. A transaction can therefore fail while the fee payer still loses the transaction fee.

This matters for SIMD-0553 because its proposed resource fee would also have become part of the pre-execution fee calculation.

Why SIMD-0553 proposed changing the fee model

The central criticism behind SIMD-0553 was that the flat signature fee does not directly price the amount of network resources a transaction reserves.

Two transactions can each contain one ordinary signer and therefore begin with the same 5,000-lamport base charge even when their scheduler costs are very different.

One transaction might be a small, inexpensive state update. Another might request a large compute budget, lock many writable accounts and load substantial account data.

Validators do not experience those two transactions as identical work.

The current base fee primarily follows signatures

The current base charge originated from a model in which signature verification was a major explicit fee driver. Yet Solana's scheduler separately maintains a broader cost model for deciding how transactions fit within block resource limits.

That scheduler cost already considers more than transaction signatures.

SIMD-0553 proposed using that existing resource measurement as an economic input.

Reserved resources influence scheduling before execution

A validator cannot wait until every transaction finishes executing before deciding how much work to pack into a block. It needs an estimate beforehand.

Solana therefore calculates a requested scheduler cost using information known before execution.

That requested cost affects block packing and prioritization.

SIMD-0553's argument was straightforward: if transactions reserve materially different quantities of resources, some of the base economic charge should reflect those requested resources rather than remaining mostly flat.

The proposal also targeted SOL burn

The second motivation concerned token economics.

Under the current base-fee mechanism, half of the signature fee is burned. SIMD-0553 proposed replacing that fixed burned portion with a variable resource fee that would be burned in full.

Higher requested scheduler cost would therefore correspond to a larger amount of SOL removed from supply, while a very lightweight transaction could pay less resource burn.

Accepted SIMD, governance vote, and the status today

The chronology matters because articles written from a July 2026 snapshot can now be misleading.

June 2026: the fee design enters the SIMD process

SIMD-0553 was created as a core protocol proposal describing a Base Inclusion and Resource-based Fee.

The proposal specified the complete calculation, fee distribution, feature gates, RPC implications, wallet behavior, validator considerations and staged rates.

July 23, 2026: Solana Foundation calls it accepted

Solana Foundation's July 23 changelog explicitly reported that the Resource and Inclusion Fees SIMD had been accepted.

Acceptance was not the same thing as activation.

The SIMD itself defined three separate feature gates and required validator implementations to support the model before the first mainnet activation.

No wallet should have interpreted the July announcement as evidence that mainnet had immediately switched fee formulas.

August 2026: the design enters binding governance

The fee proposal subsequently became SGP-0003 in Solana's new stake-weighted governance process.

Solana Foundation published additional analysis on August 21 examining transaction classes, resource over-requesting, market makers, aggregators, validator economics and potential SOL burn.

August 28, 2026: SGP-0003 is rejected

The governance vote closed with SGP-0003 rejected.

That changes how the proposal should be described today.

It remains an important technical design and a useful explanation of where Solana fee-market thinking may go, but it is not appropriate to tell users that every mainnet transaction now pays a SIMD-0553 resource fee.

September 6, 2026: current official fee documentation remains on the existing model

Solana's current documentation still describes the base fee as 5,000 lamports per signature, with 50% burned and 50% paid to the validator, alongside the separate optional priority fee.

This is the model users should use when interpreting current transaction fees unless and until a later governance decision and network activation establish something else.

Current fees vs the SIMD-0553 design

The proposed base inclusion fee

SIMD-0553 proposed renaming and redesigning the base component as a "base inclusion fee."

The amount would have been 2,500 lamports per transaction, paid entirely to the block leader.

Notice the phrase "per transaction."

The proposal did not say 2,500 lamports for every signature. That difference matters.

Why the leader still receives a fixed inclusion payment

If priority fees are optional, many users will naturally submit transactions with a zero priority fee when blockspace is available.

A fee design that sent nothing to the leader for those transactions could make zero-priority traffic economically unattractive to include.

The fixed inclusion fee creates a baseline reward for actually placing the transaction into a block.

SIMD-0553 therefore separated two ideas that the current base fee partially combines: compensation for inclusion and payment for resource usage.

Why multi-signer transactions would behave differently

Under the current model, adding counted signatures can increase the base fee because the fee is calculated per signature.

Under SIMD-0553, the 2,500-lamport inclusion portion would remain flat for the transaction. Signature verification would still have a cost, but that cost would be represented inside requested scheduler cost and therefore affect the resource fee.

The SIMD explicitly acknowledged that multi-signer transactions could pay less than under the current per-signature structure unless signature pricing in the scheduler cost model were increased through a later proposal.

What the proposed Solana resource fee actually measured

The phrase "resource fee" can be misleading if interpreted as a fee on compute units alone.

SIMD-0553 defined the fee using requested cost units, a scheduler-level aggregate that incorporates several categories of transaction cost.

Requested cost units are therefore broader than the compute units a program eventually consumes in the runtime.

Five components contribute to requested cost units

The proposal specified a saturating sum of five cost-model components:

This distinction is essential for transaction planning.

A user could execute a program using fewer runtime compute units than requested and still pay the proposed resource fee based on the larger pre-execution request.

Requested cost vs consumed cost

One of the most consequential decisions in SIMD-0553 was to charge for requested resources rather than retrospectively measuring what execution consumed.

That design was deliberate.

The fee has to be knowable before execution

A transaction's fee payer needs enough lamports to cover the charge before the transaction executes.

Validators also need a deterministic result when they verify the block.

If the fee depended on a complex post-execution measurement, the system would introduce more dependency between execution outcomes, fee calculation and scheduling.

Requested cost can be calculated before execution begins.

The scheduler already reasons about requested resources

Block packing cannot assume every transaction will consume only the eventual minimum amount.

A transaction could legitimately use everything it requested.

The scheduler must therefore reserve capacity based on its requested cost until execution reveals otherwise.

SIMD-0553 attempted to align the user's economic charge with that reservation.

Accurate requests become financially valuable

Suppose Transaction A realistically needs a 120,000-CU execution budget but requests 600,000 CUs "just to be safe."

Under a resource-fee model, the execution portion of its requested scheduler cost reflects the 600,000-CU request, not the 120,000 CUs it eventually consumes.

The transaction therefore pays for much of the resource headroom it asked the network to reserve.

The design creates a direct incentive for simulation-driven estimation with a sensible safety margin rather than oversized defaults.

The SIMD-0553 fee formula

Once a resource-fee feature gate were active, the proposed total fee would be the sum of three components.

The inclusion fee would be 2,500 lamports.

The priority fee would remain whatever the transaction's existing priority-fee mechanism produced.

The resource fee would be calculated as:

The ceiling operation matters because lamports are discrete integer units. A fractional result would round upward to the next whole lamport.

Example: 300,000 requested cost units at the 1/10 stage

At 0.1 lamport per requested cost unit, a transaction with 300,000 requested cost units would generate a 30,000-lamport resource fee.

With no priority fee:

At the 1/4 stage

The same requested cost would generate 75,000 lamports of resource fee.

At the terminal 1/2 stage

The same request would generate 150,000 lamports of resource fee.

These examples make the design's behavioral incentive obvious. A transaction that reserves a lot of scheduler capacity is no longer economically similar to a minimal single-signature update merely because both have one signer.

The proposed three-stage rollout

SIMD-0553 did not propose jumping immediately to its full resource-fee rate.

It defined three feature gates intended to increase the rate progressively.

The staged structure was designed to let wallets, RPC systems, applications and validator clients observe behavior under a lower rate before reaching the proposed terminal level.

Highest active rate would win

The SIMD specified that if more than one of the feature gates were active for a bank, implementations would use the highest effective resource-fee rate.

Although the gates were intended to activate in order, the calculation itself did not depend on the assumption that every lower stage had activated first.

Epoch boundaries would matter

The design tied activation to normal feature-gate mechanics. A rate becoming active for a new epoch would change which fee formula the bank uses from the first slot of that epoch.

That creates an important wallet requirement: fee estimation near an activation boundary has to simulate against the correct feature set.

A client using stale fee assumptions could underestimate what a fee payer needs.

Priority fees were not being replaced

SIMD-0553 did not propose turning the resource fee into a new bidding system for leader attention.

Resource pricing and transaction prioritization remained separate economic functions.

Resource fee: network-wide resource charge

The proposed resource fee was tied to requested scheduler cost and burned completely.

The proposal's rationale was that the costs of replaying and validating a transaction are borne by the broader network, not solely by the leader who includes it.

Priority fee: leader-directed scheduling incentive

The priority fee would remain revenue for the block leader.

It exists to make a transaction more attractive relative to competing transactions when inclusion is contested.

Under legacy and version-0 transaction mechanics, that fee continues to relate to the requested compute-unit limit and selected compute-unit price.

One transaction could pay both

A compute-heavy swap under the proposal could pay a substantial burned resource fee because of the resources it reserves and a substantial priority fee because the sender wants faster inclusion.

Those are two different economic decisions.

The resource fee says, in effect, "this transaction reserves significant network resources."

The priority fee says, "the sender is willing to pay the leader more to schedule it competitively."

What SIMD-0553 would have changed for leader revenue

For ordinary single-signature transactions, the proposed base inclusion payment was intentionally close to the leader's current base-fee share.

Today, a 5,000-lamport single-signature base fee sends 2,500 lamports to the validator.

SIMD-0553 would also have sent 2,500 lamports to the validator as the inclusion fee.

That means leader protocol-fee revenue for the base portion of a typical single-signature transaction would not automatically increase just because the resource fee was introduced.

The new resource fee would be burned, not paid to the leader.

Multi-signer traffic would differ

Current leader revenue from the base fee increases with applicable signature count because the base charge is per signature.

A flat 2,500-lamport inclusion fee per transaction would remove that scaling from the leader's inclusion component.

Signature work would instead contribute through requested scheduler cost, but the associated resource fee would be burned.

This is why multi-signer transactions were one of the areas where the proposed economics diverged from the current system.

How the SOL burn would have changed

SIMD-0553's largest token-economic change was replacing a fixed signature-linked burn with a burn tied to requested resources.

Current burn

Today, 50% of the base signature fee is burned.

For a simple 5,000-lamport single-signature base fee, that means 2,500 lamports are destroyed.

Proposed burn

The 2,500-lamport inclusion fee would not be burned at all.

Instead, the entire resource fee would be destroyed.

A lightweight transaction could therefore burn relatively little, while a resource-heavy transaction could burn much more.

The resource fee would not have been validator revenue

This was a deliberate part of the design.

Routing a share of the resource charge to the leader could create incentives for leaders to favor inefficient transactions simply because those transactions paid larger resource fees.

Burning the full resource component reduces that direct incentive.

Burn estimates were scenario-dependent

The SIMD used May 2026 network observations to estimate that the staged rates could produce significantly more resource-fee burn than the existing signature-fee burn under the sampled workload.

Solana Foundation's later August analysis emphasized an important caveat: user behavior would change.

If applications aggressively optimized their requests once over-reservation became expensive, the eventual burn could be much lower than calculations based on today's poorly calibrated transaction requests.

Burn projections should therefore be interpreted as behavioral scenarios, not guaranteed token-supply forecasts.

Why over-requesting compute became the center of the debate

The proposal exposed a problem that matters even without SIMD-0553: many Solana transactions reserve substantially more scheduler capacity than they ultimately consume.

Solana Foundation's August 21 analysis reported that aggregate consumed cost units were only around one-fifth of requested amounts in the examined data.

Even transactions explicitly configuring both compute and loaded-account-data limits showed material excess requests.

Why developers over-request today

A transaction that requests too little compute can fail.

Developers therefore have a rational incentive to leave headroom.

If the incremental economic cost of that headroom is small or zero, over-provisioning can be operationally safer than trying to estimate tightly.

The result is a tragedy of reservation rather than necessarily a tragedy of actual consumption: each application protects itself by reserving more than it expects to need, while the scheduler must account for those requests.

SIMD-0553 would have priced the headroom

The proposed resource fee would turn excessive reservation into a direct monetary cost.

An application requesting twice the scheduler resources it actually needs would not receive a refund merely because execution was efficient.

That would change engineering behavior.

Simulation, historical percentile analysis and per-route compute estimation would become more valuable because saving requested capacity would save lamports.

What the proposal would have meant for wallets

Wallets would have become responsible for displaying a transaction fee whose base component was no longer predictable from signature count alone.

Fee estimation would need current bank rules

Hardcoding 5,000 lamports per signature would become unsafe after a resource-fee feature gate activated.

The wallet would need current network state, requested cost and any applicable priority fee.

RPC estimation would remain the safer source

SIMD-0553 proposed keeping RPC fee responses compatible at a high level. Existing calls could still return a scalar total fee even if the internal components changed.

The proposal specifically contemplated methods such as fee estimation and transaction simulation returning the new total.

This means wallets would not necessarily need to reimplement every validator cost-model detail locally.

A useful UI would explain the components

Even if an RPC endpoint returns only one total number, a sophisticated wallet could explain why a transaction became expensive.

Was the resource request high?

Was the priority bid high?

Was the transaction a low-resource transfer or a complex route touching many accounts?

Separating those ideas is useful because reducing a priority fee and reducing resource reservation are not the same optimization.

Fee-payer balances would need more margin

A transaction prepared under the assumption that approximately 5,000 lamports would cover its base charge could become invalid if the calculated resource fee made the actual required fee much larger.

This was one of SIMD-0553's backwards-compatibility concerns.

Applications that fund ephemeral fee payers with very tight balances would have needed to change.

What SDK and transaction builders would need to do

SIMD-0553 would reward software that understands the transaction it is building instead of relying on oversized defaults.

Simulate before finalizing resource limits

A common strategy is to simulate a representative transaction, observe its actual compute requirement and then add a moderate safety margin.

Solana's current compute-budget guidance already recommends avoiding unnecessary CU requests because priority fees can be based on the requested limit.

A resource fee would strengthen that incentive even for zero-priority transactions.

Loaded-account-data limits matter too

Focusing exclusively on compute units would be incomplete.

SIMD-0553's requested cost also incorporated the requested loaded-accounts data size.

An application that carefully tunes compute but leaves an unnecessarily large data-size request can still carry excess scheduler cost.

Generic defaults become economically visible

Today, an application may omit an explicit compute-unit limit and allow defaults derived from its instruction set.

Under SIMD-0553, those implicit requested limits could generate a substantially larger resource fee than the program's real execution would justify.

That would push SDKs toward more active fee and resource estimation.

Market makers and high-frequency transaction senders

A tiny increase that is irrelevant to one retail user can matter enormously to an actor submitting millions of transactions.

This makes market-making systems one of the most important groups in any Solana fee reform.

Frequency magnifies marginal costs

Market makers continuously update orders, liquidity parameters and prices.

A 0.00001 SOL change per transaction may appear trivial until multiplied by a large number of transactions every day.

Different market-making architectures have different resource profiles

Not all trading infrastructure would have been affected equally.

Simple oracle-like updates can request relatively few resources and potentially become cheaper under a resource-aware model.

More complex order-book or routing transactions can reserve substantially more scheduler capacity and therefore incur larger resource charges.

Batching creates an interesting tradeoff

Some high-frequency systems combine multiple logical updates into one transaction because the current fixed base fee makes aggregation economical.

A resource-aware charge weakens the assumption that a larger transaction enjoys nearly the same base economics as a tiny one.

Builders would need to compare the resource cost of batching with the extra inclusion cost of splitting work across more transactions.

Why routing and aggregators were especially exposed

Swap aggregators can build transactions that interact with several programs and accounts to find better execution.

That complexity is exactly the type of workload a resource-based fee attempts to distinguish from a simple transfer.

Solana Foundation's pre-vote analysis found that routing systems were among the transaction classes facing the largest potential fee increases under the SGP-0003 assumptions.

More complex routing would carry a direct resource cost

An aggregator may decide that an extra venue improves execution by 0.00005 SOL while requiring enough additional resources to increase the transaction fee by 0.00008 SOL.

Under that scenario, the nominally better route is no longer economically better for the user.

The fee model can therefore influence routing strategy itself.

Fee-aware pathfinding becomes part of execution quality

A mature routing engine should optimize net user outcome, not quoted asset output in isolation.

If transaction resource costs become material, pathfinding needs to account for them alongside price impact, slippage, priority fee and execution probability.

Although SGP-0003 was rejected, the analysis remains useful because it illustrates how protocol pricing can alter DeFi architecture.

Arbitrage and low-margin transaction flow

Solana supports strategies that compete for very small price discrepancies at high speed.

Some arbitrage opportunities are profitable only because transaction costs are extremely low relative to the value being moved.

A resource fee raises the minimum profitable edge

If the network charges more for a complex arbitrage transaction, an opportunity must produce more profit before it becomes rational to execute.

That can remove some low-margin flow.

Whether that outcome is beneficial depends on the role the activity plays in market efficiency, liquidity and validator economics.

Economic filtering is different from technical filtering

The proposal did not ban arbitrage transactions.

It changed the cost curve.

A strategy with sufficient alpha could continue operating. A strategy whose expected profit was smaller than its resource charge would stop being rational.

Validator implications

The proposal affected validators in several different roles: as block producers receiving fees, as network participants replaying transactions and, before Alpenglow, as senders of on-chain vote transactions.

Single-signer inclusion revenue would remain similar

For the ordinary one-signature transaction, current base-fee leader revenue is 2,500 lamports.

The proposed inclusion fee was also 2,500 lamports.

The resource portion would be burned rather than added to leader revenue.

Multi-signer revenue would decline relative to the current base-fee structure

A validator currently receives half of each applicable 5,000-lamport signature charge.

Under a flat 2,500-lamport per-transaction inclusion fee, the leader would not receive multiple inclusion payments simply because the message carries multiple signatures.

Vote transactions were a special case

Before Alpenglow eliminates normal on-chain consensus vote transactions, validators themselves send vote traffic at high frequency.

The SIMD warned that legacy vote transactions could look unnecessarily resource-heavy if their requested limits remained poorly calibrated.

With properly tuned requests, however, its example vote transaction at the terminal 0.5-lamport rate came out cheaper than the current 5,000-lamport base fee.

Using 3,765 requested cost units:

That is about 12.3% below 5,000 lamports.

The comparison illustrates the proposal's intended logic: cheap work can become cheaper while expensive resource reservations pay more.

Would a resource fee reduce spam?

The answer is more nuanced than "resource pricing makes spam expensive."

A resource fee would increase the cost of spam transactions that reserve significant resources.

However, SIMD-0553 could also reduce the minimum fee for extremely cheap transactions.

The proposed minimum could be below 5,000 lamports

The SIMD noted that at the terminal 0.5-lamport resource rate, a minimal transaction could have a floor around 3,010 lamports under its cost assumptions.

The first two staged rates would imply even lower resource components for the same minimal requested cost.

That is below today's 5,000-lamport single-signature base fee.

Cheap spam could become cheaper

If an attacker can construct transactions that are extremely inexpensive for validators to process, a resource-aware fee intentionally charges them less.

From an economic-efficiency perspective, that can make sense because the transactions are cheap.

From an anti-spam perspective, reducing the absolute minimum transaction cost can lower one barrier to high-volume nuisance traffic.

Resource-heavy spam would face a different economics

Transactions designed to reserve large compute limits, lock expensive state or load substantial data would pay more under SIMD-0553 than minimal traffic.

The proposal therefore changes spam economics by resource profile rather than simply increasing every transaction's minimum cost.

Failed and fee-only transactions

The proposal did not create a general rule that users pay a resource fee only if their programs successfully reach the final instruction.

Fees are part of transaction processing, not a success commission.

Fee-only handling would include the resource fee

SIMD-0553 specifically addressed Agave's fee-only handling for certain transactions that fail during account loading.

Under the proposed activated model, the fee payer would still be charged the complete calculated fee, including the resource component, even though normal execution never occurred.

This is consistent with the principle that the transaction reserved and caused network processing before its failure became known.

Applications need preflight discipline

When a complex transaction can carry a materially higher total fee, blindly submitting transactions that are already likely to fail becomes more expensive.

Simulation and current account-state checks become more valuable.

Users investigating failed or unexpectedly expensive Solana transactions can use the TokenToolHub Solana Transaction Decoder to inspect instructions, execution results, program calls and balance effects rather than relying only on a wallet's summary.

RPC and fee-estimation implications

One practical strength of the SIMD design was that it did not require every application to receive an entirely new mandatory JSON response shape.

The validator could calculate the new total internally while familiar RPC methods continued returning the total fee.

getFeeForMessage

Under the proposed model, the returned total would reflect inclusion fee, resource fee and priority fee for the relevant bank.

simulateTransaction

Simulation would similarly need to use the effective resource-fee rate associated with the bank and feature set being simulated.

getTransaction

The transaction metadata fee field would represent the total amount charged rather than only one internal component.

Priority-fee data remains conceptually separate

Methods used to inspect prioritization-fee conditions would not suddenly become resource-fee estimators.

The two mechanisms address different economic problems.

Infrastructure consistency matters

At any feature activation boundary, RPC infrastructure and validators need to agree on active fee rules. Applications relying on several providers should avoid constructing a transaction using one bank's fee assumptions and evaluating it against stale network state elsewhere.

Teams that require dedicated or redundant Solana RPC infrastructure can evaluate Chainstack as one infrastructure option, while still implementing their own health checks, current-bank fee estimation and transaction simulation rather than treating provider redundancy as a substitute for fee-aware transaction construction.

What about Solana v1 transactions?

Fee discussions in 2026 are complicated by the transition toward Solana's newer v1 transaction format.

Current official fee documentation distinguishes legacy and version-0 transactions from upcoming v1 behavior.

Legacy and v0 priority fee

For existing legacy and v0 transactions, the familiar prioritization fee is derived from compute-unit price multiplied by the requested compute-unit limit, rounded into lamports.

v1 changes the priority-fee representation

Solana's current documentation describes v1 transactions as setting the priority fee as an absolute lamport amount in the message configuration rather than using the same Compute Budget price-times-limit mechanism.

This does not erase the broader concept behind SIMD-0553.

A resource fee and a priority fee remain conceptually separate: one prices requested resources and is burned, while the other offers leader-directed economic priority.

Builders should therefore avoid writing fee infrastructure around one transaction-format assumption forever.

What Solana's August 2026 analysis found

Before the binding governance vote closed, Solana Foundation published a data-focused analysis of SGP-0003.

The findings help explain why the proposal attracted serious debate rather than being treated as a minor parameter update.

Requested resources were often substantially above consumption

The analysis found that aggregate consumed cost was around 20% of requested cost in the examined sample.

Even transactions that explicitly configured both compute and loaded-account-data size were still over-requesting significantly on average.

This matters because SIMD-0553 would charge the request, not the eventual consumption.

Simple transfers could be relatively unaffected

Transactions with low scheduler cost could remain near current fee levels or become slightly cheaper depending on their exact resource profile.

This reinforces the point that SIMD-0553 was not simply a universal fee increase.

Complex routing was much more exposed

The Foundation analysis found materially larger fee impacts for transaction aggregators and resource-heavy on-chain routing.

That outcome follows directly from the proposed design. Complex routes request more resources, so they pay more resource fee.

Behavior would adapt

Any calculation based on current requests assumes developers do not respond to the new fee.

In reality, SDKs, routers, market makers and wallets would optimize aggressively once inefficient resource requests created visible costs.

That makes static estimates useful for stress testing but poor long-term forecasts.

Why burn estimates require caution

A fee proposal that burns more SOL naturally attracts tokenomics discussion, but the interaction between fees and supply is not a fixed spreadsheet.

Higher fee rates change behavior

If a resource-heavy strategy becomes uneconomic, the transaction may never be sent.

If a wallet learns to request half as much compute headroom, the resource fee falls.

If developers optimize program execution, requested cost can fall again.

A proposed fee rate therefore changes the activity that generates the fee.

Current over-requesting can exaggerate projected burn

If transaction builders currently ask for far more resources than they consume, applying a future resource fee to today's unoptimized requests creates an intentionally harsh counterfactual.

Once users pay for the request, they have an incentive to reduce it.

Burn does not automatically equal net deflation

SOL supply changes also depend on protocol issuance and other supply effects.

A larger transaction burn can offset more issuance without necessarily making total supply contract.

Any statement that SIMD-0553 would make SOL "deflationary" should therefore specify assumptions rather than presenting one sampled burn estimate as certainty.

Why accurate resource requests matter even after SGP-0003 was rejected

The governance rejection does not make transaction efficiency irrelevant.

Several incentives already reward accurate resource configuration.

Priority fee can already depend on requested CU limit

For legacy and version-0 transactions using a non-zero compute-unit price, requesting more CUs than necessary can increase the priority fee because the requested limit enters the calculation.

Requested cost affects scheduler priority

Solana's scheduler evaluates economic reward relative to transaction cost.

An unnecessarily expensive requested-cost profile can therefore make a transaction less attractive per unit of scheduler resource even before a dedicated resource burn exists.

Blockspace efficiency matters as Solana scales

Faster slots and larger block capacity do not eliminate resource constraints.

As activity grows, efficient use of compute, account locks and loaded data becomes increasingly important for throughput and latency.

SIMD-0553 may have been rejected as a specific economic mechanism, but the underlying resource-calibration problem remains technically relevant.

Transaction planning under the current fee model

Because the proposed resource fee is not active, builders should not artificially add it to current mainnet transaction costs.

They should still estimate fees using current RPC state and configure compute intelligently.

What ordinary users should look at in a transaction

Most retail users do not need to reproduce validator fee arithmetic manually.

They should know which numbers mean what.

Total transaction fee

This is the lamport amount deducted from the fee payer for processing the transaction.

It should not be confused with token swap price impact, protocol fees charged by a dApp or rent-related account funding.

Priority fee

This is an optional scheduling incentive.

A transaction can have a low program-level cost but a high priority fee if the sender aggressively bids for inclusion.

Compute-unit limit

The limit represents requested execution headroom, not necessarily what the programs actually consumed.

This distinction was central to SIMD-0553 and remains relevant to current priority-fee calculation.

Program-level charges

A swap, token transfer or application can impose economic effects separate from the Solana protocol transaction fee.

Always distinguish protocol fees from application fees.

For readers who want to inspect Solana instructions and fee-relevant transaction structure rather than relying on an explorer's abbreviated labels, the Solana Transaction Decoder guide provides a structured way to read transaction execution.

Worked fee examples

Example 1: basic one-signature transfer today

A user submits a simple transaction with one counted signature and no priority fee.

Under the current base-fee model, the transaction pays 5,000 lamports.

Approximately half of that base charge goes to the validator and half is burned under the current fee distribution.

There is no active SIMD-0553 resource fee added simply because the transaction requests scheduler resources.

Example 2: one-signature transaction with priority fee

A user chooses a priority fee of 20,000 lamports through the relevant compute-budget configuration.

The simplified economic structure is:

The base component follows the current burn/validator split, while the priority component goes to the validator.

Example 3: what SIMD-0553 would have done at 200,000 requested cost units

Assume one transaction, no priority fee and a hypothetical active resource-fee rate of 0.5 lamport per requested cost unit.

The resource fee would be 100,000 lamports.

That is far above the current 5,000-lamport single-signature baseline because the resource request is substantial.

Example 4: low-resource transaction under the proposed model

Suppose requested cost units were only 3,765, matching the optimized vote example used by the SIMD.

At the 0.5 rate, the resource fee would be 1,883 lamports after upward rounding.

This transaction would have been cheaper than today's 5,000-lamport one-signature base charge.

Example 5: over-requested compute

Two transaction builders execute the same program path.

Builder A carefully requests resources consistent with simulation.

Builder B requests several times more execution capacity than it realistically needs.

Under the rejected SIMD-0553 model, Builder B would pay more resource fee even if both ultimately consumed identical runtime compute.

This is the economic incentive the proposal was specifically trying to create.

Example 6: resource fee plus high priority

Imagine a complex arbitrage route with a 150,000-lamport proposed resource fee and a 2,000,000-lamport priority fee.

The full hypothetical fee would be:

The resource fee is meaningful, but the priority bid still dominates the total.

This illustrates why a statement such as "resource fees would make every high-priority transaction several times more expensive" is not necessarily correct. Percentage impact depends on the size of the priority fee already being paid.

Example 7: multi-signer transaction

Under today's fee structure, multiple applicable signatures increase the base fee.

Under SIMD-0553, the inclusion component would remain 2,500 lamports for the transaction, while the signature work would contribute to requested scheduler cost and therefore the burned resource charge.

This is one reason multi-signature applications would not experience the proposal in the same way as single-signer consumer transactions.

Example 8: failed fee-only transaction

Under the proposed activated model, a transaction that reaches fee-only handling because of certain loading failures could still be charged the full calculated inclusion, resource and priority fee even though normal execution never occurs.

A large requested-cost transaction could therefore fail and still incur a materially larger charge than users accustomed to a small flat fee expect.

Resource pricing, efficiency and network externalities

The economic intuition behind resource pricing extends beyond individual fee bills.

A transaction does not execute in isolation. Validators must receive it, verify it, schedule it, execute or reject it, propagate block data and replay the resulting block.

Write locks constrain parallelism

A transaction writing to hot accounts can interfere with parallel execution even if its raw compute consumption is modest.

This is why scheduler cost includes more than compute-unit execution.

Loaded account data uses memory and processing capacity

Transactions that require more account data impose a different resource profile from transactions touching a tiny state footprint.

A resource-aware design can theoretically price those differences better than one signature count alone.

Instruction data and signature work are not free

Even a program path with small runtime compute can carry other scheduler costs.

Requested cost units attempt to combine these dimensions into one resource measure the scheduler can already use before execution.

The strongest arguments in favor of SIMD-0553

Although the governance vote rejected SGP-0003, the proposal addressed real technical and economic questions.

More direct resource pricing

Transactions with substantially different scheduler footprints would no longer pay nearly identical base charges simply because they contain the same number of signatures.

Stronger incentive to stop over-reserving

Applications would have a direct monetary reason to estimate compute and loaded data more accurately.

Greater SOL burn from resource-intensive activity

The proposal could increase burn when high-resource usage remains strong, connecting part of SOL's supply reduction more directly to network resource demand.

Leader incentives remain straightforward

The leader gets a predictable inclusion payment plus existing priority revenue rather than receiving a share of the resource charge.

Low-resource work could be cheaper

A resource-pricing design does not necessarily punish every user. Transactions that genuinely impose little scheduler cost can pay less than the current flat one-signature base fee under the proposed terminal model.

The strongest concerns around SIMD-0553

The rejection also makes more sense when the drawbacks are examined carefully.

Existing resource requests were poorly calibrated

Charging transactions based on today's requested cost could produce unexpectedly large fee increases before wallets and applications optimize.

The Foundation's own analysis documented substantial over-requesting.

Trading infrastructure could face meaningful operating-cost increases

Aggregators, CLOB market makers and complex routes often use more resources than simple transfers.

Those systems operate at high frequency, so even small per-transaction increases accumulate.

The lowest transaction-cost floor could decline

Extremely cheap transactions could cost less than today's 5,000-lamport baseline, potentially reducing one economic barrier to minimal spam.

The transition creates compatibility requirements

Every validator implementation must calculate the same fee. Wallets, SDKs and RPC services must estimate it correctly. Fee payers funded around old assumptions can fail.

Economic behavior is difficult to forecast

A resource fee changes routing, batching, market making, compute optimization and spam economics simultaneously.

Projected burn and fee revenue depend on how participants respond.

What the governance rejection means

Rejecting SGP-0003 does not prove that resource-based fees can never return to Solana.

It means this proposal did not obtain approval through the binding governance process that concluded on August 28, 2026.

The technical problem remains discussable

Resource over-requesting, scheduler economics and transaction-cost allocation are still real engineering topics.

A later proposal could use a different rate, different measurement, different burn allocation, different rollout or completely different fee mechanism.

Do not assume the defined feature gates will activate anyway

The mere existence of feature IDs in a SIMD is not activation.

Mainnet behavior depends on governance, implementation support and actual feature state.

Future articles should check live fee documentation again

Solana protocol development moves quickly. If a replacement resource-fee proposal appears later, readers should compare its text with SIMD-0553 rather than assuming every parameter remains the same.

How to tell whether Solana's fee model has actually changed

How to investigate an unexpectedly expensive Solana transaction

A user seeing a surprisingly large fee should not immediately conclude that a resource fee has been activated.

As of September 6, 2026, that is not the active mainnet explanation.

Check the priority fee first

A high priority bid can dominate the transaction fee.

During competitive trading or congestion, automated systems may intentionally pay much more than the ordinary base fee.

Check how many signatures are fee-relevant

The current base fee scales with applicable signature count.

Multi-signer transactions can therefore cost more even before priority is considered.

Separate protocol fees from dApp economics

A swap can include trading fees, price impact, token transfers and priority fees in one user experience.

Only part of the economic cost may be Solana's protocol transaction fee.

Decode the signature

The Solana Transaction Decoder can help inspect transaction structure when a wallet summary is too shallow to explain where value moved or why the transaction failed.

Fee analysis is not wallet-risk analysis

An expensive transaction and a dangerous wallet are different questions.

A legitimate arbitrage system can intentionally pay a large priority fee. A compromised wallet can execute a cheap malicious transfer. Protocol fee size alone does not classify the transaction as safe or unsafe.

When the broader concern is an address's behavior, counterparties or transaction history, the Solana Wallet Risk Scanner provides a wallet-level research layer separate from transaction-fee interpretation.

Fee mechanics do not determine token safety

SIMD-0553 is a protocol-economic proposal. It says nothing about whether a token mint is legitimate, whether mint authority remains active, whether liquidity is deep or whether a token's holder distribution is healthy.

Those questions require separate evidence.

If a transaction involves an unfamiliar Solana token, the Solana Token Scanner can help examine mint-level context rather than treating transaction fee behavior as a token-quality signal.

What builders should take away even though the proposal failed

The biggest engineering lesson is not "ignore SIMD-0553 because it was rejected."

The proposal highlighted inefficiencies that already affect scheduling and priority economics.

Stop using compute limits as arbitrary large constants

A static maximum is easy to implement but can produce poor scheduling and unnecessary priority fees.

Simulation-driven limits are usually a better foundation.

Understand loaded-account-data requirements

Account-data loading can become a meaningful resource dimension, particularly as Solana continues increasing throughput.

Keep fee logic upgradeable at the application layer

Wallets and SDKs should query current network conditions instead of embedding the assumption that today's base-fee formula can never change.

Separate fee components in internal telemetry

Even if users see one total, applications should understand how much of their cost comes from base signatures, priority bidding and application-level fees.

Record requested and consumed compute

That data makes it possible to quantify over-requesting before a future protocol change makes it more expensive.

A planning framework for market makers and bots

High-frequency senders should evaluate fee changes in expected-profit terms rather than looking only at average lamports per transaction.

Measure resource requests by strategy

Do not average a simple oracle update together with a multi-hop route. Different transaction families can have very different scheduler footprints.

Measure successful and failed submissions

A strategy that broadcasts ten attempts for one profitable execution has a different fee exposure from a strategy that lands nearly every transaction.

Measure request efficiency

Track requested compute against actual compute consumed.

Even without resource burn, this can reveal opportunities to improve priority efficiency.

Recalculate minimum profitable alpha under proposed fee changes

If another resource-fee proposal emerges, model the resulting fee against each strategy's actual requested scheduler cost rather than using a network-wide average.

A planning framework for validators

Validator operators need a different set of questions because fee changes affect both expenses and revenue.

Leader revenue

Model the share of current base-fee revenue derived from single-signature versus multi-signature transactions.

Vote costs

Before Alpenglow fully removes the traditional on-chain vote-transaction burden, validators should keep vote resource requests efficient.

Client compatibility

A consensus fee change requires all relevant validator clients to agree on fee calculation and burn accounting.

A disagreement is not merely a wallet display bug. Burn totals influence bank state and consensus verification.

Feature activation

Operators should distinguish support in a release from activation on a cluster.

A binary can understand a feature for weeks or months before the feature becomes active.

A planning framework for RPC providers

RPC operators sit between rapidly changing protocol state and applications that expect reliable estimates.

Fee estimation must be bank-aware

If a fee model activates at an epoch boundary, the endpoint needs to calculate according to the bank being queried or simulated.

Caches need careful invalidation

Fee estimates that are safe one epoch can become stale when feature state changes.

Simulation and fee responses need consistency

An application should not receive one expected fee from getFeeForMessage and a materially incompatible figure during preflight for the same bank state.

Historical transaction data needs context

If Solana eventually changes fee models, analytics systems should know which rule set was active at a transaction's slot before comparing historical fee behavior.

The deeper economic idea behind resource pricing

SIMD-0553 belongs to a broader class of blockchain fee designs asking a simple question: what scarce thing should users pay for?

A signature is one measurable resource.

Compute is another.

Writable state contention is another.

Loaded account data is another.

Network propagation, storage and execution all impose costs with different bottlenecks.

Flat fees are simple but imprecise

A flat fee creates predictable UX and very cheap accounting.

Its weakness is cross-subsidization. Lightweight transactions and expensive transactions can pay similar base charges.

Resource fees are more expressive but more complex

Charging by scheduler cost aligns price more closely with requested work.

The cost is additional estimation complexity and more sensitivity to how the resource model itself is calibrated.

The resource metric becomes economically important

Once a cost-model number determines money, errors in that cost model have more visible consequences.

An operation that is systematically over-priced in scheduler units becomes systematically more expensive.

An operation that is under-priced can consume more real resources than it pays for.

Resource pricing therefore makes cost-model accuracy an economic design problem, not merely a scheduler implementation detail.

Could a revised resource-fee proposal return?

Yes, but future adoption should not be assumed.

SIMD-0553 documented one possible design. SGP-0003 tested that design through governance and was rejected.

A future proposal could modify almost any part of it.

The rate could change

The 0.1, 0.25 and 0.5 lamport stages are not universal constants. They belonged to this proposal.

The burn share could change

A future mechanism could choose another distribution between burn, validators or another economic destination.

The measured resource could change

A later proposal might price only some scheduler components, use congestion-sensitive rates, target hot accounts or introduce a dynamic controller.

Rollout governance could change

Solana's governance process itself is evolving. Future protocol economics may go through additional discussion, testing and binding votes before any feature gate becomes active.

Readers interested in this broader layer of consensus, validator economics and protocol evolution can continue through TokenToolHub's advanced blockchain guides.

Common misconceptions about SIMD-0553

Solana already charges the SIMD-0553 resource fee

No. SGP-0003 was rejected on August 28, 2026. Current official Solana fee documentation continues to describe the existing per-signature base fee.

The resource fee was just another name for the priority fee

No. The proposed resource fee would have been burned and based on requested scheduler cost. Priority fees are separate and paid to the leader.

The proposal charged only for compute units

No. Requested cost units included signature cost, write-lock cost, instruction-data cost, requested program-execution cost and requested loaded-account-data cost.

The proposal charged actual compute consumed

No. The fee used requested pre-execution scheduler cost.

Unused requested compute would have been free

No. Over-requesting would directly increase the resource fee because the request, not post-execution consumption, was the basis of the calculation.

Every transaction would have become more expensive

No. Low-resource transactions could have become cheaper than today's 5,000-lamport single-signature base charge, while resource-heavy transactions could become materially more expensive.

Validators would receive the new resource fee

No. The proposal specified that the resource fee be burned in full.

The 2,500-lamport inclusion fee would be burned

No. It would be paid entirely to the block leader.

Priority fees would be burned under SIMD-0553

No. The proposal preserved priority-fee distribution to the leader.

The new inclusion fee was 2,500 lamports per signature

No. SIMD-0553 proposed a 2,500-lamport inclusion fee per transaction.

Acceptance in July meant immediate mainnet activation

No. Protocol-document status and feature activation are different processes. The design later went through binding governance and was rejected.

A resource fee would automatically eliminate spam

No. Resource-heavy spam would become more expensive, but the proposal could lower the absolute fee floor for very cheap transactions.

Higher burn guarantees SOL becomes deflationary

No. Net supply depends on issuance and other supply changes as well as burn, and user behavior can change substantially in response to fees.

What users and builders should do now

A transaction-observation workflow

If Solana fee behavior changes in the future, the most reliable way to understand it is to observe the chain rather than extrapolate from an old proposal.

Conclusion: SIMD-0553 matters even though its fee model is not live

SIMD-0553 is one of the most useful Solana fee proposals to study because it exposes the difference between paying for transaction inclusion and paying for the resources a transaction asks the network to reserve.

Under Solana's current fee system, the baseline remains centered on signatures.

The live base fee is 5,000 lamports per applicable signature. Half is burned. Half is paid to the block-producing validator. An optional priority fee sits on top and is paid to the validator.

SIMD-0553 proposed decomposing that structure.

The leader would receive a flat 2,500-lamport inclusion fee for each transaction.

The network would then calculate a separate resource fee using requested scheduler cost.

That scheduler cost was broader than compute alone. It included signature cost, write locks, instruction data, requested program execution and requested loaded-account-data size.

The full resource fee would be burned.

Priority fees would continue serving a different function by rewarding the leader for scheduling a transaction competitively.

The proposal therefore separated three questions:

How much should the leader receive for including the transaction?

How much should the transaction pay for the resources it reserves?

How much extra does the sender want to bid for priority?

That separation would have created significant new incentives.

Applications that routinely requested far more compute than they needed would begin paying directly for the excess.

Wallets would need better estimation.

Market makers would need to measure costs at high transaction volumes.

Aggregators would need to judge whether a more complex route still delivered better net execution after resource fees.

Validators would see a different revenue composition, particularly for multi-signer transactions.

Resource-heavy spam would become more expensive while the absolute floor for minimal transactions could fall.

Burn could increase significantly, but the amount would depend on how quickly applications optimized their requests and how much activity remained economical.

The proposal also exposed a broader engineering fact: Solana transactions often request substantially more capacity than they ultimately consume.

That matters even though SGP-0003 failed.

Requested compute already influences priority-fee costs for legacy and v0 transactions when a non-zero CU price is used. Requested scheduler cost also influences how validators reason about transaction priority and block packing.

Efficient resource requests are therefore not wasted work.

The current status is equally important.

Solana Foundation's July 23, 2026 changelog described the Resource and Inclusion Fees SIMD as accepted. That was not mainnet activation. The proposal subsequently entered binding governance as SGP-0003, and the vote closed rejected on August 28, 2026.

As of September 6, 2026, users should not add a SIMD-0553 resource fee when interpreting live Solana mainnet transactions.

They should follow current fee documentation and actual network state.

If another resource-pricing proposal emerges, do not assume it will reuse the same rates or economics. Check the new specification, governance result, client support and feature activation separately.

For transaction-level verification, the Solana Transaction Decoder can help show what actually executed and what fee was charged. For transaction-analysis methodology, use the decoder guide. Wallet-level behavior can be investigated with the Solana Wallet Risk Scanner, while unfamiliar assets can be checked separately through the Solana Token Scanner.

The larger lesson is that transaction cost is becoming a first-class protocol-design question as Solana pushes toward higher throughput, shorter slots and more sophisticated execution.

A fee is not only something a user pays.

It shapes which transactions are economical, how builders allocate resources, what validators are rewarded for, how applications batch work and how efficiently scarce block capacity is used.

SIMD-0553 did not become Solana's live fee model, but the problems it tried to solve remain part of the network's long-term scaling conversation.

FAQs

References and further reading

These sources document the SIMD-0553 design, current Solana fee mechanics, the July 2026 status update and the later analysis surrounding SGP-0003.

• Solana Improvement Documents: SIMD-0553 Base Inclusion and Resource-based Fee
• Solana Changelog: July 23, 2026
• Solana Foundation: Resource and Inclusion Fee, Digging into Data
• Solana Documentation: Fees
• Solana Documentation: Fee Structure
• Solana Documentation: Compute Budget
• Solana Validator Governance

This guide is educational technical research. Solana transaction fees, transaction formats, feature gates and governance decisions can change. SIMD-0553 and SGP-0003 are discussed here because they define an important resource-pricing design, but SGP-0003 closed rejected on August 28, 2026. Check current Solana documentation, governance and active network features before implementing production fee assumptions.