How to Estimate Gas Fees on Ethereum and Other Chains
Learn how to estimate gas fees: the formula, gas limit vs gas price, eth_estimateGas, and the traps on Arbitrum and other chains, with a worked example.
To estimate a gas fee, multiply the gas a transaction will use by the price you pay per unit of gas. On Ethereum after EIP-1559, that means (base fee + priority fee) × gas units used. The units come from simulating your exact transaction. The price comes from the live network. This guide shows both halves, then covers what changes on layer 2s, with smart accounts, and when you build payments into an app.
(If you landed here looking for the price of fuel for your car, this page is about blockchain transaction fees.)
TL;DR
- Fee = gas used × price per gas. Gas used measures computational work. The price per gas reflects demand.
- Simulate the exact transaction with
eth_estimateGasfor the units, and read live fee data for the price. Refresh both right before signing. - A gas limit is a ceiling, not a charge. Unused gas is not consumed, but a failed transaction still pays for the work it did.
- Rollups like Arbitrum add a layer 1 data cost. Use each chain’s own estimator, not an Ethereum mainnet assumption.
- For payment apps, store the estimate, fee fields, timestamp and final receipt fee so you can reconcile later.
Table of Contents
- The formula behind every gas estimate
- Gas limit vs gas price
- A worked example
- Estimating gas in code
- Layer 2 and other chains do not follow the mainnet formula
- Smart accounts and sponsored gas
- Common estimation mistakes
- What to record for payments
- Our perspective
- Skip the per-chain fee plumbing
- FAQ
- Sources
The formula behind every gas estimate
Ethereum.org defines gas as the unit that measures the computational effort needed to run operations on the network. Every transaction consumes some amount of it. You then pay a price for each unit. That gives two separate numbers:
- Gas units depend on what the transaction does. Sending ETH to a plain address is simple. Calling a smart contract is not.
- Price per gas depends on how busy the network is right now. It is quoted in gwei.
The point most calculators hide: changing your contract logic moves the first number, while congestion moves the second. A good interface shows both instead of one unexplained total.
Gwei and ETH
One gwei equals 0.000000001 ETH (10^-9). So to convert, multiply gas units by the price in gwei, then divide by 1,000,000,000 to get ETH. Multiply by the ETH price only if you want a dollar figure. Our gwei converter handles wei, gwei and ETH in both directions.
What EIP-1559 changed
Since EIP-1559, each block has a base fee per gas that moves up or down with demand, and the base fee is burned. On top of that, a transaction carries a priority fee (the tip) and a max fee, the most you are willing to pay per gas in total. You pay the base fee of the block that includes you plus your tip, as long as the sum stays under your max fee.
So a wallet quote has three moving parts: units, base fee and tip. The max fee is a safety cap, not a prediction.
Gas limit vs gas price
These two terms trip up most newcomers, so here they are side by side.
| Gas limit | Gas price | |
|---|---|---|
| What it is | The most gas units you allow the transaction to use | What you pay per unit, in gwei |
| Set by | Your estimate of the work involved | Market demand, plus your tip |
| Raising it | Does not raise the fee by itself | Raises the fee directly |
| Too low | Transaction fails | Transaction waits or is not included |
The key behavior: a gas limit is a ceiling. A standard ETH transfer uses 21,000 gas, and unused allocated gas is returned. MetaMask notes that raising a limit manually does not necessarily raise the final fee because unused gas is not consumed. It also does not buy faster confirmation. A manual override only protects you from underestimation.
The danger runs the other way. If a contract runs out of gas during execution, it reverts but still consumes the gas you supplied. And computation is paid for even when a transaction reverts. That is why you simulate before you broadcast.
A worked example
The numbers below are illustrative, not live prices. Assume a base fee of 20 gwei and a priority fee of 2 gwei, so 22 gwei per gas.
| Transaction | Gas units | Price per gas | Fee in gwei | Fee in ETH |
|---|---|---|---|---|
| Plain ETH transfer | 21,000 | 22 gwei | 462,000 | 0.000462 |
| ERC-20 approval (typical wallet display) | 45,000 | 22 gwei | 990,000 | 0.00099 |
The 21,000 figure for a simple transfer comes from Ethereum.org. The 45,000 figure is what MetaMask commonly shows for an ERC-20 approval, but the real number depends on the contract and its state. A token transfer or a swap will differ again. That is the whole reason you cannot hardcode units for anything beyond a plain transfer.
To get a fiat figure, take 0.000462 ETH and multiply by the current ETH price. Do that last, and label it as approximate.
Estimating gas in code
If you are building rather than clicking, the process has four steps.
- Describe the full transaction intent.
eth_estimateGasneeds the chain, the destination address, the calldata and the value, and optionally fee fields. Change the token amount, the recipient or the contract state and the estimate can change. Never reuse the estimate from a different transfer. - Call
eth_estimateGasagainst a node. It returns the units required, usually as a hexadecimal number you must decode. - Fetch current price recommendations. Ask a fee oracle or your node for a base fee and a tip suggestion at the speed you want (slow, standard, fast).
- Compute and present a range. Multiply units by the price, and show users a maximum or range. A quote is not a guarantee, and the network can move between estimation and inclusion.
Then add one habit that saves headaches: refresh the price immediately before signing. Gas price is demand-sensitive, so the same transaction can cost different amounts at different times. Ethereum.org points to block explorers and gas trackers for live data when you only need a quick check by hand.
Pad the limit, not the price
A small buffer on the gas limit is cheap insurance, since unused gas is not charged. Padding the price per gas, on the other hand, directly increases what you pay. Keep those two decisions separate in your code.
Layer 2 and other chains do not follow the mainnet formula
A single generic EVM formula can mislead. Rollups charge for two things: execution on the layer 2, and posting your transaction data to layer 1.
Arbitrum is a good example. Its documentation says the quick path is calling eth_estimateGas and multiplying by the child-chain gas price. The returned gas limit includes layer 2 computation plus a buffer for the layer 1 cost. That buffer depends on compressed calldata size and on parent-chain pricing, so the estimate can shift when layer 1 gets busy. For component-level accounting, the NodeInterface.gasEstimateComponents call splits out the total, the layer 1 buffer and base fee data. Arbitrum itself warns that estimates are approximate and actual fees may differ.
For a deeper walk-through, see our post on tracking live Arbitrum gas fees with NodeInterface and Nitro’s formula.
Tron works on an entirely different model. It charges in bandwidth and energy rather than a gas price, so none of the above applies directly. Our guide to TRON fees and the TRON fee calculator for USDT-TRC20 transfers cover that model.
The rule for multi-chain products: use each network’s own estimator, and keep chain-specific logic behind one interface.
Smart accounts and sponsored gas
If you use account abstraction with a paymaster, a plain transaction quote is not enough. ERC-7677 explains that paymaster estimation depends on context, because the wallet and bundler know how the user operation will actually be submitted. It says wallets should use paymaster-provided gas values for paymaster-specific fields, including post-operation gas, since bundlers may underestimate those costs.
In practice: estimate through the same wallet, paymaster and bundler path you will use to broadcast. Do not reuse a number from an ordinary transaction.
Common estimation mistakes
- Showing one number with no context. Users should see the units, the price, and a maximum.
- Using the wallet’s maximum limit as the expected charge. The limit is a ceiling. Multiplying it by the price overstates the likely fee.
- Estimating once and signing later. Prices and contract state move. Re-simulate right before signing.
- Applying Ethereum mainnet assumptions to a rollup. You will miss the layer 1 data component.
- Ignoring failures. A reverted transaction still costs gas. Simulate first and surface errors before the user pays.
- Dropping the audit trail. Without records, finance cannot reconcile quotes against what was actually charged.
What to record for payments
If your app moves money, treat the estimate as data worth keeping. For each transaction, store:
- the chain and block context
- the gas estimate and the gas limit you set
- the fee fields you used (base fee, tip, max fee)
- the timestamp of the estimate
- the final fee from the transaction receipt
Comparing the quote with the receipt tells you how far your estimates drift and whether your buffers are too tight or too generous. It also gives support a straight answer when a customer asks why a fee changed.
Our perspective
Most teams we talk to do not struggle with the formula. They struggle with everything around it: running nodes for several networks, decoding raw responses, handling each chain’s fee quirks, and keeping all of it consistent as chains change.
We built Chaingateway around that gap. The idea is one REST API across chains such as Ethereum, Tron, Bitcoin, Solana, Polygon, BNB Chain and Arbitrum, with automatic gas estimation and pre-decoded data, so your team is not maintaining a separate fee path per network. Our view is that fee estimation should be a built-in step of sending a transaction, not a side project your developers rebuild for every chain.
We also think a quote should be honest. Show the estimate as an estimate, keep the receipt fee next to it, and let the numbers teach you where your buffers belong.
— Bitblade
Skip the per-chain fee plumbing
If you are building wallets, payouts or deposit flows, our Blockchain API lets you create wallets, send token transfers with automatic gas estimation, and fetch decoded transaction data through one interface. Pair it with Chaingateway Webhooks to get real-time notifications when payments arrive, instead of polling. Requests are HMAC-signed.
Plans are billed per month or per year, and you can see every tier on the pricing page:
| Plan | Monthly | Yearly |
|---|---|---|
| Plus | 49 EUR per month | 490 EUR per year |
| Pro | 99 EUR per month | 990 EUR per year |
| Premium | 249 EUR per month | 2490 EUR per year |
| Enterprise | 499 EUR per month | 4990 EUR per year |
Building on Arbitrum specifically? See how to send ERC-20 tokens on layer 2 with one REST call. For background on ETH, gas and ERC-20 tokens, our Ethereum overview is a good start.
Sources
- Ethereum gas and fees: technical overview, ethereum.org
- How to estimate the gas fee, MetaMask Help Center
- How gas fees, limits, and network fees work, MetaMask Help Center
- How to estimate gas in Arbitrum, Arbitrum docs
- ERC-7677: Paymaster Web Service Capability
- EIP-1559, Ethereum Improvement Proposals
Recommended
Frequently asked questions
Simulate your exact transaction with eth_estimateGas to get the gas units. Get the current base fee and a priority fee suggestion, then compute (base fee + priority fee) × gas units. Convert from gwei to ETH, and to dollars only if you need to display one.
The gas limit is the maximum number of gas units you allow a transaction to use. The gas price is what you pay per unit, in gwei. The limit is a ceiling and unused gas is not charged, while the price directly scales your fee.
Not always. An estimate is based on conditions at the moment you ask, and the network can change before your transaction is included. On Ethereum you pay the base fee of the block that includes you plus your tip, capped by your max fee. Show users a range or maximum rather than a guaranteed figure.
Yes, in most cases. Computation that happened before a revert is still paid for, and a transaction that runs out of gas mid-execution consumes the gas supplied. Simulating beforehand catches many failures before you spend anything.
Rollups charge for execution on the layer 2 and for posting data to layer 1. On Arbitrum, the estimated gas limit includes a buffer for that layer 1 cost, which changes with parent-chain pricing. Use the chain’s own estimation method.
Ready to build this yourself? Get your API key — 7-day trial, no card required — or see the Blockchain API for the full endpoint reference.