FLIP 336: Dynamic Transaction Fees

[vishalchangrani]

Issue for the FLIP: #336

Comment Period: 2 weeks (July 28th to Aug 4th)

[bluesign]

I support, but I would love to see some adjustment and then discount/surge depending on the load.

This seems to have very negative associations ( surge pricing ) like flow fees can increase 100x etc.

But instead we can maybe do 10x down, 10x up etc.

As you mention in the FLIP, fees are unreasonably low for adoption ( marketing etc ) maybe better to show that it is discounted like 100x.

[vishalchangrani]

I support, but I would love to see some adjustment and then discount/surge depending on the load.

This seems to have very negative associations ( surge pricing ) like flow fees can increase 100x etc.

But instead we can maybe do 10x down, 10x up etc.

As you mention in the FLIP, fees are unreasonably low for adoption ( marketing etc ) maybe better to show that it is discounted like 100x.

Thanks (as always) for taking the review the FLIP @bluesign.

Do you mean that there should be a 10x down surge when network usage is slower than anticipated? TBH, that was part of the first draft but then I removed it as the tx price is already so low.

OR did you mean that we first do a 100x to establish a new baseline and then do a 10x+ or 10x- based on that?

Raising the base fees is something I feel should be tackled as a broader tokenomics discussion as it should address other concerns around inflation. This FLIP is intended to make sure the network can gracefully handle overcapacity.

[btspoony]

Love it!

[bluesign]

did you mean that we first do a 100x to establish a new baseline and then do a 10x+ or 10x- based on that?

Yeah exactly, fees are now super cheap. Instead of saying "in surge you can pay 100x" it is much better to say: "in surge you can pay 10x, but also when network is calm, you can pay cheaper fees"

[janezpodhostnik]

Execution effort focuses explicitly on execution time and is proportional to it. It covers only one of our available resources.

If the network is at execution capacity (the execution nodes are not executing fast enough) this is absolutely correct. However, execution is not always our bottleneck. With a high enough TPS of extremely simple transactions we would see problems else-where. This is what the inclusion effort is supposed to focus on.

In the future we could see the surge factor of a transaction also be a function of the Inclusion Effort and Execution Effort:

• If execution is struggling to keep up, but collection/consensus/network/... is doing fine we could have the surge factor be higher for transaction with a lot of execution effort and lower for low execution effort transactions
• If execution is not busy at all, but collection/consensus/network/... are struggling, we could change the surge factor so that is is cheaper to send 1 transaction with many operations instead of one transaction for each operation

While its ok to take only Execution Effort as the estimate now (since we do not have a good definition for inclusion effort), we should definitely mention that inclusion effort is part of this too and covers other resources besides execution.

[vishalchangrani]

Thanks for the comment @janezpodhostnik.

1. The FLIP proposes the usage of CU /second as a proxy for load. If the TPS is high but the transactions are extremely simple, wouldn't the CU/second still go well above the average?
2. Will edit the FLIP to include something along the lines that surge will be applied to both inclusion effort and execution effort as the formula for tx fees = surge (inclusion effort + execution effort)

[janezpodhostnik]

Nice!

1. the graph governance/20250727-dynamic-surge-pricing/phase.png should not loop back on itself.

I think we should limit the ΔS to a reasonable number. (ΔS change in surge pricing)

Lets say that I as a user send a tx and at the time of sending I could see that the surge factor is 1 so I expect to pay the normal fees. However, there could be a system transaction changing the surge factor already in flight and will change the surge factor before my transaction is executed. This means I will have to pay more than I expected. I will need to pay ΔS times more.

While users should account for the surge factor changing somewhat, I think its unreasonable to expect that users account for a huge ΔS. Maybe we say that in our typical times to seal ΔS will not be more than 10, or something like that.

Another (far more complex) solution would be to charge transactions with the surge factor as it was at the transaction reference block.

[bluesign]

@janezpodhostnik this is very good point. I think one option is setting surge pricing smoothing.

Like we set surge pricing at some regular block interval ( maybe 600 blocks ) and it changes maximum x percent ( ex: 10 percent) up and down.

This is especially important if you are running transactions on behalf of others ( like evm gateway )

[vishalchangrani]

Nice!

1. the graph governance/20250727-dynamic-surge-pricing/phase.png should not loop back on itself.

I think we should limit the ΔS to a reasonable number. (ΔS change in surge pricing)

