Ethereum Gas Fees: Why the Gas Limit Is Not What You Pay

A wallet showing a transaction cost usually shows one figure, which invites the assumption that one setting produced it.

Two did. A gas fee is units of computation multiplied by a price per unit, and the fields a wallet exposes do not all act on the same factor. Knowing which is which is what separates a setting that is refunded from one that is not.

Two Numbers, Not One: Gas Used and the Price Per Unit

Gas is a unit of computational effort. Every operation the network performs has a cost measured in those units, and the total a transaction consumes depends on what it asks the network to do.

A plain transfer of ETH from one account to another has a fixed intrinsic cost of 21,000 units. A transaction that calls a smart contract does more work and consumes more, sometimes far more.

The second number is what each unit costs, quoted in gwei. A gwei is one billionth of an ETH, a denomination that exists because quoting these prices in whole ETH means writing eight zeros before the first significant digit.

Multiply the two and you have the fee. Everything below is about which of the two a given setting touches, and what happens to the part you authorised but did not use.

Where the Money Goes: Burned, Tipped or Returned

The price per unit is itself two components with different destinations, which is why a single total obscures more than it reveals.

The protocol sets the base fee; the sender does not. Paying it is a condition of validity, and on inclusion it is destroyed. Nobody collects it: it leaves circulation.

The priority fee is the part the sender chooses. It goes to the validator that includes the transaction, and it is the only part anyone competes for. A transaction offering the base fee alone is valid but gives a validator no reason to prefer it over any other.

The official worked example makes the split concrete. A transfer consuming 21,000 units at a base fee of 10 gwei with a 2 gwei tip costs 252,000 gwei in total, of which 42,000 gwei reaches the validator and 210,000 gwei is destroyed.

Read the third column and the asymmetry appears. Two of those fields can hand money back, one sends it to a person, and one sends it nowhere at all.

The Gas Limit Is a Ceiling on Work, Not on Cost

The most common misreading is that the gas limit caps spending. It does not. It caps units of computation, and the difference matters in both directions.

Set a limit of 50,000 on a transfer that needs 21,000 and the network consumes 21,000. The remaining 29,000 units are never charged, because they were never used. Authorising headroom is free.

Set a limit of 20,000 on that same transfer and it does not go through at a discount. It is rejected during validation, before entering a block, and no gas is consumed at all.

Contract interactions are where the limit stops being a formality, because the work required is not fixed in advance and can depend on the state of the contract at the moment of execution.

Three Ways a Transaction Fails, and Who Pays for Each

Failure is not one outcome with one bill. Three distinct things can go wrong, and the cost differs in each.

The first is a limit set below the intrinsic requirement. The transaction never runs, is rejected at validation, and costs nothing. This is the only free failure.

The second is exhausting the gas during execution. A contract call consumes everything authorised before finishing, so the network reverts every state change it made and keeps the entire amount supplied. Nothing happened, and the full fee is gone.

The third is a transaction that executes and reverts for its own reasons, such as a condition inside the contract not being met. The computation was performed, so it is paid for.

The rule underneath all three is that the fee buys attempted computation, not a delivered outcome.
That is also the answer to why a failed transfer leaves a charge behind with nothing to show for it.

The Max Fee Cap Does Not Make You Pay More

A wallet may also expose a maximum fee per unit, and the natural reading is that a higher number means a higher bill. It is the opposite kind of field.

The max fee is a ceiling on what the sender will pay per unit. For the transaction to execute it has to exceed the base fee plus the tip at the moment of inclusion.

What is owed is that sum, not the ceiling. The difference between the two is refunded, which means the ceiling decides whether the transaction stays valid as conditions move, not what it costs.

The practical consequence is another asymmetry. A ceiling set too low leaves a transaction waiting or unexecuted when the base fee rises; a ceiling set generously above the likely cost comes back. The two errors do not carry the same penalty.

Why the Next Block Costs at Most 12.5 Per Cent More

The base fee is not quoted by anyone. It is computed from the blocks already produced, which is what makes part of the cost predictable rather than a matter of guesswork.

Each block has a target size equal to half the gas limit. A block coming in above target raises the base fee for the next one, a block below target lowers it, and the adjustment is proportional to the distance from target.

That adjustment is bounded. It runs from minus 12.5 per cent for an empty block to plus 12.5 per cent for one at the limit, so a single block can never double the base fee.

For anyone about to transact, that bound is arithmetic rather than forecast. Whatever the base fee is now, the next block cannot demand more than that figure multiplied by 1.125. The tip is not bounded the same way, because it is a bid among senders rather than a protocol output.

Current values are read from a block explorer at the moment of sending, not from an article. Any figure printed here would be stale within minutes, which is the same problem that makes withdrawals that cost gas impossible to price in advance.

Who Should Not Be Setting These Fields by Hand

Most wallets set a recommended base fee and tip automatically, and for most people that is the right default rather than a limitation.

Hand-setting pays off in a narrow set of cases: interacting with an unfamiliar contract where consumption is uncertain, transacting when the network is volatile enough that a low ceiling would strand the transaction, or automating transactions the defaults were never designed for.

Outside those cases the risk runs the other way. A limit lowered to save money cannot save money, because unused gas was never charged, and it can cost the whole fee by triggering a revert.

The alternative worth naming is not adjusting these fields more carefully but avoiding them. An account at a custodian never shows them, since holding crypto at an exchange instead means the provider settles internally and charges its own schedule. That is a different trade-off, not a cheaper one.

Two related points sit outside fees but inside the same decision. On-chain costs are part of why how a supply figure is counted is a matter of protocol records rather than reporting, and this fee market is the successor to how blocks are produced under proof of work.

Frequently Asked Questions