How are gas fees calculated? | Avalanche Support (2024)

The amount of computation used by a transaction is measured in units of gas. Each unit of gas is paid for in AVAX at the gas price for the transaction. The gas price of the transaction is determined by the parameters of the transaction and the base fee of the block that it is included in.

To avoid draining the user's wallet due to non-terminating execution through the EVM, transactions are submitted with a gas limit, which denotes the maximum units of gas that a particular transaction is allowed to consume.

If a transaction attempts to use more than this limit, then the transaction will revert and still consume and pay for the full gas limit. Total fees paid by the user can be calculated as (gas consumed) * (gas price), and is known as gas fees. Similarly, maximum gas fees can be calculated as (gas limit) * (gas price).

Originally, transactions could only set a single parameter to define how much they were willing to pay for gas: gas price. When dynamic fees were introduced, EIP-1559 style transactions were introduced as well which contain two parameters maxFeeCap and maxPriorityFee to determine the price a transaction is willing to pay.

With the introduction of dynamic fees, legacy-style transactions that only have a single gas price parameter can lead to both delayed transactions and overpaying for transactions. Dynamic fee transactions are the solution! For more info, read this.

For the dynamic fee algorithm, when a block is produced or verified, we look over the past 10s to see how much gas has been consumed within that window (with an added charge for each block produced in that window) to determine the current network utilization. This window has a target utilization, which is currently set to 15M gas units.

Lastly, there is an added charge if a block is produced faster than the target rate of block production. Currently, the target rate of block production is one block every two seconds, so if a new block is produced one second after its parent, then there is an additional surcharge added to the base fee calculation.

Base price could increase, decrease, or remain the same depending upon the amount of activity on the network in the most recent window. If the total gas in the last few blocks of the window is more, less, or the same than the target gas, then the base price will increase, decrease, or remain the same, respectively.

When estimating the base fee for users, we simply look at the currently preferred block and calculate what the base fee would be for a block built on top of that block immediately.

Along with a gas limit, users can now pass 2 values in dynamic fee transactions - gas fee cap and gas tip cap.

The maximum price per unit of gas, that the user is willing to pay for their transaction is called the gas fee cap. If the base price for a block is more than the gas fee cap, then the transaction will remain in the transaction pool until the base fee has been changed to be less than or equal to the provided gas fee cap (note: the transaction pool limits the number of pending transactions, so if the number of pending transactions exceeds the configured cap then the transactions with the lowest fees may be evicted from the transaction pool and need to be re-issued).

A gas tip cap is a maximum price per unit of gas, that the user is willing to pay above the base price to prioritize their transaction. But the tip is capped by both the gas tip cap as well as the gas fee cap. The actual tip paid above the base fee of the block is known as the effective gas tip.

EffectiveTip = min(MaxFeeCap - BaseFee, GasTipCap)

Consider the following examples (here GWEI or nAVAX is one-billionth of AVAX) -

Look at transactions A and B (the bottom two transactions). In these scenarios, it looks like transaction B is paying a higher tip, however, this depends on the base fee of the block where the transactions are included. The effective tip of A is more than that of B. So, if both of these transaction competes for being included in the next block, then the validators would prioritize transaction A since it pays a higher effective tip.

For any additional questions, please view our other knowledge base articles or contact a support team member via the chat button. Examples are for illustrative purposes only.