What is a gas fee?

A gas fee is the amount paid for the network resources consumed by an operation on a blockchain that uses gas accounting. Gas is the accounting unit; the fee is the monetary cost. On Ethereum, gas measures work performed by the Ethereum Virtual Machine (EVM), and execution fees are paid in ETH. Other networks may use different units, fee markets or payment assets, so “gas fee” is not a universal formula for every blockchain.

Gas accounting serves two related purposes. It assigns a cost to computation and data, and it puts a limit on how much work one transaction can ask nodes to perform. This helps allocate limited block space and prevents an execution from running indefinitely. Ethereum’s official gas documentation describes gas as a measure of computational effort rather than a token or a separate balance.

What consumes gas on Ethereum?

An Ethereum transaction has an intrinsic gas cost before contract code runs. That cost reflects the transaction itself, including its data, and contract creation costs more than a basic call. During execution, EVM instructions consume additional gas according to the protocol’s gas schedule. Storage writes, contract calls and other state-dependent operations may therefore use different amounts of gas.

This is why the amount of ETH or tokens transferred does not by itself determine the fee. A small-value interaction with a contract can use more gas than a larger basic ETH transfer. The exact path taken by contract code can also change the final gas used, so an estimate is not a promise of the final result.

Gas limit, gas used and block gas limit

Three similar terms describe different constraints:

• Transaction gas limit is the maximum gas the sender permits the transaction to consume. It is a safety and execution bound, not the amount automatically charged.
• Gas used is the chargeable gas recorded after execution and the applicable refund accounting. It is the quantity multiplied by the effective gas price to calculate the execution fee.
• Block gas limit caps the total gas that transactions in a block can use. It is a network-level constraint, not an individual transaction’s fee setting.

If a transaction’s gas limit is higher than the gas ultimately needed, the unused portion is not charged as if it had been consumed. If the limit is too low for the execution path, however, execution can run out of gas and fail. Ethereum transaction fields and fee fields are summarized in the official transactions documentation.

For an ordinary Ethereum execution transaction, the central relationship is:

Execution fee = chargeable gas used × effective gas price

This equation describes the execution-gas component. It does not necessarily describe every fee associated with a layer-2 transaction, a platform withdrawal or a transaction type with a separate fee market.

How EIP-1559 sets the effective gas price

For an EIP-1559 transaction, the sender specifies two per-gas caps:

• Max priority fee per gas (maxPriorityFeePerGas) caps the tip offered to the block proposer.
• Max fee per gas (maxFeePerGas) caps the combined base fee and priority fee the sender is willing to pay per gas.

Every Ethereum execution block has a base fee set by the protocol. It changes in response to how much gas earlier blocks used relative to the protocol’s target, and the base-fee portion paid by a transaction is burned. A transaction’s priority-fee portion is credited to the block proposer. These mechanics are specified in EIP-1559.

The effective priority fee is constrained by both user-defined caps:

Effective priority fee = min(max priority fee, max fee − block base fee)

Effective gas price = block base fee + effective priority fee

The max fee is therefore a ceiling, not a quotation of what will be charged. If the max fee cannot cover the block’s base fee, the transaction is not eligible for inclusion in that block. A larger cap may allow the transaction to remain valid if the base fee rises, but it does not by itself make the full cap payable. It also cannot guarantee when a validator will include the transaction.

Older transaction formats use one gasPrice field instead of the two EIP-1559 caps. In either format, the useful distinction for a reader is between the maximum price authorized and the effective price charged for an included transaction.

Reading a fee calculation

Suppose an EIP-1559 transaction has these hypothetical values:

• Transaction gas limit: 80,000 gas
• Chargeable gas used: 50,000 gas
• Block base fee: 20 gwei per gas
• Max priority fee: 3 gwei per gas
• Max fee: 22 gwei per gas

The max fee leaves only 2 gwei above the base fee, so the effective priority fee is min(3, 22 − 20) = 2 gwei. The effective gas price is 22 gwei and the execution fee is:

