3

In ethers.js you can use provider.getGasPrice() to get a best-guess estimate of the gas you should pay. Is there anything simple I can call or transform onto this value in order to get what an equivalent of a "Fast" transaction would be instead of an "Average" speed transaction?

TylerH
  • 20,799
  • 66
  • 75
  • 101
aroooo
  • 4,726
  • 8
  • 47
  • 81

1 Answers1

4

The getGasPrice() queries your provider JSON-RPC method eth_gasPrice and simply proxies whathever your provider returned.

In order to calculate the "Fast" and "Average" speed, you'll need to define what you consider these metrics. For example you can collect all transactions within the last 20 blocks (approx. 5 minutes) and look for percentiles in the historic data:

  • Top 10% percentil of gas prices is "Fast"
  • Top 50% percentil of gas prices is "Average"

You can get transactions in a block using the getBlockWithTransactions() ethers.js method. In each transaction you're looking for the gasPrice property.

Petr Hejda
  • 40,554
  • 8
  • 72
  • 100
  • What does "look for percentiles in the historic data mean"? Top 10% according to which Metric? Thanks Petr! – Tomiwa Jun 18 '22 at 14:17
  • @Tomiwa The `gasPrice` field of each transaction. – Petr Hejda Jun 18 '22 at 14:42
  • 1
    I see. I realized the point I was trying to make. A more appropriate method might be: 1. Define fast as having your tranaction confirmed within 10-15 seconds. 2. Get the average gasPrice for all transactions that completed within 10-15 seconds in the last 20 bocks. 3. The number from 3 is your "fast" gasPrice. I guess this strategy relies on there being a way to see how long a transaction took to get a certain number of confirmations. Is such a thing possible? If not possible from blockchain directly, what if we used a 3rd party API like Etherscan? – Tomiwa Jun 18 '22 at 15:48
  • 1
    @Tomiwa There's no field of the raw transaction stating when the transaction was broadcasted - only when it was mined. If there was such field (broadcast timestamp), your approach would be possible... Etherscan lists the pending transactions when their node catches the tx. That's not exactly the timestamp of when the transaction was broadcasted - only when Etherscan learned of its existence. But it might be possible to implement your approach, assuming you're okay with this difference in the "tx created" timestamp. Great thinking! – Petr Hejda Jun 18 '22 at 20:59