eth_gasPrice: The Node's Suggested Gas Price
eth_gasPrice•Read method•Ethereum JSON-RPCeth_gasPrice returns a single wei-per-gas figure the node thinks would get a transaction mined. It predates EIP-1559 and still exists because legacy transactions still exist. Post-London it is a convenience wrapper: the node adds the current base fee to its suggested tip and hands you the sum, discarding the structure that makes fee markets legible.
Try eth_gasPrice
curl -s https://ethereum-rpc.publicnode.com \
-X POST \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_gasPrice",
"params": []
}'Runs the example straight from your browser against the endpoint above. The prefilled URL is a third-party public endpoint, not run by BLAZED.sh.
What eth_gasPrice does
The number is produced by the client's gas price oracle, not by consensus. Geth samples the transactions of recent blocks, takes a percentile of the tips it observed, clamps the result against a configured ceiling, and adds the current base fee. Nethermind, Erigon and Reth each implement their own variant, so two healthy nodes on the same chain legitimately return different numbers at the same moment.
For a legacy (type 0x0) transaction, gasPrice is the whole fee: the base fee is burned out of it and whatever remains goes to the block proposer as the tip. Legacy transactions are still valid, and a value returned here can be dropped straight into one, which is why simple scripts and older tooling keep using this method.
For an EIP-1559 (type 0x2) transaction there is no gasPrice field to fill in. You need maxFeePerGas and maxPriorityFeePerGas, and collapsing them into one number throws away the ability to set a generous cap while paying a small tip. That separation is the entire point of the 1559 fee market, so anything sending typed transactions should be reading eth_feeHistory or eth_maxPriorityFeePerGas instead.
Parameters
eth_gasPrice 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 property of any particular block.
What it returns
A hex quantity in wei per gas. Post-London this is the base fee of the pending block plus the oracle's suggested tip, so it moves with both the fee market and whatever sampling window the client uses.
There is no error case worth planning for and no null: a node always has an opinion. The risk is not that the call fails, it is that the number is stale by the time your transaction reaches a builder.
Example response
{
"jsonrpc": "2.0",
"id": 1,
"result": "0x326dc7f"
}0x326dc7f is 52,878,463 wei, about 0.053 gwei, on a quiet mainnet block whose base fee was roughly 0.048 gwei. The gap between the two is the tip the oracle suggested; both numbers move constantly, so run the example for a current one.
eth_gasPrice with ethers.js
import { JsonRpcProvider, formatUnits } from "ethers";
const provider = new JsonRpcProvider("https://ethereum-rpc.publicnode.com");
// the legacy single number
const legacy = await provider.send("eth_gasPrice", []);
console.log("gasPrice:", formatUnits(BigInt(legacy), "gwei"), "gwei");
// what you actually want for a type-2 transaction
const fees = await provider.getFeeData();
console.log("maxFeePerGas:", formatUnits(fees.maxFeePerGas, "gwei"), "gwei");
console.log("maxPriorityFeePerGas:", formatUnits(fees.maxPriorityFeePerGas, "gwei"), "gwei");Gotchas and common errors
It is one number where you need two
An EIP-1559 transaction is priced with a cap you are willing to pay (maxFeePerGas) and a tip you offer the proposer (maxPriorityFeePerGas). eth_gasPrice folds both into a single figure, which means either overpaying the tip or setting a cap with no headroom. Set the two fields explicitly from eth_feeHistory or eth_maxPriorityFeePerGas and keep this method for legacy transactions.
The oracle looks backwards
Every implementation samples blocks that have already been built, so the answer lags the market it is describing. During a spike it is too low and your transaction sits; right after a spike it is too high and you overpay for a block that has already cleared. Anything time-sensitive needs its own view of recent percentiles, which is what eth_feeHistory provides.
A stale price falls under the base fee
Base fee can rise 12.5% per block, so a value fetched a minute ago can be below the next block's base fee. Submitting it produces "max fee per gas less than block base fee", and a transaction already in the mempool at that price simply stops being minable until the base fee falls back. Re-read the price close to submission, and set a cap with room for several consecutive increases.
Two providers will disagree
The oracle's sampling window, percentile and ceiling are client configuration. Comparing eth_gasPrice across endpoints compares their configurations, not the network. If you must compare, compare base fees from block headers, which are consensus values that every node agrees on.
It says nothing about how much gas you need
This is a price per unit of gas. The quantity of gas comes from eth_estimateGas, and the cost of a transaction is the product of the two. Confusing the price with the limit produces transactions that either fail immediately or carry a nonsensical fee.
What eth_gasPrice costs on BLAZED.sh
eth_gasPrice costs 1 credit per call on BLAZED.sh and returns a handful of bytes, so the only way to spend real money on it is to call it far more often than the fee market changes. Since a new base fee is only set once per block, one read per block is enough; a bot that wants a finer view is better served by a single eth_feeHistory request covering the same window. Both resolve on the node host in under 10ms when your code sits next to the node, which matters when the price you fetch has to still be valid when the transaction lands.
See the full credit price listeth_gasPrice: frequently asked questions
Is eth_gasPrice still valid after EIP-1559?
Yes, it still works and still returns a number you can use for a legacy transaction. It is simply the wrong tool for typed transactions, which need maxFeePerGas and maxPriorityFeePerGas set separately.
How does the node calculate eth_gasPrice?
From its own gas price oracle: it samples the tips paid in recent blocks, takes a percentile, clamps it against a configured maximum, and adds the current base fee. The exact sampling differs per client and per configuration, which is why nodes disagree.
Why is my transaction stuck even though I used eth_gasPrice?
The price was probably fetched too early. Base fee can rise 12.5% per block, so a value from a minute ago can be below the current base fee, and a transaction priced below base fee is unminable until the market falls back. Replace it with a bumped fee, or set a higher cap from the start.
Should I use eth_gasPrice or eth_feeHistory?
eth_feeHistory for anything you care about: it returns per-block base fees and tip percentiles so you can choose a strategy. eth_gasPrice for legacy transactions and quick scripts where a single approximate number is fine.
Does eth_gasPrice include the base fee?
Post-London, yes; the returned value is the current base fee plus the oracle's suggested tip. That is why it is usually slightly above the base fee you read from the latest block header.
Call eth_gasPrice from the node itself
Deploy your container or script next to a synced Ethereum node. No rate limits, no compute units, sub-10ms local RPC.