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 -
- 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
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
maxPriorityFee to determine the price a
transaction is willing to pay.
With the introduction of dynamic fees, legacy style transactions that only have
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
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 capand
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
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) -
|Max Fee Cap
|Gas tip cap
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 -
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.
Was this page helpful?