eth_feeHistory
API post London fork. We will also discuss the eth_maxPriorityFeePerGas
method and replicate the calculation it performs. Then we will discuss how you might productionize such a calculator.eth_feeHistory
API and it's result:eth_feeHistory
results through the formatter:priorityFeePerGas
field represent the 25th, 50th, and 75th percentiles of priority fees that were submitted in those blocks.gasUsedRatio
. This ratio refers to how full the block was. You can see that block 12966164 was 99% full, block 12966165 was 23% full, 12966166 was 88%, and 12966167 was 99%.priorityFeePerGas
field, you can see that for block 12966164 the 25% percentile of transactions spent 34222993160 in priority fees, while the 75% percentile spent 63222993160 in priority fees. That's almost a 2x increase! The spread can be pretty drastic.gasUsedRatio
and baseFeePerGas
gasUsedRatio
and baseFeePerGas
is literally the crux of EIP 1559 and the London fork.gasUsedRatio
of over 99%. It has a baseFeePerGas
of 315777006840. The very next block (12966165) has a baseFeePerGas
of 354635947504, an increase of approximately 12%.gasUsedRatio
of approximately 23%, which means the subsequent block (12966166) has a lower base fee.gasUsedRatio
and priorityFeePerGas
for historical blocks. Let's use them to create an estimate.maxPriorityFeePerGas
field on your transaction and you've got a decent chance of being included in the block.eth_maxPriorityFeePerGas
eth_maxPriorityFeePerGas
method.eth_feeHistory
exposes to us, but we'll do our best. I suspect the bottom 3 transactions would be approximately in the 1st percentile of priority fees, so here is our attempt at replication:baseFeePerGas
from the pending block, which is already known by the network. Then we add the tip on top of that. This is the full value (in Wei) that we can present to the end user. You might want to convert that to Gwei first, since that's normally what users see.eth_feeHistory
call with 3 percentiles. Since we are doing the 1st percentile on the "slow" end, let's do the 99th percentile on the "fast" end, and of course "average" refers to the 50th percentile. So here we go!eth_feeHistory
API are nice, but they don't tell the full story (as we've seen). Just look at the spread of fees within a single block! There is a ton of cost saving potential for better fee estimation.gasUsedRatio
. What happens when a block is 50% full and then the next one is 99% full? Lots of transactions get dropped. Perhaps there is a better predictor of these spikes?