Gas Limit vs Gas Price: Ethereum Transaction Fees Explained

Gas limit and gas price are two separate settings that together determine an Ethereum transaction's total fee. Gas limit is the maximum amount of computational work — measured in /glossary/gas units — that a transaction is allowed to consume, while gas price (now split into a base fee and priority fee) is how much you pay per unit of gas actually used. Confusing the two is a common source of failed transactions and fee-estimation mistakes.

What gas measures

Every operation on Ethereum — storing data, transferring tokens, executing contract logic — has a fixed cost denominated in gas units, reflecting the actual computational and storage burden it places on the network. A simple ETH transfer costs a small, fixed amount of gas. A complex DeFi transaction interacting with multiple contracts can cost many times more, since it triggers far more computation.

Gas limit: the cap, not the cost

The gas limit is the maximum number of gas units you authorize a transaction to consume — it is not itself a cost, but a ceiling. If your transaction's actual execution needs less gas than the limit, you only pay for what was actually used; the unused portion of the limit is never charged. If a transaction runs out of gas before completing — because the limit was set too low — it fails, but critically, the gas consumed up to that failure point is still spent and non-refundable, since the network still did real computational work before the transaction ran out of room.

Gas price: what you pay per unit

Since the EIP-1559 upgrade, gas price is split into two components, described in more depth in /blog/what-is-eip-1559-base-fee-burn:

• Base fee — an algorithmically determined fee per gas unit, adjusting automatically with network congestion, that gets burned rather than paid to a validator.
• Priority fee (tip) — an additional amount you choose to add, paid directly to the validator, to incentivize faster inclusion when many transactions are competing for block space.

Your total fee is calculated as: gas used × (base fee + priority fee).

How the two combine

Setting	What it controls	Who sets it	Effect if set wrong
Gas limit	Maximum gas the transaction may consume	You (or your wallet, based on a simulation)	Set too low: transaction fails, gas is still spent. Set high: no extra cost if unused.
Base fee	Price per gas unit, algorithmically adjusted	The protocol, based on recent block fullness	Not directly controllable, but predictable enough to estimate in advance
Priority fee	Extra tip per gas unit paid to validators	You (or your wallet's suggestion)	Set too low during congestion: transaction may sit pending for a long time

Why wallets estimate gas limit automatically

Most wallets simulate a transaction before you send it, estimating the gas it's likely to require and setting a gas limit slightly above that estimate as a safety margin. This is why manually overriding the suggested gas limit to a very low number is risky — if the actual execution needs more gas than you've allowed, the transaction fails partway through and you still pay for the gas already consumed.

Reading these fields on a block explorer

When reviewing a completed transaction, as covered in /blog/how-to-read-etherscan-transactions, you'll see both the gas limit that was authorized and the gas actually used — if these numbers are close together, it can indicate the transaction nearly failed from running out of gas.

What happens to unused gas and failed transactions

It's worth being precise about refunds. If you set a gas limit higher than what a transaction actually needs, you are only ever charged for the gas genuinely consumed — the difference is simply never spent, not refunded after being charged, since it was never actually deducted in the first place. The opposite scenario is where costs get confusing: a transaction that runs out of gas partway through still pays for every unit of gas consumed up to the point of failure, even though the intended action never completed. This is a deliberate design choice, since the network still performed real computational work up to that failure point and needs to be compensated for it regardless of the transaction's ultimate outcome.

Practical implications for users

Understanding this distinction matters most in two situations: interacting with complex contracts where gas needs can be harder to predict (raising the case for a slightly higher gas limit buffer), and during network congestion, where raising your priority fee — not your gas limit — is what actually speeds up inclusion. More detail on estimating these values in advance is covered in /blog/how-to-estimate-ethereum-gas-fees.

Bottom line

Gas limit caps how much computational work a transaction is allowed to use, while gas price (base fee plus priority fee) determines what you actually pay per unit of that work. Getting the gas limit too low risks a failed transaction that still costs you gas, while the priority fee — not the limit — is the lever that actually affects how quickly a transaction gets included during busy periods.