Adjusting Gas Prices during high network activity
Introduction#
This tutorial is designed to help users adjust the priority fee and max fee cap for a transaction during periods of high network activity. Follow this tutorial to take full advantage of the benefits of dynamic fee transactions.
Occassionally during periods of extremely high network activity, transactions can either remain pending for a very long period or instantly get a failed transaction notification. This can lead to confusion and frustration for users, especially the ones unfamiliar with Gas Fees and how they are calculated.
This tutorial will help you if:#
- Your transaction has been pending for a long time, and you don't know what to do
- Your transaction has failed, with an error such as
transaction was underpriced
- It's your first transaction, and you want to be sure about any potential issues
You can directly skip to the solution if you don't wish to read the entire tutorial and key concepts.
Gas fees should only be adjusted when your transactions are failing or pending for a long period due to high network activity or heavy network congestion when fees are frequently fluctuating. Such adjustments are not required during normal network activity days. Wallets like Decypher and MetaMask will automatically do that for you.
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 DJT 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 utilisation. This window has a target utilisation, 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
andgas 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
.
_10EffectiveTip = min(MaxFeeCap - BaseFee, GasTipCap)
Consider the following examples (here Gwei or nDJT equates to one-billionth of 1 DJT)
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 prioritise transaction A since thats the transaction thats willing to pay an higher effective tip.
Primary reasons for Trasnaction Pending 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 nDJT or Gwei). Although the
base fee is automatically estimated in wallets like 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 or wait for the network activity to get a bit lower before trying again.
You can use Decypher Extension which automatically adjusts the Gas Fees based on Dijets Utility Chain's Gas Tracker. Or you can manually make the fee adjustments through wallets like 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 Dijets Mainnet, in which we will be sending 0.1 DJT to a receiver using the MetaMask. By clicking Next we can review gas fees and the amount which we want to send.
-
On the review page, you can see the estimated priority and max fee for this transaction. Click on EDIT, to adjust these fees according to network requirements.
-
You can edit the priority fee (gas tip cap) and max fee (max fee cap) using the advanced options or you can use MetaMask's inbuilt gas estimation. You can estimate the max fee as shown on Dijets Utility Chain Explorer which represents the average max fee over the last 5 seconds.
-
If the network activity is high, you have to edit the priority and max fees accordingly, as shown on Dijets Utility Chain Explorer. Consider the example below, where the average max fee is 31.25 Gwei (nDJT).
-
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. Apart from that, MetaMask will indicate you whether you are paying extra price than required, so you should not have to worry about getting overcharged. Edit the max fee to 40 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 40 Gwei. The more the priority fee the faster the transaction is. As an example, let's set this to 2 Gwei. You can also rely on MetaMask's automatic estimate instead of opting for advanced options. Now, save and confirm 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.
Transaction | Max Fee Cap | Gas tip cap | Base price | Effective tip | Total price |
---|---|---|---|---|---|
1 | 40 Gwei | 2 Gwei | 25 Gwei | 2 Gwei | 27 Gwei |
Speeding Up the Pending Transaction#
If your transaction is on hold for a very long time, you can speed up through MetaMask. Click on the Speed Up button, to edit your priority and max fee. By default, the new transaction has slightly more priority and max fee (say 10% more than the previous), but you can edit the value as required.
You can look at Utility Chain Explorer's gas tracker to get an estimate about the average base fee, which is currently getting accepted. If the max fee of the network is much higher than your transaction, then set the max fee cap to match that of the network.