Skip to content
Financial Context Wiki

Gas and Transaction Fees

A fork-aware guide to gas units, intrinsic and execution costs, EIP-1559 fee caps, base-fee burn, priority fees, reverts, out-of-gas, refunds, blob gas and L2 fee components.

Updated

For educational purposes only; not investment or transaction advice. Fees depend on the exact chain, fork, transaction type, execution path, state, fee markets, sequencer or builder policy and inclusion time.

Direct answer

Gas is the protocol accounting unit for execution work and state access; a gas fee is a monetary charge computed from charged gas units and a price per unit. On EIP-1559 Ethereum, effectiveGasPrice = min(maxFeePerGas, baseFeePerGas + maxPriorityFeePerGas), execution fee is gasUsed * effectiveGasPrice, the base-fee portion is burned, and the priority portion is paid through the block’s fee-recipient path. Gas limit and fee caps authorize maxima; they are not amounts automatically spent.

The exact gas used depends on calldata, opcode path, memory expansion, cold and warm state access, storage changes, nested calls, precompiles, success or failure, refunds and the active fork. A higher price can improve inclusion competitiveness but cannot fix a revert, insufficient gas limit, malicious contract, stale quote or bad calldata. Blob transactions and many L2s add separate data or protocol fee components that must not be folded into EVM gas by assumption.

Network fee
0.000462 native
Fiat equivalent
$1.39
Base fee
22 gwei

Outputs are educational approximations. They exclude venue rules, taxes, latency, oracle behavior, and other protocol-specific parameters unless shown.

How it works

  1. Pin chain, fork, block or state tag, transaction type, sender, nonce, destination, value, calldata, access list, blob fields, gas token and fee currency. Record whether the quote concerns an L1 transaction, an L2 execution, data publication, withdrawal or a composed route.
  2. Reconstruct intrinsic gas before execution: transaction envelope, calldata byte costs, creation and access-list charges, and type-specific overhead. If gas limit is below intrinsic gas or the sender cannot satisfy the protocol’s maximum-cost validity checks, the transaction is rejected before included execution rather than included and reverted.
  3. Trace execution under the target fork. Measure opcode dynamic costs, memory expansion, cold and warm accounts or storage slots, SSTORE, call forwarding, value transfer, precompile charges, logs and refunds. The same ABI function can follow different branches and use different gas under different state.
  4. Separate outcomes. Successful execution commits its effects. REVERT rolls back the failed scope and may return unused frame gas; an out-of-gas exceptional halt normally consumes the gas made available to that frame. An included top-level failure still consumes the transaction nonce and charged gas even though its contract state, value transfer and logs roll back.
  5. Price execution gas. For a type-2 transaction, compute effective gas price from the base fee, priority cap and total cap; then split charged gas into burned base fee and priority fee. Distinguish unused gas and unspent fee-cap headroom from protocol gas refunds created by eligible state cleanup and limited by the active refund cap.
  6. Price other fee markets separately. A blob transaction pays execution gas plus blobGasUsed * blobGasPrice subject to maxFeePerBlobGas; blob base fee has its own adjustment path. An L2 user fee can include L2 execution, compressed L1 data or blob cost, operator or protocol charges and margins, with formulas and scalar parameters specific to that deployment and upgrade.
  7. Reconcile estimate, inclusion and receipt. Before signing, verify balance against value plus maximum authorized fees, simulate at a pinned state and set bounded fee caps. After inclusion, record gas limit, receipt gas used, effective price, base fee, priority fee, refund effects, blob gas, L2 fee fields, status and balance delta; treat estimation error, replacement and finality separately.

Worked examples

  • Type-2 success and caps. Gas limit is 120,000, gas used is 70,000, base fee is 25 gwei, max priority fee is 3 gwei, and max fee is 40 gwei. Effective price is min(40, 25 + 3) = 28 gwei; actual fee is 70,000 * 28 gwei = 0.001960 ETH, split into 0.001750 ETH burned and 0.000210 ETH priority fee. Maximum execution-fee authorization is 120,000 * 40 gwei = 0.004800 ETH; the unused 50,000 gas and unspent cap headroom are not protocol cleanup refunds.
  • REVERT versus out-of-gas. Two included calls each have gas limit 100,000 and effective price 30 gwei. Call A executes REVERT after receipt gas used reaches 60,000, so its fee is 60,000 * 30 gwei = 0.001800 ETH. Call B exhausts the entire transaction gas limit, so its fee is 100,000 * 30 gwei = 0.003000 ETH. Both top-level failures roll back contract effects and consume the sender nonce, but REVERT can preserve unused gas while out-of-gas does not.
  • Refund cap. In a fork-scoped EIP-3529 teaching case, execution consumes 100,000 gas before refund and creates a refund counter of 30,000 gas. The maximum applied refund is 100,000 / 5 = 20,000 gas, so charged gas is 100,000 - 20,000 = 80,000 gas. At 20 gwei, the fee is 0.001600 ETH rather than 0.002000 ETH, a saving of 0.000400 ETH; refund rules and eligible operations can change by fork.
  • Separate blob fee market. A hypothetical blob transaction uses 100,000 execution gas at 20 gwei and two blobs. With 131,072 blob gas/blob, blob gas used is 262,144; at a blob gas price of 5 gwei, blob fee is 262,144 * 5 gwei = 0.00131072 ETH. Execution fee is 0.002000 ETH, so combined protocol fee is 0.00331072 ETH. The chosen 5 gwei is an example, and blob fee is not a validator priority tip or an L2 user’s full end-to-end fee.

Risks

  • Using the wrong chain, fork, gas token, transaction type or fee currency.
  • Confusing gas units, wei, gwei, ETH and fiat conversions.
  • Treating gas limit as the expected or actual fee.
  • Failing the intrinsic-gas or maximum-cost pre-validation checks.
  • Relying on a stale estimate after state, base fee or calldata changes.
  • Setting gas limit below the actual branch’s needs.
  • Assuming a higher gas price can prevent contract REVERT.
  • Confusing REVERT, out-of-gas, invalid opcode and pre-validation rejection.
  • Missing a caught child-call failure despite top-level status 1.
  • Mispricing cold and warm state access or an incomplete access list.
  • Ignoring memory expansion, call forwarding, precompile or log costs.
  • Applying obsolete storage-refund rules or exceeding the refund cap.
  • Counting unused gas or fee-cap headroom as a protocol gas refund.
  • Setting max fee below the inclusion block’s base fee.
  • Overpaying priority without understanding builder or sequencer policy.
  • Lacking the native gas token despite holding other assets.
  • Omitting blob gas, blob fee cap or data availability charges.
  • Treating one L2’s execution, data, scalar and operator formula as universal.
  • Ignoring replacement, nonce, dropped-transaction and balance-reservation races.
  • Treating a paid or successful transaction as proof of contract safety or finality.

Common misconceptions

  • Gas is a percentage of the value transferred.
  • Raising gas limit necessarily increases the amount charged.
  • A high max fee or priority fee guarantees successful execution.
  • All unused authorization and state-cleanup refunds are the same mechanism.
  • L2 fees equal only local EVM gas and blob fees are ordinary execution gas.

Sources

Navigation

Search the wiki...