Transaction Fees

Every transaction on Ethereum and EVM-compatible blockchains incurs a fee measured in gas, which represents computational effort. Blockchain users pay a fee per unit of gas in the blockchain's native token to compensate validators for processing and storage. Gas fees help prevent spam and allocate limited block space and processing power to the highest bidders. Gas is typically measured in Gwei (Giga Wei, or 10⁹ Wei).

This guide provides background on Ethereum transaction types, how gas fees work, and which EVM compatible chains they are supported by.

• 0x0: Legacy Transactions
• 0x1: Access List Transactions
• 0x2: Dynamic Fee Transactions
  • EIP-1559 Fee Scenarios
• 0x3: Blob Transactions
  • EIP-4844 Fee Scenarios
• 0x4: Execution Delegation Transactions
• Gas Fee Estimation
• EVM-compatible chains support
• Fixed-Fee Model

0x0: Legacy Transactions

Fee Model: fixed gas price

This bidding method is called "first-price-auction". Legacy transactions are still supported on Ethereum, however EIP-1559 transactions are more gas-efficient.

Parameter	Source	Definition
gas price	user	Total amount to be paid to the validator. Any excess of the base fee will be paid to the validator as a priority fee (see dynamic fee transactions).
base fee	network	Variable fee adjusted block-by-block based on how full the previous block was.

0x1: Access List Transactions

Introduced: EIP-2930, Berlin upgrade

Fee Model: fixed gas price - the same fee structure as legacy transactions.

Access lists reduce gas costs by allowing transactions to predeclare which contract addresses and storage slots they will access. Because the node knows these accesses in advance, it can pre-warm the required state and avoid higher cold-access gas penalties. While a transaction can include unrelated access-list entries, each entry has an upfront gas cost and unused entries provide no benefit, making abuse economically ineffective.

0x2: Dynamic Fee Transactions

Introduced: EIP-1559, London upgrade

Fee Model: dynamic fee model using max fee and max priority fee

For more in-depth information about EIP-1559 transactions, read this cheatsheet for implementers.

Parameter	Source	Definition
max fee	user	Maximum total fee (base fee + priority) the user is willing to pay. If the base fee + effective priority fee is less than this amount, the difference is refunded to the user (see example).
max priority fee	user	Maximum fee paid to validators to prioritize including the user's transaction in the next block.
base fee	network	Variable fee adjusted block-by-block based on the previous block demand. This fee is burned.

EIP-1559 Fee Scenarios

Base Case

When submitting a transaction, users specify a max fee (the maximum total fee per unit of gas) and a max priority fee (the maximum tip they are willing to pay the validator). The network sets the base fee for the block, and the validator receives a priority fee on top of that base. The actual (effective) priority fee paid may be lower than the max priority fee so that the total fee does not exceed the user's max fee.

Refund When Base Fee Is Low

When users set both a max fee and a max priority fee, they may receive a refund if the actual base fee is low enough. In this example, the base fee is 40 Gwei and the effective priority fee is capped at the max priority fee of 40 Gwei, for a total paid fee of 80 Gwei. Since the user’s max fee is 100 Gwei, the remaining 20 Gwei is refunded.

Setting Equal Max Fees

If a user sets the max fee and max priority fee to the same value, the transaction will pay the full max fee as long as it exceeds the base fee. Here, the base fee is 40 Gwei and the remaining 60 Gwei is applied as the effective priority fee, resulting in a total fee of 100 Gwei with no refund.

Legacy Transactions in the EIP-1559 System

Legacy transactions that specify a single gas price continue to work under EIP-1559. Any portion of the gas price that exceeds the base fee is treated as a priority fee paid to the validator, making legacy transactions behave equivalently to setting equal max fee and max priority fee values.

0x3: Blob Transactions

Introduced: EIP 4844 (proto-danksharding), Dencun upgrade

Fee Model: Adds separate “blob gas” market separate from EVM gas

Blob transactions support cheaper, ephemeral data availability for Layer 2 (L2) rollups. The blob fee market operates separately from the traditional EIP-1559 fee market and uses a dedicated fee type called blob gas.

Parameter	Source	Definition
blob max fee	user	Maximum blob fee the user is willing to pay per unit of blob gas. If the base blob fee is less than this amount, the difference is refunded to the user. Blob gas has no priority fee.
blob base fee	network	Variable fee adjusted block-by-block based on blob demand.

EIP-4844 Fee Scenarios

Base Case

As in EIP-1559 fee scenarios, users specify a max fee and a max priority fee for the transaction's execution. The network sets the execution base fee, and the validator receives an effective priority fee on top of that base, capped so the total execution fee does not exceed the user's max fee.

Blob fees are handled separately from execution fees, and users also specify a blob max fee, the network sets a blob base fee, and any unused portion of the blob max fee is refunded. Unlike execution gas, blob gas does not include a priority fee.

Refund When Base Fee Is Low

In this example, the execution base fee is 40 Gwei and the effective priority fee is capped at the max priority fee of 40 Gwei, for a total execution fee of 80 Gwei. Because the user's max fee is 100 Gwei, the remaining 20 Gwei is refunded.

For blob data, the network sets a blob base fee of 30 Gwei. Since the user's blob max fee is 40 Gwei, the remaining 10 Gwei is refunded to the user.

0x4: Execution Delegation Transactions

Introduced: EIP-7702, Pectra upgrade

Fee Model: dynamic fee model, same as EIP-1559

