Proposing Transaction fee changes and Flow EVM gas charges for Flow Crescendo launch

[kshitij.chaudhary]

This is only a blog, not a FLIP. The objective of this post is to brainstorm ideas and collect initial feedback from the community before we present a formal FLIP.

This post covers three changes to Flow computation charges and limits to reflect changes to Flow (most notably, the addition of EVM operations) and to improve the resiliency of Flow to denial-of-service attacks.

1. We propose a mechanism to convert EVM gas costs into Flow computation costs so that EVM transactions and operations can be added into the standard Flow transaction fee calculations.
2. We propose an increase in the computation limit for Flow transactions to reflect the performance improvements made to Cadence and the overall protocol, in order to allow each transaction to do more (when warranted).
3. We propose an increase in the per-unit computation cost, to reflect the reality that the current cost of computation on Flow is many orders of magnitude below other chains, which opens the protocol up to a potential denial-of-service attack from a malicious entity sending cheap “junk transactions” to clog up the network.

Recap: Transaction fees for EVM transactions on Flow

See this post for a description of how transaction fee of EVM transactions would be calculated once EVM is live on Flow Mainnet. Remember, with the addition of a new weight EVMGasUsage, we would amend the calculation of execution effort on Flow Cadence in the following way-

Execution Effort =
    0.0239 * function_or_loop_call +
    0.0123 * GetValue +
    0.0117 * SetValue +
		43.2994 * CreateAccount +
	  **EVMGasUsageCost * EVMGasUsage**

While EVMGasUsage is supplied by EVM (for instance 21K gas for a simple send transaction), EVMGasUsageCost is the ratio of converting EVM gas to Flow’s computation units, which may also be called “Gas-to-Compute ratio” (or “G2C ratio”). Note that in this previous post, a 1000:1 G2C ratio was mentioned as an example; this post explains why choosing a different ratio (5000:1) would be more effective.

Goal 1: Enabling Execution of the large EVM contracts and transactions on Flow

EVM launch on Flow presents an opportunity to better align with network objectives and user needs in terms of total computation required. The current execution effort (”compute”) limit of 9999 on Flow Cadence may be inadequate for larger EVM transactions. Flow should be able to match or surpass the capabilities of Ethereum, allowing transactions of up to 30M gas to be executed seamlessly.

To attain this objective, two approaches can be employed: (1) Implementing a gas-to-compute conversion ratio (EVMGasUsageCost) to ensure that larger contracts (30M gas) fit within the 9999 compute limit, and (2) raising the computation limit on Flow to accommodate larger transactions requiring higher compute. The most effective strategy would involve a combination of both methods.

1. Gas to compute conversion ratio (EVMGasUsageCost)

Empirical data shows that G2C with the current computation limit of 9999 (or in other words, the current weights) should not be lower than 1000:1, otherwise we risk ETH transactions using up more computation time, than they pay for. Considering however that EVM transactions also consume compute units in cadence execution, the actual size of EVM transactions/ contracts that can be executed with the ratio of 1000:1 would be much less than 10M. To match Ethereum’s 30M gas limit, a 5000:1 gas to compute ratio could be adopted to calculate execution effort (compute units) on Flow. This ratio would allow for 30M gas, along with adequate compute allocation for cadence execution based on our test transactions. For instance, a 30M gas transaction with a 5000:1 conversion ratio may consume about 6000 compute units for EVM execution, leaving 3999 compute units for Cadence execution.

It’s important to note that for such sizable contracts however, even these compute units (3999 in the above example) may prove insufficient for cadence execution. Therefore, we should also consider revising Flow’s computation limit of 9999 to ensure seamless execution of the largest Ethereum contracts.

2. Computation Limit

Directly raising the computation limit entails substantial code modifications and collaboration with ecosystem developers. Alternatively, we can indirectly increase the limit by lowering the execution effort coefficients or weights (0.0239, 0.0123, 0.0117, and 43.2994 in the execution effort calculation). Decreasing these weights would effectively expand a transaction’s computation limit; in other words, more and larger operations would “fit within” the 9999 compute limit.