Lets say that I as a user send a tx and at the time of sending I could see that the surge factor is 1 so I expect to pay the normal fees. However, there could be a system transaction changing the surge factor already in flight and will change the surge factor before my transaction is executed. This means I will have to pay more than I expected. I will need to pay ΔS times more.

While users should account for the surge factor changing somewhat, I think its unreasonable to expect that users account for a huge ΔS. Maybe we say that in our typical times to seal ΔS will not be more than 10, or something like that.

Another (far more complex) solution would be to charge transactions with the surge factor as it was at the transaction reference block.

1. Corrected the diagram. I want to show in the diagram that till <= 70% surge is constant but after 70% it increases exponentially. The exponential curve wasn't drawn accurately - I took another stab at it.
2. Great point about the ΔS. So if you look at the table, you will notice that the change is surge between 100 and 101 is very little (121 to 142, 17% increase) but the change in surge between 100 and 110 is huge (almost 6x). The exponential nature of the curve ensures that smaller change in TPS doesn't result in large change of surge but larger change in TPS does.

As part of the short-term implementation, the plan is to only adjust surge if there is a sustained load instead of revising the surge very frequently (see here). We should never have to adjust surge more than once in Time to seal window of 12 seconds.

[vishalchangrani]

@janezpodhostnik this is very good point. I think one option is setting surge pricing smoothing.

Like we set surge pricing at some regular block interval ( maybe 600 blocks ) and it changes maximum x percent ( ex: 10 percent) up and down.

This is especially important if you are running transactions on behalf of others ( like evm gateway )

The short term implementation would be far more rudimentary where we only adjust surge if there is a sustained load for ~1 hour. I added more explanation here. Let me know if that makes sense.

[bjartek]

How does this affect the events emitted at the end of every tx?

Is gas/computation affected by this or only the amount of flow you pay for each gas/computation.

[bjartek]

I also agree with @bluesign that a model where there can also be negative surge to be good. But then general fee have to go up.

[bjartek]

Do we need to look into previous traffik to do some simulations or is it enough to be abstract here.

Like will a period where live nation create accounts be enough for a surge. Because those tx are imho pretty expensive since they create new accounts.

[vishalchangrani]

How does this affect the events emitted at the end of every tx?

Is gas/computation affected by this or only the amount of flow you pay for each gas/computation.

1. Events emitted at the end of the tx shouldn't change.
2. This will only affect the amount of flow you pay in total and not affect the gas/computation.
   Transaction Fee = (Inclusion Fee + Execution Fee) × Surge Factor. Surge will be applied after the Fees have been calculated.

[vishalchangrani]

Do we need to look into previous traffik to do some simulations or is it enough to be abstract here.

Like will a period where live nation create accounts be enough for a surge. Because those tx are imho pretty expensive since they create new accounts.

Great question @bjartek.

1. I am intentionally keeping this a bit abstract since network capacity is continuously improving with recent and upcoming performance upgrades. In particular, features like parallel transaction execution are expected to significantly increase throughput.

2. We are currently running benchmarking tests to better measure real-world network capacity. Those results should give us a more accurate baseline and are expected to conclude in a few weeks.

3. Looking at historical data, the peak observed was around 13M transactions in a week (~22 TPS). This is still well below the network utilization threshold where surge pricing would kick in.

[vishalchangrani]

hi folks,

@bluesign , @bjartek - As mentioned earlier, raising the base fees should be addressed as part of a broader tokenomics discussion, where we can look holistically at inflation and other related considerations. This FLIP is focused on ensuring the network can gracefully handle overcapacity, and is not intended to adjust base fees.

Since there have been no further comments, I would like to mark this FLIP as Accepted unless someone has any objection or comments.

The next step will be to run a test on testnet where we raise the surge price to validate that the mechanism works as expected. This will also help identify any upstream or downstream dependencies such as wallets, dapps, or other integrations that might be affected by surge pricing changes.

[vishalchangrani]

hi folks,

@bluesign , @bjartek - As mentioned earlier, raising the base fees should be addressed as part of a broader tokenomics discussion, where we can look holistically at inflation and other related considerations. This FLIP is focused on ensuring the network can gracefully handle overcapacity, and is not intended to adjust base fees.

Since there have been no further comments, I would like to mark this FLIP as Accepted unless someone has any objection or comments.

The next step will be to run a test on testnet where we raise the surge price to validate that the mechanism works as expected. This will also help identify any upstream or downstream dependencies such as wallets, dapps, or other integrations that might be affected by surge pricing changes.

@janezpodhostnik - ok to mark this FLIP as accepted?

[vishalchangrani]

Marked the FLIP as Accepted.