eth_maxPriorityFeePerGas: The Node's Suggested Tip

What eth_maxPriorityFeePerGas does

The value comes from the client's oracle rather than from consensus. Geth samples the tips paid in recent blocks (twenty blocks at the 60th percentile by default), ignores transactions below a floor, and clamps the result against a configured ceiling. Other clients implement the same idea with their own defaults, so this is a well-informed guess about a market, not a protocol quantity.

A transaction's tip is what the proposer actually keeps; the base fee is burned. Blocks are filled in descending order of effective tip, so the suggestion answers "what were recent inclusions paying" rather than "what will get me into the next block". When blocks are not full, a tip of zero is perfectly minable; when they are, the suggestion is a floor rather than a target.

To build a fee you combine this with the base fee: maxFeePerGas has to cover the next block's base fee plus the tip, and most tooling doubles the base fee to absorb several consecutive 12.5% increases. The node charges you base fee plus tip and refunds the difference up to your cap, so a generous cap costs nothing extra when the market is calm.

Parameters

eth_maxPriorityFeePerGas takes no parameters; send an empty params array. There is no block parameter because the answer is the oracle's current opinion rather than a value stored in a block.

What it returns

A hex quantity: the suggested priority fee in wei per gas. It is not part of the block and no two clients are obliged to agree on it.

The number is often much smaller than people expect on a quiet chain, sometimes a tiny fraction of a gwei, because it reflects what the marginal recent transaction actually paid rather than what wallets habitually offer.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0xfec8"
}

0xfec8 is 65,224 wei, roughly 0.000065 gwei, on a quiet block. Suggested tips collapse toward zero when blocks are not full and climb sharply when they are, which is exactly why a hardcoded tip is a bad idea in both directions.

import { JsonRpcProvider, formatUnits } from "ethers";

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

const tipHex = await provider.send("eth_maxPriorityFeePerGas", []);
const tip = BigInt(tipHex);

const block = await provider.getBlock("latest");
const baseFee = block.baseFeePerGas;

// cap = room for a few 12.5% base fee climbs, plus the tip
const maxFeePerGas = baseFee * 2n + tip;

console.log("tip:", formatUnits(tip, "gwei"), "gwei");
console.log("cap:", formatUnits(maxFeePerGas, "gwei"), "gwei");
// ethers' getFeeData() performs both calls and returns the same pair

Gotchas and common errors

What eth_maxPriorityFeePerGas costs on BLAZED.sh

eth_maxPriorityFeePerGas costs 1 credit per call on BLAZED.sh and its response is a few bytes, so the surcharge for responses over 100KB is irrelevant here. Because the answer only changes meaningfully once per block, one call per block is the right cadence; pairing it with a block header read, or replacing both with a single eth_feeHistory request, keeps the request count proportional to the information. Co-located code gets that reading in a sub-10ms local round-trip, which is the difference between pricing against the current block and pricing against a stale one.

eth_maxPriorityFeePerGas: frequently asked questions