To determine the appropriate reduction factor for the weights, a thorough understanding of Flow’s execution capabilities in handling large transactions was necessary. This involved assessing how much “computation” could currently be accommodated in a block (on Mainnet24) and how much additional time a transaction could consume before encountering complications. For instance, if transactions in a block exceed the available block time (1.25s), they might need to be split across multiple blocks—a feature not currently supported; also, single transactions can never be split further. After evaluating these factors, it became apparent that increasing the transaction time by more than 5 times may lead to execution issues. Therefore, it is proposed to reduce the computation weights by a factor of 5.

Goal 2: Increasing Transaction Fees to drive greater utility and minimizing risk of network attack

Transaction fees on Flow are low, posing risks of attack, necessitating continuous token issuance (inflation), and making FLOW utility seem peripheral vis-a-vis other networks. The FLIP to introduce 100x transaction fee was upvoted by most community members but has been pending for a while. Crescendo launch is a chance to take it through the final approval and implement it.

While this increase might seem large by itself, the cost of Flow transactions to date have been several orders of magnitude below the costs seen on alternative computation networks. With the proposed new fee structure, we estimate that Flow will be approximately ~16,000x less expensive than Ethereum and ~10x less expensive than popular L2s such as Optimism and Base (for typical transactions).

The Proposal

Combining the proposed adjustments outlined above, the following changes are suggested:

1. Establishing the “Gas to compute ratio” at 5000:1 or setting EVMGasUsageCost to 1/5000.
2. Reducing the coefficients of execution effort by a factor of 5x, effectively increasing the computation limit by the same factor. This reduction in coefficients will be counterbalanced by an increase in the cost of execution unit on Flow. See this post to review the calculation method for transaction fees and to understand how a corresponding increase in the cost of execution units would negate any influence on the total transaction fee.
3. Elevating the cost of execution units by 500x compared to the current rate, resulting in a value of ~2.5 x 10E-5. This overall increase results from combining a 5x increase to compensate for the reduction in coefficients (see the previous point) with the 100x increase proposed by FLIP-74 (see Goal 2, above).
4. Increasing inclusion unit cost by 100x, to 1E-4 for all transactions, also intended to correspond with the 100x increase in transaction fee across the board.

Execution effort or compute calculation would then become -

Execution Effort = 
    0.00478 * function_or_loop_call +
    0.00246 * GetValue +
    0.00234 * SetValue +
		8.65988 * CreateAccount + 
		1/5000 * EVMGasUsage

Summary

Since Transaction fee = [inclusion fee + (execution effort units * execution effort unit cost)] x surge , after these proposed changes -

• Inclusion Fee = 1E-4 (constant)
• Execution effort units will be calculated as -

Execution effort units (or computation units) = 
    0.00478 * function_or_loop_call +
    0.00246 * GetValue +
    0.00234 * SetValue +
		8.65988 * CreateAccount + 
		1/5000 * EVMGasUsage

• Execution effort unit cost = ~2.5 x 10E-5 (constant)
• Surge = 1 (constant and no change)

Next Steps

Following community discussion on this forum post, the next phase will involve the presentation of a formal FLIP (Flow Improvement Proposal), which will be shared with the community. Community members will receive updates and ample time to respond to these proposed changes, allowing for planning and preparation. Subsequently, the changes will undergo testing on the testnet before deployment on Mainnet, timed around the Crescendo mainnet launch.

Final Word

Overall, the proposed/implemented changes aim to simultaneously enhance the computation limit and increase transaction costs by 100x (thereby bolstering resilience against attacks by the same factor). For developers, the indirect increase in the compute limit eliminates any extra effort required to update their contracts for changes in the computation limit. Additionally, the 5000:1 gas-to-compute ratio would empower them to execute larger contracts on EVM on Flow. Although transaction fees would incur a slightly higher cost for parties responsible for transactions (developers, wallets, etc.), this adjustment brings the advantages of enhanced network security, increased utility, and lays the groundwork for potential reduction in token inflation in the future.

