The primary goal of ethgasstation.info is to provide reasonably accurate, real-time predictions of the time it will take for any given transaction to be confirmed on the Ethereum network. This piece of information can help wallets and users set the best gas price based on how quickly they need a confirmation and what fee they are willing to pay.

Ethereum now routinely processes over 300,000 transactions per day — and ethgasstation records the block at which all transaction are first seen by its node and the block at which it is later confirmed- so there is no lack of data on which to build a predictive model. In fact, as people who are familiar with model building will know, the biggest risk in model construction with large data sets like this is overfitting- i.e. assuming there is real relationship between two variables based on statistical tests, when in fact the model is fundamentally misspecified.

As I have previously written, up until recently, the transaction time prediction model used at ethgasstation included the following parameters: the transaction’s gas price, the percent of network hashpower that accept that gas price, the number of transactions at or above the transaction’s gas price in the txpool, and whether the transaction was a simple transfer (i.e. gas offered = 21,000). It turns out this while this produced reasonable predictions in many circumstances– there was an important misspecification in the model that I will now describe.

If you study the ETH transaction pool today, you will notice the following phenomena: a substantial proportion of the current transaction volume comes from a relatively small number of addresses, often submitted in large batches to the network over short time intervals. Additionally, there are events like ICOs where there is a sudden surge in transactions from multiple users all going to the same address.

Based on my analyses of these transactions, it appears that miners employ policies that deprioritize transactions when there are large numbers sent by or to the same address. Furthermore, they seem to prioritize address diversity even at the cost of maximizing transaction fees. For example- if there are 2000 transactions submitted from the same address with a 30 Gwei gas price, you will still see transactions with lower gas prices getting confirmed before this entire batch is processed. Whatever the motivation, this policy has the effect of keeping the network running smoothly for the average user (who is typically only sending a couple transactions at a time).

These prioritization effects are very strong. In fact, once I adjusted for them in my models, it became apparent that there is no special advantage for transactions offering 21000 gas (a standard transfer) vs. higher gas contract calls. This is good news for users interacting with smart contracts.

In terms of confirmation time prediction, these phenomena create some difficulties. In order to give an accurate prediction, in theory you would need to know not only about the number and gas price of transactions in the txpool but also their to and from addresses and where the user was intending to send their current transaction. While this is not insurmountable, a practical solution is to create predictions that apply only for transactions that are not going to high volume addresses (i.e. predicting confirmation during super hot ICOs is not really the goal of ethgasstation- the intent is rather to predict confirmation time and set gas price for standard, every day transactions)

With this new model (gas price, hash power accepting, number of transactions at or above gas price in txpool, and assuming a transaction is not being sent to/from a high volume address), I am now able to create much more accurate confirmation time predictions in real time. I have added the following table: http://www.ethgasstation.info/predictionTable.php which shows the predicted average and upper 99th percentile for confirmation time for transactions submitted at the current block based on their gas price. This provides a good sense of the non-linearity associated with gas price and confirmation time (e.g. 20gwei gas price is nowhere close t0 a 5x confirmation time improvement versus a 4 gwei gas price). Try it out and see if it is accurate. The most useful predictions are generally for gas prices in the 0.5–4 Gwei range where confirmation times can vary the most based on current network demand. One day, I hope to convince the wallet providers to stop setting default gas prices at 20 Gwei (or the median gas price of recent blocks) and instead use dynamic, ‘smart’ gas price settings that provide users better values for time and cost. Until then, my advice is use a 1-4 Gwei for a default and if you want lower fees or really fast confirmations, check the site to find the best values based on current network load.