Adjusting Gas Price During High Network Activity

Sometimes during periods of high network activity, transactions either remain pending for a very long duration or instantly get a failed transaction notification. This may confuse and frustrate users, especially if they don't understand why their transactions are not getting accepted.

Probable Reasons You Are Here

Your transaction has stalled, and you don't know what to do
Your transaction has failed, with an error - transaction underpriced
It's your first transaction, and you want to be sure about any potential issues
Just for general knowledge on adjusting dynamic fee settings

If these are your reasons for being here, then you can either go through this entire section, for a better understanding of the scenario or directly skip to the solution.

Good to Know Keywords and Concepts

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 into 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 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).

Gas tip cap is the 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) -

Transaction	Max Fee Cap	Gas tip cap	Base price	Effective tip	Total price
1	50 Gwei	0 Gwei	25 Gwei	0 Gwei	25 Gwei
2	50 Gwei	0 Gwei	50 Gwei	0 Gwei	50 Gwei
3	50 Gwei	0 Gwei	60 Gwei	0 Gwei	PENDING
A	50 Gwei	10 Gwei	40 Gwei	10 Gwei	50 Gwei
B	40 Gwei	40 Gwei	40 Gwei	0 Gwei	40 Gwei

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.

Why My Transaction is on Hold or Failing?

If your transaction is failing and giving an error - transaction underpriced, then the max fee cap of your transaction must be less than the minimum base price that the network supports (as of now, it's 25 nAVAX or Gwei). Although the base fee is automatically estimated in wallets like Core or MetaMask, you can try increasing the max fee cap in the wallet.

During a period of heavy congestion on the network, all submitted transactions can't be included in the same block, due to the block's gas limit. So, validators choose transactions giving higher priority to transactions with the highest effective tips.

Another reason your transaction may get stuck in pending, is that the max fee cap may be below the current base fee that the network is charging. In this case, you need to increase the max fee cap of your transaction above the current base fee for it to be included in the block.

These fee adjustments can be made through wallets like Core or MetaMask.

Adjusting Gas Fees Before Submitting the Transaction

You may not need to edit the gas fees on normal days. This is only required if there is heavy congestion on the network, and the base fees are frequently fluctuating.

Let's create a sample transaction on Avalanche Mainnet, in which we will be sending 0.1 AVAX to a receiver using Core. Four predefined gas settings can be seen, which are Core's inbuilt gas estimation. To set a custom fee select “Custom” and enter the gas amount to use. By clicking on the Settings icon, we can review gas fees and the amount which we want to send.
On this page, you can edit the priority fee (Max Priority Fee) and base fee (Max base fee). You can estimate the max fee as shown on Snowtrace, which represents the average max fee over the last 3 seconds. For more detailed statistics, you can have a look here.
If the network activity is high, you have to edit the priority and max fees accordingly, as given on Snowtrace. Consider the example below, where the average max fee is 26 Gwei (nAVAX).
It is recommended to set the max fee cap as the maximum price that you are willing to pay for a transaction, no matter how high or low the base fee will be, as you will only be charged the minimum of base fee and the max fee cap, along with a small priority fee above the base fee. Now let's edit the max fee to 35 Gwei. This would ensure that our transaction would not fail until the base fee would exceed this amount. We can set a priority fee to anything between 0 and 35 Gwei. The higher the priority fee, the faster the transaction will be. For this example, let's set this to 2 Gwei. Now, save and send the transaction.
After submitting the transaction, even if the base fee has decreased, you will only pay 2 Gwei above that fee as a priority fee. If this fee is one of the highest among the pending transactions, then it will be confirmed rapidly. We can see the confirmation of the transaction below.