[flowjosh]

I’m not familiar enough with the specifics of tokenomics and costs to know if these exact numbers are the perfect choices, but I definitely support increasing the computation limit and increasing the cost of transactions because they are both too low right now. Thanks for writing and proposing this!

[bt.wood]

I have a shallow thought:

Regarding the previous discussion on x100 Fee, there has actually never been a real vote with $FLOW Token/Staked $FLOW Token holding weight. It was only a conclusion reached within our Working Group of less than 20 people.

Due to the fact that gas computation on EVM on Flow is brand new, and everyone has already been accustomed to low gas in Cadence before, even the amount of Storage Cost is familiar to everyone. And now, upgrade with EVM onFlow is an inevitable move.

Perhaps we can try the following modification while maintaining the x100 Gas Fee target:

Extra option 1:

• For Transaction without EVM operation = Keep gas fee unchanged
• For Transaction with EVM operation = Cadence standard compution + EVM compution = The total gas cost is about x100 gas fee when doing similar job without EVM operation.

Extra option 2:

• For Transaction without EVM operation = x10 compution Gas Fee
• For Transaction with EVM operation = x10 Cadence standard compution fee cost + EVM compution = The total gas cost is about x100 gas fee when doing similar job without EVM operation.

This can also make pure Cadence development more attractive, allowing more people to try pure Cadence development instead of just migrating an EVM project.
At the same time, we have also achieved our previous goal of x100 Gas Fee (on EVM transactions, because we believe this will attract more people.).

[kshitij.chaudhary]

Hey @bt.wood - appreciate your insights. Here are my thoughts:

1. Currently, Flow transaction fees are notably lower compared to other networks. Even with a 100x increase across the board, we’d remain highly competitive. For example, transactions on Flow (both pure cadence and EVM) would be ~10x cheaper than similar networks like Solana, BASE, Optimism, and Polygon, ~500x cheaper than Avalance and Cardano; and ~16,000x cheaper than Ethereum, even after the 100x increase suggested in the post.

2. The formula shared in the post for post-EVM execution effort calculation would result in a positive non-zero value for EVMGasUsageCost * EVMGasUsage (e.g., 1/5000 * 65,000 = 13 units for a transfer transaction requiring 65K gas on Ethereum). This would result in higher execution effort and thus higher fees for transactions with EVM operations compared to pure Flow Cadence transactions. As a result IMO, Cadence development would continue to be more attractive, encouraging developers to explore pure Cadence development if required instead of solely migrating EVM projects. Estimates from test transactions suggest that Cadence transactions will cost approximately 60% compared to fees for EVM transaction (rough numbers - tbc confirmed with more data).

[bt.wood]

Hey @kshitij.chaudhary

I don’t think you understand my core intention.

What I mean is not to oppose the goal of 100x, but to maintain the goal of 100x in form only, limited to transactions involving EVM execution.

When comparing with other chains, we compare based on algorithms that include EVM transactions, which still have a similar effect as 100x. (Because the main increase in transaction fees comes from EVM calculations).

But for pure Cadence computations, the impact of increased Gas will be very small.

Compared to your previous overall adjustments, this makes Cadence’s computational advantage 10-100 times greater than the previous design.

However, when comparing with external and other public chains, we still use the value that includes EVM calculations, which means Gas Fee is equivalent to 100x of the original (in form of same behavior).

[bt.wood]

For example:

Before modification: Transferring FT costs 0.00003 $FLOW.

After modification:

1. Transfering Flow native FT costs 0.0003 $FLOW as gas fee.
2. Executing transfers ERC20 on EVM requires 0.003 $FLOW as gas fee.

In form, we have achieved making Transfer FT on Flow 100x. gas fee.

[kshitij.chaudhary]

@bt.wood