Allows externally owned accounts (EOAs) to temporarily include smart contract code for execution. An authorization list specifies which code is permitted to execute on behalf of the EOA. This is an evolution of Account Abstraction from the earlier ERC-4337 standard.

Gas Fee Estimation

Users compete to have their transaction included in the next block, through gas price auctions (legacy) or priority fees (EIP-1559). Gas price oracles (GPOs) are often used by wallets to predict what fee will be most effective and efficient. The simplest implementation queries a blockchain node to return a suggested gas price.

The go-ethereum Node Oracle

When a wallet makes a request to a go-ethereum node for a suggested priority fee (or gas price for legacy transactions), by default the node will return the 60th percentile of all the transactions fees paid in the most recent 20 blocks (ignoring fees below 2 Wei). See the default GPO CLI parameters of go-ethereum below:

   GAS PRICE ORACLE

    --gpo.blocks value             (default: 20)
          Number of recent blocks to check for gas prices

    --gpo.ignoreprice value        (default: 2)
          Gas price below which gpo will ignore transactions

    --gpo.maxprice value           (default: 500000000000)
          Maximum transaction priority fee (or gas price before London fork) to be
          recommended by gpo

    --gpo.percentile value         (default: 60)
          Suggested gas price is the given percentile of a set of recent transaction gas
          prices

MetaMask Gas Oracle API

Some wallets, like MetaMask, use a custom API to suggest a gas price. On supported networks, in addition to the current base fee retrieved by a node, Metamask provides the following additional information:

• time estimates
• low/medium/high base
• priority fee suggestions
• historic base fee range

On unsupported networks, MetaMask will default to ask the node (see previous section). The current MetaMask gas price API can be found at https://gas-api.metaswap.codefi.network/networks/{ChainID}/suggestedGasFees. Modify ChainID to query your selected network, ie 1 for Ethereum Mainnet (for the ChainID of popular networks, see chainlist.org).

Transaction Re-submission

Mechanism

Pending transactions can be replaced by submitting another transaction with the same nonce and a higher gas fee. While this varies by network, the replacement fee typically needs to be at least 10% higher than the original.

This mechanism enables three key operations:

• Speed up: increase transaction priority by resubmitting with identical nonce, payload, and value but higher gas fee
• Replace: substitute a pending transaction by using the same nonce and higher gas fee with different payload or value
• Cancel: remove a pending transaction by sending a no-op transaction (empty payload and zero value) using the same nonce and higher gas fee

EVM-compatible chains support

Overview of transaction types supported by popular EVM-compatible blockchains (e.g., 0x0 legacy, 0x1 EIP-2930, 0x2 EIP-1559, 0x3 EIP-4844, 0x4 EIP-7702) along with links to official gas and fee documentation.

Chain Name	0x0	0x1	0x2	0x3	0x4	Chain Fee Docs
Arbitrum One	✅	✅	✅		✅	Gas & fees, EVM differences from Ethereum
Avalanche C	✅	✅	✅		✅	Gas & fees
Base	✅	✅	✅		✅	Gas & fees, EVM differences from Ethereum
BNB	✅	✅	✅	✅	✅	Gas & fees
Celo	✅	✅	✅		✅	Transactions, Gas & fees
Curvegrid Testnet	✅	✅	✅	✅
Ethereum	✅	✅	✅	✅	✅	0x1: EIP-2930, 0x2: EIP-1559, 0x3: EIP-4844, 0x4: EIP-7702
Filecoin	✅	✅	✅			Docs home
Flare	✅	✅	✅		✅	Transactions
Gnosis	✅	✅	✅	✅	✅	Gas & fees, EIP-7702 Guide
Lisk	✅	✅	✅			Gas & fees, EVM differences from Ethereum
Mantle	✅	✅	✅			Gas & fees, Relevant FAQs
NEON EVM	✅	✅				Gas & fees, EVM differences from Ethereum
OP	✅	✅	✅		✅	Gas & fees, EVM differences from Ethereum
Polygon	✅	✅	✅		✅	Transactions
Scroll	✅	✅	✅		✅	Transactions, EVM differences from Ethereum
XRPL EVM	✅		✅			Docs home
Zircuit	✅	✅	✅		✅	Transactions, Gas & fees

Notes

• Custom transaction types: Some chains define transaction types beyond 0x00 to 0x04. For example, OP Stack used transaction type 0x7e for its "deposit/system" transactions.
• Polygon tip floor: On Polygon, transactions with a max priority fee less than 30 Gwei may be dropped.

Fixed-Fee Model

• Layer 1 (L1): A blockchain network with its own consensus mechanism (e.g., Proof of Work, Proof of Stake) that has its own native validators or miners securing the network. All Layer 2 transactions ultimately rely on an L1 for settlement and security guarantees.

• Layer 2 (L2): A network built on top of an L1 that increases throughput and reduces costs by executing transactions off-chain and batching results back to the L1. L2s inherit the security of the L1 while providing faster and cheaper execution.

Many L2 networks, including Arbitrum and Optimism, operate with a minimum gas price model for transaction execution. Under normal network conditions, transactions are generally processed on a first-come, first-served basis, and users pay the minimum gas price multiplied by the transaction's gas usage, similar in effect to a base fee in EIP-1559.

In addition to execution fees, L2s charge a separate L1 data fee to publish transaction data to the underlying L1. This fee is calculated automatically by the L2 and deducted from the user at execution time.

Parameter	Source	Definition
min gas price	network	The minimum fee required to execute the transaction at the current time.