50,000 × 22 gwei = 1,100,000 gwei = 0.0011 ETH

The calculation uses 50,000 gas, not the 80,000-gas transaction limit. It also illustrates why the displayed max priority fee is not always the priority fee ultimately paid. These values are only an explanation of the arithmetic, not a live fee estimate or a typical price for a particular operation.

Unused gas, refunds and failed transactions

The word refund is used for two different mechanisms:

1. Unused transaction gas: a gas limit is a maximum. Gas not consumed by execution is not ultimately charged at the effective price. Likewise, the difference between a fee cap and the effective gas price is not an extra fee simply because the sender authorized that cap.
2. EVM execution refunds: certain state changes can add units to an internal refund counter. This reduces chargeable gas after execution; it does not send a separate payment during contract execution or give the contract more gas to continue running.

The second mechanism is deliberately limited. EIP-3529 removed the refund for SELFDESTRUCT, reduced the refund associated with clearing storage and capped the applied refund at one-fifth of gas spent. This protocol-level accounting is mostly relevant to developers; for a general reader, the key point is that unused gas and an EVM refund are not two cash payments sent back by a contract.

A failed transaction may still have a fee because “failed” can describe several outcomes:

“Failed” can describe several technically different outcomes:

• Included and reverted: nodes have already performed work. State changes are rolled back, but gas spent before the revert remains chargeable. Under EIP-140, REVERT does not automatically consume all remaining gas.
• Out of gas: the failing execution context can consume all gas made available to it. A top-level transaction that runs out of gas can consume its full transaction gas limit.
• Rejected before inclusion: no onchain execution occurred, so there is no Ethereum execution fee for an included transaction. An application error message alone does not prove that a network fee was paid.

For an included failed transaction, the receipt and block data—not only the interface message—show the status and gas used. The fee and sender nonce change are part of processing the included transaction even though the reverted contract-state changes do not persist.

Where the Ethereum formula stops applying

Gas is a broad design pattern, but the terms above describe Ethereum’s execution layer. Other chains may use fixed fees, resource credits, multiple fee assets or different auction rules. Even within the Ethereum ecosystem, a layer-2 fee may combine local execution with the cost of publishing data to Ethereum. EIP-4844 also defines blob gas as independent of normal execution gas, with its own fee accounting.

A centralized platform’s withdrawal fee is another distinct concept: it may reflect a platform’s fee policy and batching practices rather than equal the network fee for one onchain transaction. These amounts should not be used interchangeably without checking what the interface actually labels.

FAQ

Is gas a separate coin?

No. On Ethereum, gas is a resource-accounting unit and the execution fee is denominated in ETH. Another network may use its own native asset or a different payment mechanism.

Does setting a higher gas limit make a transaction more expensive?

Not by itself. The fee is based on chargeable gas used, not automatically on the entire limit. A higher limit does, however, authorize more execution and increases the transaction’s maximum possible gas exposure.

Does a higher max fee guarantee faster confirmation?

No. The max fee is a cap and must be high enough to cover the base fee. Inclusion also depends on the effective priority fee, available block space, validator selection and changing network conditions.

Related concepts

For a longer Ethereum-focused explanation, read Ethereum gas fees explained.

Explore blockchain addresses and crypto wallets, or return to the Crypto Glossary.

Sources

• Ethereum.org: Gas and fees — gas units, fee components, base fees and failed transactions.
• Ethereum.org: Transactions — transaction gas and EIP-1559 fee fields.
• EIP-1559: Fee market change for ETH 1.0 chain — base-fee, fee-cap and effective-price rules.
• EIP-140: REVERT instruction — state rollback and remaining-gas behavior for REVERT.
• EIP-3529: Reduction in refunds — current limits on execution refund accounting.
• EIP-4844: Shard Blob Transactions — separate blob-gas accounting and fee market.