• Transfering Flow native FT costs 0.0003 $FLOW as gas fee.
• Executing transfers ERC20 on EVM requires 0.003 $FLOW as gas fee.

Hi @bt.wood - thanks for sharing this example to help me understand your thoughts. What I’m proposing is that assuming Transferring FT costs 0.00003 $FLOW on cadence today, we increase this to 0.003 $FLOW (100x) for Cadence-only transactions (not 0.0003 $FLOW like you shared in point#1), while for EVM transactions, due to the additional gas factor, this might cost slightly more (say 0.004 $FLOW). (If we do not action this proposal, EVM transactions, in my stated example, would cost 0.00004 $FLOW).

I think the difference here is that you think Cadence transactions should only go up by 10x, while EVM transactions can go up by 100x - is that right? If it is, I think I am not in favor of keeping such a stark difference between the two and taxing developers heavily for deploying EVM transactions on Flow compared on Cadence ones.

Please correct me if I have still misunderstood your point

[kshitij.chaudhary]

@bt.wood

Regarding the previous discussion on x100 Fee, there has actually never been a real vote with $FLOW Token/Staked $FLOW Token holding weight. It was only a conclusion reached within our Working Group of less than 20 people.

Also while I think we are on the same page, still want to highlight that the proposal that we put out last year for transaction fee increase (FLIP) - no final decision was made, and thus no implementation was done. The fees is still the same as it was and no values (execution cost or inclusion costs) have changed. So this current proposal is exactly the same as last year’s proposal but I’m simply suggesting that we time this with other critical changes (computation limit hike and the Crescendo launch, etc.)

[bt.wood]

Here is my thought:

1. EVM never existed before, there is no 100x for it, it should be new to everyone. Only measure of EVM fee is other public chains.
2. After the upgrade our overall cost is still like you said “transactions on Flow (both pure cadence and EVM) would be ~10x cheaper than similar networks like Solana, BASE, Optimism, and Polygon, ~500x cheaper than Avalance and Cardano; and ~16,000x cheaper than Ethereum”, so it still attracts EVM developers.

[bt.wood]

Yeah, we are on the same page for these.

[bt.wood]

I use formulas to express it, which may make it easier to explain.

According to FLIP-74

1. Inclusion fee is maintained as a constant, but increased 100x, from 1E-6 FLOW to 1E-4 FLOW for all transaction types
2. Unit Cost of Execution Effort is increased 100x, from 4.99E-8 FLOW to 4.99E-06 FLOW

My new proposal is

1. Separate EffectUnits into CadenceEffectUnits + EVMEffectUnits

EffectUnits(or ComputationUnits) =
  CadenceEffectUnits +
  EVMEffectUnits

CadenceEffectUnits = 
  0.00478 * function_or_loop_call +
  0.00246 * GetValue +
  0.00234 * SetValue +
  8.65988 * CreateAccount

EVMEffectUnits = 
  1/5000 * EVMGasUsage

2. Changing the formula and constant of Transation fee:

• From TransactionFee = [InclusionFee + (EffectUnits * ExecutionEffectUnitsCost)] x Surge
  • InclusionFee = 1E-6 $FLOW (constant)
  • ExecutionEffectUnitsCost = 4.99E-8 $FLOW (constant)
  • Surge = 1(constant and no change)
• To TransactionFee = [InclusionFee + (CadenceEffectUnits * ExecutionEffectUnitsCost + EVMEffectUnits * EVMExecutionEffectUnitsCost)] x Surge
  • InclusionFee = 1E-4 $FLOW (constant)
  • ExecutionEffectUnitsCost = 4.99E-7 $FLOW (constant) (BTW, 2.5x10e-5 is 500x)
  • EVMExecutionEffectUnitsCost = 4.99E-6 $FLOW (constant)
  • Surge = 1(constant and no change)

There are three benefits to doing this:

1. Reduce the impact of increased fee costs for ecosystem partners
2. Increase the advantage for using Pure Cadence
3. Keep the narrative of increasing 100x gas fee for Marketing, At the same time, it still ensures “transactions on Flow (both pure cadence and EVM) would be ~10x cheaper than similar networks like Solana, BASE, Optimism, and Polygon, ~500x cheaper than Avalance and Cardano; and ~16,000x cheaper than Ethereum”. And we still can attract EVM developers, because all of this is new, we are just comparing with other public chains from the gas fee perspective.

[kshitij.chaudhary]

Thanks, @bt.wood, for taking the time to thoroughly explain your perspective! I appreciate it. Your proposal offers a slightly different approach from mine, and I’m eager to hear from other community members, especially developers, to get their thoughts on it.

[bluesign]

@bt.wood

This can also make pure Cadence development more attractive, allowing more people to try pure Cadence development instead of just migrating an EVM project.

I think the direction we are going here is, there is no pure Cadence vs EVM discussion anymore. We have a hybrid model. People can use Flow without Flow Account via EVM. So basically EVM gas pricing should be proportional to resource usage of the network. ( EVM is first class citizen not alternative to Cadence )

Even 100x change is still very vey cheap ( actually I think it should be on 1000x level, currently executing transactions are costing 40000x approximately )

[bt.wood]

First of all, I am not belittling EVM and still consider it as a first-class citizen.

My points are:

1. Previously, there was no EVM, so we didn’t need to make any assumptions about EVM because we are discussing the initial situation now.

2. The transaction fees in the EVM environment do not need to be compared with those in the Cadence environment. We only need to compare them with other EVM-compatible public chains. If we use 100x UnitCost for EVM calculations, it is still much cheaper than other public chains, which makes it attractive enough.
   Note that what I emphasize here is not comparing with Cadence but comparing with other public chains.

3. Since after introducing the EVM environment, if Cadence calculations have relatively lower UnitCosts, wouldn’t it be easier to attract Solidity developers who are introduced to Flow because of EVM to try out Cadence development?
   This would be beneficial for the overall development of the Cadence language.

Again, this is not belittling the EVM environment but rather looking at it from the perspective of promoting Cadence and hoping to gain more favorable opportunities for Cadence.

[bluesign]

I agree with pricing EVM and Cadence can be different, but my point is we have to look from network side; I meant, totally hypothetical but if doing something on EVM is consuming less resource, but it is taking more resources in Cadence, we cannot favor Cadence there.

Ofc I agree with all points and support here. if EVM is cheaper and competitive to other networks, while Cadence is more optimized vs EVM and cheaper than EVM, it would be the best scenario. But setting this artificially would be not good. ( Btw my feeling here is Cadence should be more expensive vs EVM )

We can start with 100x increase on fees on Cadence side, and set EVM pricing based on resource usage ratio, and then confirm EVM is still competitive with other EVM chains.

[kshitij.chaudhary]

@bluesign

Ofc I agree with all points and support here. if EVM is cheaper and competitive to other networks, while Cadence is more optimized vs EVM and cheaper than EVM, it would be the best scenario.

Yeah, and like i said, with the changes proposed above, some test transactions that we ran showed that EVM transactions on Flow would be ~10x cheaper than similar networks like Solana, BASE, Optimism, and Polygon; while Cadence transactions would be about 40% cheaper than EVM transactions.

[kshitij.chaudhary]

UPDATE

As outlined in this blog post and also FLIP 74, the proposal was to amplify the unit cost of execution effort and unit cost of inclusion by 100 times, thereby elevating the transaction fee by 100 times across all transaction types. However, to isolate the current transaction fee change now and for the future, we propose a new transaction multiplier (’T’). It will be initially set to 100. This is different from the surge multiple whose purpose is to adjust fees in case the network experiences a surge in transactions. The transaction multiplier help separation of concerns.

Presently, the Flow network allows for dynamic adjustment of transaction fees based on network congestion. The surge factor (‘S’), currently fixed at 1.0, facilitates fee adjustments during periods of network congestion, ensuring optimal performance. Introducing a Transaction Fee Multiplier (‘T’) alongside the existing surge factor would help adapt transaction fees to FLOW’s exchange rate fluctuations. The purpose of this is to prevent developers and partners from either overpaying or underpaying for transactions (in fiat terms).

Initially T will be set at 100 to increase the transaction fee by 100 times compared to now. T will be subject to adjustments based on rules surrounding demand and supply of FLOW; these rules are still under research and will be included in the formal FLIP that introduces these changes to the community. Initially, the service account committee, consisting of key community members, will manually assess and adjust the value of ‘T’ periodically to ensure responsive fee adaptations based on market changes. However, the long-term objective is to automate the setting of ‘T’ without human intervention. This automated process will involve algorithmic determination of ‘T’, ensuring that it reacts to market forces. Further, to address concerns about extreme values, the community can establish minimum and maximum ranges for ‘T’ ensuring stability and reasonable adjustments.

Note that this new approach not only provides greater flexibility and responsiveness to economic realities but also ensures transparency and ease of understanding for our community members. Let us know what you think!

[bluesign]

I am not sure if thinking transaction fees in fiat terms are a good idea. ( I am commented very cautiously here, unless there is something big I am missing, now my instinct is more closer to ridiculous to be honest )

• First of all it is against the idea of reducing inflation
• Second it is no different than setting unit price. ( now if we are charging unit computation X, changing to 100*X or changing to T * X ( where T=100 ) exactly same thing
• I think also this has negative effect on Flow price, if we decrease tx fees when flow price increases, it will increase inflation ( that will decrease flow price )

I am curious what would be the use case of Flow if tx fee ( my cost as a Dapp ) will be in fiat. If we don’t scale to fiat price, we can say Dapp to stake some flow to cover tx fees for example, so they can hedge their cost in a predictable way, which helps system and flow price by locking flow. But when it is promised to be fiat correlated, there is no motivation to keep flow anymore.

[vishal]

The reason to have the Transaction fee multiplier (T) is to provide some guardrails in the case when the token price goes too high or too low. If the token price goes too high, then the end users will not be willing to pay the resulting high transaction fees and the dApps will essentially lose revenue. On the flip side, if the token price goes too low, we will end up in the same situation as today - low transaction fees and more inflation. T doesn’t necessarily tie tx fees to FIAT but provides some protection against these extreme cases. The rules to set T can be based on long periods of time to account for volatility and be very broad stroked to not attempt to adjust T frequently.

The reason to have T separated from unit computation is essentially to separate concerns. It’s just easier to explain Transaction fee multiplier versus unit computation e.g. “Transaction fee multiplier is now 100” intuitively tells the reader that the transaction fees went up by 100 instead of saying “the computation unit is now 100”. The formula also becomes easy to read IMO.

Asking dApps to stake may or may not fly well with all dApps. Staking will require some effort from their end and distract them from what they would like to focus on - building and running the dApp.
Also, I don’t think T is intended to make tx fee Fiat correlated but like I mentioned provide some protection against ridiculously high tx fees.

[bluesign]

@vishal

If the token price goes too high, then the end users will not be willing to pay the resulting high transaction fees and the dApps will essentially lose revenue.

I think we should focus on revenue from dapp or from wallet side ( they are paying the transaction ) I don’t think it makes sense to assume user will pay the transaction fees in the long run.

in that sense it is good to get rid of ( forcing them to optimise ) dapps that are spamming network or using high resources.

Also I think it would be best for dapps to utilize Flow token for sales, then transaction fees would be just percentage of the sale price for example.

I don’t know if any chain makes transaction fees relative to Fiat ( even for big changes in the price ) but if also we also put rewards to relative to this T I don’t see any big problem

I don’t think T is intended to make tx fee Fiat correlated but like I mentioned provide some protection against ridiculously high tx fees.

I think this is a good intention, I think Flow Foundation (alternatively) can give some guarantees to dapps/wallets for example by staking some Flow and covering their some part of transaction fees etc.