The eth_feeHistory API was recently introduced in the JSON-RPC spec as a counterpart to EIP1559, which is currently live on Ropsten & Goerli and is scheduled for mainnet at block 12965000.
The API exposes information that is useful for setting parameters for the new transaction fee mechanism. One main rationale for EIP1559 is to improve the transaction-sending user experience. Wallet designers seeking to implement a change to deliver the improved user experience will need to have access to that information.
Together, a wallet and user must select two parameters, maxPriorityFeePerGas and maxFeePerGas. If the API was implemented on Erigon it would allow for rational selection of those two parameters using an Erigon node. Otherwise, another source of information might be needed.
This API might remove the need for third party gas price oracles, increasing users autonomy and rewarding those who run an Erigon node.
What are the use-cases?
Check the current and recent base fees to plan maximum fee (maxFeePerGas). For example, a wallet might choose a maximum fee that is twice the base fee.
Fetch recent priority fee distribution to plan gas premium (maxPriorityFeePerGas). For example, a wallet might choose the gas premium that was the lowest accepted in the last block, or the average of some percentile that matches user preference.
Convey customised fee information to users (e.g., Wallets or explorers showing a chart of base fees or recent gas premia).
A range of wallet-related resources are here. I also made some notes on what the API could enable for a wallet UI here.
Implementation
I am making this issue primarily to raise awareness about the API and the ecosystem it might support. While not strictly required before the Mainnet hard fork, there might be a dependency graph:
Erigon API implementation.
Erigon-based wallets/services implement change using JSON-RPC API.
Services that want to deliver UI improvement can implement on Ropsten/Goerli and test.
Mainnet forks and end-user wallets/services transition cleanly.
I will not be implementing the API, but hope to instead be useful in the process if I can.
API notes
Here is a digest that I have made using the JSON-RPC spec, which outlines the key components used in the API POST method.
blockCount
Required
How many blocks of fee history are wanted?
"Number of blocks in the requested range. Between 1 and 1024 blocks can be requested in a
single query. Less than requested may be returned if not all blocks are available."
Formatted as a hexadecimal representation of the integer as a string.
e.g. for 25 blocks, str(hex(25)) = "0x19".
newestBlock
Required
What is the most recent block that is wanted?
"Highest number block of the requested range."
Formatted as either of:
A hexadecimal representation of the integer as a string.
e.g. for block 5093543, str(hex(5093543)) = "0x4db8a7".
This is the most recent block that is wanted.
A descriptor string, one of:
"earliest".
Starting from genesis
"latest".
The block that was just mined.
"pending".
The block that is about to be mined.
rewardPercentiles
Optional
Which percentiles of the gas premium are wanted?
"A monotonically increasing list of percentile values to sample from each block's
effective priority fees per gas in ascending order, weighted by gas used."
E.g. 0th, 25th, 50th, 75th and 90th percentiles.
Formatted as floating point values between 0 and 100 as a string.
E.g. For the example above:
["0", "25", "50", "75", "100"]
Or percentiles 0-3rd with 0.5 increments, and the 80th percentile:
Rationale
Why should this feature exist?
The eth_feeHistory API was recently introduced in the JSON-RPC spec as a counterpart to EIP1559, which is currently live on Ropsten & Goerli and is scheduled for mainnet at block 12965000.
The API exposes information that is useful for setting parameters for the new transaction fee mechanism. One main rationale for EIP1559 is to improve the transaction-sending user experience. Wallet designers seeking to implement a change to deliver the improved user experience will need to have access to that information.
Together, a wallet and user must select two parameters,
maxPriorityFeePerGas
andmaxFeePerGas
. If the API was implemented on Erigon it would allow for rational selection of those two parameters using an Erigon node. Otherwise, another source of information might be needed.This API might remove the need for third party gas price oracles, increasing users autonomy and rewarding those who run an Erigon node.
What are the use-cases?
maxFeePerGas
). For example, a wallet might choose a maximum fee that is twice the base fee.maxPriorityFeePerGas
). For example, a wallet might choose the gas premium that was the lowest accepted in the last block, or the average of some percentile that matches user preference.A range of wallet-related resources are here. I also made some notes on what the API could enable for a wallet UI here.
Implementation
I am making this issue primarily to raise awareness about the API and the ecosystem it might support. While not strictly required before the Mainnet hard fork, there might be a dependency graph:
I will not be implementing the API, but hope to instead be useful in the process if I can.
API notes
Here is a digest that I have made using the JSON-RPC spec, which outlines the key components used in the API POST method.
blockCount
str(hex(25)) = "0x19"
.newestBlock
str(hex(5093543)) = "0x4db8a7"
.rewardPercentiles