SIMD-0553: Resource and Inclusion Fee

[cavemanloverboy]

Summary

(Note: Although it's reframed a bit, the design is identical to that in the originating discussion with a higher resource_fee_rate, with the additional change of 5000->2500 to the base fee.)

SIMD-0553 splits today's 5000-lamport per-signature fee (2500 burned / 2500 to the leader) into:

• Base inclusion fee — 2500 lamports per signature, 100% to the leader (same leader pay as today, renamed).
• Resource fee — requested_cost_units × resource_fee_rate, 100% burned (replaces the flat burned half; scales with scheduler cost). Initial resource_fee_rate = 0.5.

Goal: tie SOL burn to real resource use. Low-resource-usage txs (votes, oracle updates) can pay slightly less than today's 5000 lamport base fee if we use a resource_fee_rate of 0.5; high-compute, zero-priority txs pay much more (see examples in the doc).

Rough burn ~7.5–9k SOL/day vs ~648 SOL/day today.

[simd-bot]

Hello cavemanloverboy! Welcome to the SIMD process. By opening this PR you are affirming that your SIMD has been thoroughly discussed and vetted in the SIMD discussion section. The SIMD PR section should only be used to submit a final technical specification for review. If your design / idea still needs discussion, please close this PR and create a new discussion here.

This PR requires the following approvals before it can be merged:

• At least one approval from a Anza team member: t-nelson, steviez, or bw-solana
• At least one approval from an Firedancer team member: ptaffet-jump, topointon-jump, 0x0ece, lidatong, ripatel-fd, or rexicon226

Once all requirements are met, you can merge this PR by commenting /merge.

[bw-solana]

Left some comments.

That said, I'm a little concerned we don't have enough alignment on:

1. Pre/post Alpenglow and how to deal with votes
2. Using cost units as the ruler
3. The 0.5 multiplier

and thus talking about bits and bytes is time wasting

[bw-solana]

looks like we're implicitly suggesting we take the ceiling of cost_units * resource_fee_rate, we should specify that somewhere

[cavemanloverboy]

yes, will update

[bw-solana]

pedantic: we should specify which signatures we're talking about here explicitly (just transaction level, or inclusive of precompiles)

[cavemanloverboy]

will do this

[bw-solana]

might be good to be explicit about what goes into this. The sum of:

1. signature cost
2. write-lock cost
3. instruction-data cost
4. program-execution cost
5. loaded-account-data-size cost

[bw-solana]

this seems like a de facto MUST when it comes to default client implementation.

Should we also mention SIMD-0387 as a dependency? I believe that is the one that creates the change in how vote costs are classified.

What is the vote cost after adding CBP ixs to set max CUs/data?

[cavemanloverboy]

isn't it this one? already live?

[bw-solana]

@tao-stones can you chime in?

[tao-stones]

SIMD-0458 is live in mnb. The cost-model charges simple vote transaction same as normal transaction, it's compute units count is:
1,440 signatures + 600 write locks + 19 instruction data + 200,000 execution allocation + 16,384 loaded-account data (for default 64MiB) = 218,443 units

[tao-stones]

If to use CBP ixs, client would request 1 page (32KiB) for loaded accounts, then request ~4,500CU for compute-units, which includes:

• 2,100 CU for Vote ix,
• 2*150 =300 CU for 2 CBP ixs,
• 8 for loaded accounts size (for 1 page size)
• ~2,000 for signatures, write locks and instruction data

Note, by adding CBP ixs to legacy vote transaction, it not longer qualifies as "Simple Vote" transaction. The concept of "Simple Vote" is going away, but the flag still exists and have effects on current execution path.

Client could also send vote with v1 transaction, setting compute-units and loaded-accounts-data-size without CBP.

[bw-solana]

might be good to specify exactly when the new fee model should take place. Presumably if it goes active on the transition from Epoch E -> E+1, you want the new fees in place starting with the first slot in E+1.

But this could create an awkward transition for anyone using transaction sim on the boundaries.

(I'm still fine with doing the obvious thing, just think we should spell it out)

[cavemanloverboy]

ok i will do this.

[tao-stones]

I understand the stated "split the present static (base fee) ..." as two separate proposals:

1. lower signature fee in half, reward 100% to leader
2. introducing requested-cu based fee, 100% burned. This better align burn and resource usage.

They are related, but don't have to depend on each other.

[cavemanloverboy]

the reason why they must depend on each other is precisely because if done separately either

1. vote costs are way too high (if base stays the same with new resource fee)
2. dos attacks are super cheap (if base halves before new resource fee)

[tao-stones]

thanks for clarifying, it makes sense

[tao-stones]

SIMD-0458 is live in mnb. The cost-model charges simple vote transaction same as normal transaction, it's compute units count is:
1,440 signatures + 600 write locks + 19 instruction data + 200,000 execution allocation + 16,384 loaded-account data (for default 64MiB) = 218,443 units

[tao-stones]

If to use CBP ixs, client would request 1 page (32KiB) for loaded accounts, then request ~4,500CU for compute-units, which includes:

• 2,100 CU for Vote ix,
• 2*150 =300 CU for 2 CBP ixs,
• 8 for loaded accounts size (for 1 page size)
• ~2,000 for signatures, write locks and instruction data

Note, by adding CBP ixs to legacy vote transaction, it not longer qualifies as "Simple Vote" transaction. The concept of "Simple Vote" is going away, but the flag still exists and have effects on current execution path.

Client could also send vote with v1 transaction, setting compute-units and loaded-accounts-data-size without CBP.

[tao-stones]

From original discussion, where condition's opposite: tons of traffic, lots of heavy transactions; with proposed 100% burn Resource Fee (based on often over-requested compute units), would daily burns exceed inflation significantly?

[cavemanloverboy]

no it is bounded and does not scale with traffic in the same way that priority fee does. it will certainly increase but only by a factor of 2 or so on average is my hunch... until block limits are removed...

[tao-stones]

block limits only applies to actual compute units. requested compute units technically are not bounded by it (but do by tx CU limit, and indirectly by number of large txs can be packed in one block), heavy/complex transactions are likely to over-requesting CUs, potentially leads to over-burning.

[tao-stones]

to clarify - in case of fee-only, tx will be charged by Base inclusion fee + Resource fee?

[cavemanloverboy]

and priority fee, as is the case now. right?

[tao-stones]

right, was focusing on the base fee split part.

[cavemanloverboy]

but my point i guess is that fee-only behavior stays the same (user still pays their full fee).

i agree however that the simd should be updated to state this explicitly. i will do this

[tao-stones]

Seems number of signatures are accounted in both Base inclusion fee and Resource fee. Why can't Base inclusion fee be a simple static number, so number of signatures are not double counted?

[cavemanloverboy]

there's a note about this down below, ctrl+f "legacy"

[tao-stones]

yea, was thinking setting base inclusion fee to a static value would make things a bit easier

[cavemanloverboy]

i agree but if you were to do that now before update cost model to make sigs more expensive, the cost per txn for multiple sigs would be very low

[cavemanloverboy]

so i think the move should be:

1. inclusion fee * sigs (for legacy reasons) with cheaper sig-component of resource based fee
2. increase sig-component of resource based fee by updating cost model
3. remove *sig multiplicand on inclusion fee

[tao-stones]

nit: should Impact section includes:

• changes economics for estimation cu limit, over-estimating = over paying, which may lead to large changes on existing app.

[tao-stones]

Another possible consideration: potentially makes it cheaper (as much as half) to construct dos attack

[cavemanloverboy]

this is here? i can explicitly mention dos but i assumed it would be implied

[MaxResnick]

I'm in favor but would prefer to keep the base signature fee where it is at 5000 lamports. I think its too low already at about $0.0003 per tx.

[gwalen]

Writing this as an everyday Solana developer.

I’m not sure this is the right place for this kind of discussion, so forgive me if it isn’t. I found this while reading the latest Solana Changelog post on twitter.

We already have the base fee, priority fee, and, on top of that, tips such as Jito/Nozomi.

Now this proposal adds a resource fee, with a fairly complicated charging scheme.

While I understand the need to increase SOL burn, I think adding another fee component could be bad for DX and add more complexity.

From a developer’s point of view, this would mean dealing with 3 protocol-level fee components, plus tips on top, for a total of 4 separate payment components. Usually, blockchain developers only need to think about 2 protocol-level fee components.
This proposal would push Solana to 3 protocol-level fee components, plus external tips in practice. That makes the fee model harder to explain and reason about.

On top of that, many people will read this as: “transactions on Solana are getting more expensive.” Even if that is not true for every transaction, I think that will still be the public perception, which could be bad optics.

My main concern is day-to-day developer experience and the ease of onboarding new people into the Solana ecosystem.

That said, I know I have only a fraction of your knowledge about Solana internals, but I just wanted to share my “regular” Solana developer’s point of view.

[MartinH-001]

I agree that keeping it as simple as possible is important. But in the same time I don´t have any better idea than the one presented by the author of this SIMD.

1. The burn has to increase somehow. It is not optional but absolutely necessary otherwise the current tragic supply-demand imbalance will inevitably keep pushing SOL price down over the long-term. Since the burning of 50% of the whole fee was abandoned, SOL started strongly underperforming things like BNB and TRX which may have not as good tech but maintain consistent deflationary policy. If you look at monthly charts it is clearly visible that the chart started behaving differently after that change. I am not advocating for pumping quickly SOL token by implementing some quick tokenomics fix and then cashing out. But Solana is not Linux. SOL can not be free or depreciating long-term, because the token value needs to guarantee security and attract capital and developers. So extra burn is absolutely essential for long-term viability of Solana.

2. What are the alternatives to resource-usage fees? Fees based on value of transaction are legally not possible. Flat fees would make simple transactions too costly. Resource-usage based fees are complicated but still they seem like the least bad option after all.

3. I did a quick calculation and even after the fee increase Solana average fee would be cheaper than Arbitrum or Base. This is based on the estimates mentioned by the author of this proposal and the average Solana, Base and Arbitrum fees last week according to Google AI.

4. BNB and Tron have much higher fees and users are not leaving, on the contrary the number of users is increasing. A slight suggested increase of Solana fee in my opinion will not discourage new users. Fees is not everything. The liquidity, ecosystem, security, speed etc. ... users will be still getting the top tech and ecosystem for one of the lowest fees in the industry.

5. Solana at the moment is undercharging, because the fees do not cover the cost of security. Validators are still subsidised by issuance. And with the current burn mechanism even if there were many times more transactions Solana would still be inflationary. So fees and burn have to increase somehow for Solana to become economically viable. There is simply no way around it, and the sooner it is done, the better. This is not the case just for Solana but almost all pubic decentralized blockchains, so eventually they will also have to increase fees or fade into irrelevance due to ongoing long-term token price depreciation caused by structural supply surplus. Solana has the advantage that it is one of very few blockchains that can realistically achieve economic viability in very near future by combining slight increase of burn (this proposal), slight reduction of issuance (SIMD-0550: Double disinflation #550) and general increase of network activity.

[gwalen]

In principle, I agree with your arguments.
In particular, the point about deflation stands.
But, as always, there is a trade-off.

We are increasing complexity, and under the current design some low-fee, zero-priority transactions would become ~32x more expensive. That is a large jump.

Some kind of deflation mechanism may be needed, but I wonder whether this is the best way to achieve it.

We already have a default CU limit per instruction when SetComputeUnitLimit is not explicitly set. Could we instead add a default mandatory priority fee when none is specified, or when the specified fee is below some minimum threshold?
That would be less precise than the current proposal, but it could avoid introducing a third fee component (resource fee) and preserve the simpler fee model people are already used to, with only a small adjustment.

[cavemanloverboy]

I'm in favor but would prefer to keep the base signature fee where it is at 5000 lamports. I think its too low already at about $0.0003 per tx.

the long term plan outlined by the simd is to

1. eventually turn the base fee into an inclusion fee (required for MCP)
2. increase cost of signatures by fixing signature cost (and other things while we are at it) in cost model.

so the base cost for 1-signature txns can be made higher and argued in the follow-up simd.

[cavemanloverboy]

In principle, I agree with your arguments. In particular, the point about deflation stands. But, as always, there is a trade-off.

We are increasing complexity, and under the current design some low-fee, zero-priority transactions would become ~32x more expensive. That is a large jump.

Some kind of deflation mechanism may be needed, but I wonder whether this is the best way to achieve it.

We already have a default CU limit per instruction when SetComputeUnitLimit is not explicitly set. Could we instead add a default mandatory priority fee when none is specified, or when the specified fee is below some minimum threshold? That would be less precise than the current proposal, but it could avoid introducing a third fee component (resource fee) and preserve the simpler fee model people are already used to, with only a small adjustment.

some low-fee, zero-priority compute-heavy* transactions will become 32x more expensive. this introduces an incentive for those inefficient programs in question to optimize their programs, which is a healthy incentive long term imo. there might be a 32x sudden jump for some, but after optimization (for the case of pump/helium, as simple as anchor v2 migration), the jump will be lower.

[cavemanloverboy]

ok me and my clanker addressed everything here pretty sure. @tao-stones @bw-solana.

[MartinH-001]

In principle, I agree with your arguments. In particular, the point about deflation stands. But, as always, there is a trade-off.

We are increasing complexity, and under the current design some low-fee, zero-priority transactions would become ~32x more expensive. That is a large jump.

Some kind of deflation mechanism may be needed, but I wonder whether this is the best way to achieve it.

We already have a default CU limit per instruction when SetComputeUnitLimit is not explicitly set. Could we instead add a default mandatory priority fee when none is specified, or when the specified fee is below some minimum threshold? That would be less precise than the current proposal, but it could avoid introducing a third fee component (resource fee) and preserve the simpler fee model people are already used to, with only a small adjustment.

I am certainly up for any simplification. But making some minimum priority fee mandatory would not solve the burn problem, because all priority fees are paid as reward and not burned. Vote on re-introducing again 50% priority fee burn would probably not pass if in the past super-majority voted for abandoning it. I am not sure that the understanding, that removing the burn actually reduced the profit for stakers by creating large supply/demand imbalance that pushes SOL price down long-term, has reached the majority of stakers yet ...

[cavemanloverboy]

In principle, I agree with your arguments. In particular, the point about deflation stands. But, as always, there is a trade-off.
We are increasing complexity, and under the current design some low-fee, zero-priority transactions would become ~32x more expensive. That is a large jump.
Some kind of deflation mechanism may be needed, but I wonder whether this is the best way to achieve it.
We already have a default CU limit per instruction when SetComputeUnitLimit is not explicitly set. Could we instead add a default mandatory priority fee when none is specified, or when the specified fee is below some minimum threshold? That would be less precise than the current proposal, but it could avoid introducing a third fee component (resource fee) and preserve the simpler fee model people are already used to, with only a small adjustment.

I am certainly up for any simplification. But making some minimum priority fee mandatory would not solve the burn problem, because all priority fees are paid as reward and not burned. Vote on re-introducing again 50% priority fee burn would probably not pass if in the past super-majority voted for abandoning it. I am not sure that the understanding, that removing the burn actually reduced the profit for stakers by creating large supply/demand imbalance that pushes SOL price down long-term, reached the majority of stakers yet ...

in a future where there is protocol-enforced ordering (before and after MCP), resource fee vs priority fee are independent axes. i think this three-component fee is basically what we will end up at, so it introduces no complexity beyond what will eventually be introduced. This is beyond the scope here but MCP may introduce a fourth (success) fee, in fact:

1. inclusion fee paid to proposer (not leader)
2. priority fee, fully burned (used in sorting)
3. success fee, fully burned (used to break sorting tie. can be thought of as in-protocol "tip". figuring out why this doesn't just go into priority fee is left as an exercise to the reader :P)
4. resource fee, fully burned (not used to sort; does not affect in-protocol ordering at all)

under MCP, and more generally under any system with in-protocol ordering, it does not make sense for the leader to get any revenue otherwise the leader has an advantage on their own slots which is the whole thing in-protocol ordering is attempting to avoid.

This would be a post-mcp discussion, but if the full prio fee burn is enough after MCP, then i think we can make a plan to remove the resouce based fee after that. But that's about 18-24 months away and this SIMD can do quite a bit of good from now until then (and also hedge against further delays).

[bw-solana]

MUST*

[cavemanloverboy]

will rewrite this

[bw-solana]

This makes the tokenomics of SOL unsound.

advocacy language doesn't belong in the SIMD

[apfitzge]

Overall very supportive of the SIMD. Compute on the network should not be free. Would like to see a couple clarifications and I feel pretty strongly that something you listed as out of scope should be brought within scope. See those comments.

I will also comment here about the general compute/cost unit contention. Cost units are the meter we have now, if we want to make a change now, they are the tool we have. IF we have a better measure in the future, I'm fully in support of moving to that, but we don't have it now.

[apfitzge]

I think the idea here is that zero-prio txns shouldn't just be dropped since they do not reward the leader.

Is there a reason this base reward to leader should scale with number of signature, aside from current behavior? Why not just use an actual static inclusion like 2500 lamports per txn?

My motivation in this comment is that it gives less of a special-case to signatures in terms of economic cost. Just treat them more similarly to how we treat other compute.
Additionally, we already model the computational cost of the different signatures differently...we have pre-compiles at nearly an order of magnitude ore expensive than top-level signatures, yet the cost to user is exactly the same! I'd rather we just move to something that is more consistent, this proposal is a fantastic opportunity to do so.

[bw-solana]

agree. Use inclusion cost to:

1. Nudge things towards the 5k lamport "base fee" concept we're familiar with today w/o having to overhaul cost model.
2. Incentivize leader to pack
   Separately, encompass signature cost as just another dimension of overall resource cost

[apfitzge]

see my previous comment - I do not think this is out of scope. Let's just move straight to a consistent model of flat_fee + resource_fee + priority_fee.

[apfitzge]

Doesn't belong in this section, but do not see it mentioned elsewhere.

IMO we should explicitly call out nonces. I do not think they should get any special treatment here, after activation they will get charged more. However, this does introduce the case where a txn signed a very long time ago costs more if executed after the activation.

[MartinH-001]

I'm in favor but would prefer to keep the base signature fee where it is at 5000 lamports. I think its too low already at about $0.0003 per tx.

I agree to keep the base fee as it is at 5000 of which 2500 is burned and 2500 goes to validators and just add a new resource-based fee.

So the total fee would be

• base fee (keep as it is)
• resource-based fee (new, burn 100%)
• priority fee (keep as it is)

I think it is not necessary to reduce the base fee when SIMD-0296 expands the maximum transaction packet size 4x.

[bw-solana]

after chatting w/ @cavemanloverboy and @apfitzge my understanding is we'll rework to be something like the following:

1. Flat base inclusion fee to leader - decoupled from signature counts
2. Prio Fee unchanged (goes to leader)
3. Cost unit (resource) multiplier burn.

We will use a multi feature gate ladder up to 0.5 multiplier (likely 0.1, 0.25, 0.5). We will be conservative in ramping up multiplier so we can give people a chance to experience increased fees and optimize programs before their costs shoot up immediately. We also don't want to drastically increase cost for cheap operations like oracle updates

Part of the appeal of this approach is:

1. Not drag cost model updates into this SIMD, which would blow it up substantially
2. Not drastically overhaul market structure and builder incentives

Then in future SIMD(s), we get the cost model more accurate so that the resource costs align more closely to what they're costing the cluster.

I'm fine with 2.5k, 3k, 5k, or whatever as the base fee. I lean towards something like 4k lamports because it ends up fairly close to the 5k lamport min fee of today for most cheap operations and increasing operational cost of, e.g. oracle updates, feels like a silly side effect of what we're trying to do here and not the place to stall out for getting this across the line.

[cavemanloverboy]

after chatting w/ @cavemanloverboy and @apfitzge my understanding is we'll rework to be something like the following:

1. Flat base inclusion fee to leader - decoupled from signature counts
2. Prio Fee unchanged (goes to leader)
3. Cost unit (resource) multiplier burn.

We will use a multi feature gate ladder up to 0.5 multiplier (likely 0.1, 0.25, 0.5). We will be conservative in ramping up multiplier so we can give people a chance to experience increased fees and optimize programs before their costs shoot up immediately. We also don't want to drastically increase cost for cheap operations like oracle updates

Part of the appeal of this approach is:

1. Not drag cost model updates into this SIMD, which would blow it up substantially
2. Not drastically overhaul market structure and builder incentives

Then in future SIMD(s), we get the cost model more accurate so that the resource costs align more closely to what they're costing the cluster.

I'm fine with 2.5k, 3k, 5k, or whatever as the base fee. I lean towards something like 4k lamports because it ends up fairly close to the 5k lamport min fee of today for most cheap operations and increasing operational cost of, e.g. oracle updates, feels like a silly side effect of what we're trying to do here and not the place to stall out for getting this across the line.

keep in mind that the minimum cost model cost of a txn is 1080, so at the terminal resource fee rate of 1/2, the min txn fee is inclusion_fee + 540. This is why i don't think we should use 5000. 3000-4000 is reasonable. for oracles which use about ≈2000 cost units, it brings min fee to about 4000-5000 lamports (with zero priority).

however, note that moving this fee will impact leader incentives, as the validator income from the base fee increases by 20-60% (so the priority fee market structure will change). 3000 seems to be the right choice for optimizing these two things (minimizing impact to builder incentive, keeping txn fees close to original fee for small txns).

[apfitzge]

A few lints to fix, but I am happy with the proposal as is. Changes to cost-model can be done separately to make sure that signatures are not under-charged.

[cavemanloverboy]

A few lints to fix, but I am happy with the proposal as is. Changes to cost-model can be done separately to make sure that signatures are not under-charged.

fixed lints (skip line length for tables with pubkeys)

[simd-bot]

Thanks, bw-solana!

⚠️ Status: Cannot merge yet

• Missing approval from: Firedancer (ptaffet-jump, topointon-jump, 0x0ece, lidatong, ripatel-fd, or rexicon226)

[MartinH-001]

after chatting w/ @cavemanloverboy and @apfitzge my understanding is we'll rework to be something like the following:

1. Flat base inclusion fee to leader - decoupled from signature counts
2. Prio Fee unchanged (goes to leader)
3. Cost unit (resource) multiplier burn.

We will use a multi feature gate ladder up to 0.5 multiplier (likely 0.1, 0.25, 0.5). We will be conservative in ramping up multiplier so we can give people a chance to experience increased fees and optimize programs before their costs shoot up immediately. We also don't want to drastically increase cost for cheap operations like oracle updates

Part of the appeal of this approach is:

1. Not drag cost model updates into this SIMD, which would blow it up substantially
2. Not drastically overhaul market structure and builder incentives

Then in future SIMD(s), we get the cost model more accurate so that the resource costs align more closely to what they're costing the cluster.

I'm fine with 2.5k, 3k, 5k, or whatever as the base fee. I lean towards something like 4k lamports because it ends up fairly close to the 5k lamport min fee of today for most cheap operations and increasing operational cost of, e.g. oracle updates, feels like a silly side effect of what we're trying to do here and not the place to stall out for getting this across the line.

So under this model the only thing that gets burned is the new resource fee?

What is the estimated burn if it gets implemented with the suggested multipliers?

[cavemanloverboy]

after chatting w/ @cavemanloverboy and @apfitzge my understanding is we'll rework to be something like the following:

1. Flat base inclusion fee to leader - decoupled from signature counts

2. Prio Fee unchanged (goes to leader)

3. Cost unit (resource) multiplier burn.

We will use a multi feature gate ladder up to 0.5 multiplier (likely 0.1, 0.25, 0.5). We will be conservative in ramping up multiplier so we can give people a chance to experience increased fees and optimize programs before their costs shoot up immediately. We also don't want to drastically increase cost for cheap operations like oracle updates

Part of the appeal of this approach is:

1. Not drag cost model updates into this SIMD, which would blow it up substantially

2. Not drastically overhaul market structure and builder incentives

Then in future SIMD(s), we get the cost model more accurate so that the resource costs align more closely to what they're costing the cluster.

I'm fine with 2.5k, 3k, 5k, or whatever as the base fee. I lean towards something like 4k lamports because it ends up fairly close to the 5k lamport min fee of today for most cheap operations and increasing operational cost of, e.g. oracle updates, feels like a silly side effect of what we're trying to do here and not the place to stall out for getting this across the line.

So under this model the only thing that gets burned is the new resource fee?

What is the estimated burn if it gets implemented with the suggested multipliers?

https://burn.cavey.xyz