eth_feeHistory: Base Fees and Priority Fee Percentiles

What eth_feeHistory does

You ask for a window: how many blocks, ending at which block, and which reward percentiles you care about. The node walks those blocks and answers with three parallel arrays plus, when you asked for percentiles, a fourth. Everything is hex, and everything is per block in ascending order starting at oldestBlock.

The reward percentiles are gas-weighted, which is the detail that makes them useful. For each block the node sorts that block's transactions by the priority fee they actually paid and walks the cumulative gas, so the 50th percentile is the tip paid at the block's halfway point by gas, not the median transaction. A tip at the 10th percentile is what the cheapest quarter of the block's work paid; the 90th is what impatient flow paid.

Base fees need no percentile because they are determined by the protocol: each block's base fee follows mechanically from the previous block's gas usage and can move at most 12.5% per block. That is why the returned baseFeePerGas array holds one more entry than you asked for: the extra, final entry is the base fee of the block after the newest one, already computable and the number you should actually price against.

Parameters

Percentiles must be monotonically increasing and within 0 to 100; an unsorted list is rejected outright. Each extra percentile makes the node read more of every block in the window, so a 1,024-block window with five percentiles is a genuinely heavy request compared to a ten-block window with three.

What it returns

oldestBlock, the first block in the window; baseFeePerGas, an array of blockCount + 1 entries where the last is the projected base fee for the block after the window; gasUsedRatio, how full each block was as a float between 0 and 1; and reward, one array per block holding the tip at each requested percentile. Post-Cancun responses add baseFeePerBlobGas and blobGasUsedRatio, which follow the same layout for the separate blob fee market.

Blocks with no transactions still appear: their gasUsedRatio is 0 and their reward entries are zeros. The base fee is defined for every block regardless, so the baseFeePerGas array never has gaps.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "oldestBlock": "0x18789a3",
    "baseFeePerGas": ["0x335642e", "0x31e8878", "0x2efe39d", "0x325ddb7", "0x306ece9"],
    "gasUsedRatio": [0.3886851833, 0.2663517333, 0.7871539, 0.3464228833],
    "reward": [
      ["0xf4240", "0xf9311d", "0x3b9aca00"],
      ["0xfec8", "0x2d75888", "0x547906e6"],
      ["0xf4240", "0xc7b3bf", "0x38aae663"],
      ["0xf4240", "0x2faf080", "0x3b9aca00"]
    ]
  }
}

Four blocks, three percentiles. Note the five base fees for four blocks: the last one is the base fee of the next block, which is the one to price against. In the second row the 10th percentile paid 0xfec8 wei (0.000065 gwei) while the 90th paid 0x547906e6 (about 1.42 gwei), which is the spread a single averaged gas price would have hidden.

import { JsonRpcProvider, formatUnits } from "ethers";

const provider = new JsonRpcProvider("https://ethereum-rpc.publicnode.com");

// ethers has no wrapper for eth_feeHistory; use provider.send
const history = await provider.send("eth_feeHistory", ["0x14", "latest", [50]]);

// the last baseFeePerGas entry is the NEXT block's base fee
const nextBaseFee = BigInt(history.baseFeePerGas.at(-1));

// median tip across the window
const tips = history.reward.map((r) => BigInt(r[0])).sort((a, b) => (a < b ? -1 : 1));
const medianTip = tips[Math.floor(tips.length / 2)];

const maxFeePerGas = nextBaseFee * 2n + medianTip; // room for one 12.5% climb and then some
console.log(formatUnits(maxFeePerGas, "gwei"), "gwei cap,", formatUnits(medianTip, "gwei"), "gwei tip");

Gotchas and common errors

What eth_feeHistory costs on BLAZED.sh

eth_feeHistory costs 1 credit per call on BLAZED.sh regardless of how wide the window is, which makes one 20-block request with three percentiles a far better deal than twenty separate block fetches. Very wide windows can produce large responses, and anything over 100KB adds 50 credits per MB, but a normal fee-strategy request of a few dozen blocks is nowhere near that. Bots that re-price every block get the extra benefit of the local path: the call resolves on the node host in under 10ms instead of racing a gateway round-trip against the next slot.

eth_feeHistory: frequently asked questions