Skip to content
Financial Context Wiki

Block gas limit

A fork-aware guide to Ethereum block gas limit, EIP-1559 target, transaction gas cap, gas used, fee accounting, throughput estimates and node-resource tradeoffs.

Updated

For educational purposes only; not financial or security advice. Gas limits, targets, schedules, transaction caps, opcode costs and client policies vary by chain, fork and observation time.

Direct answer

The block gas limit is the execution-gas ceiling recorded in an Ethereum block header. Transactions included in the block must fit the protocol’s accounting rules so that aggregate gasUsed does not exceed gasLimit. Gas is an abstract metering unit whose opcode, calldata, memory, storage and refund rules change across forks; it is not a direct count of CPU instructions, bytes or transactions.

On Ethereum mainnet after Fusaka, the coordinated client baseline is 60,000,000 gas per block, while the actual header remains authoritative and validator preferences can move the limit gradually under the current parent-relative rule. Under EIP-1559’s elasticity multiplier of 2, the long-run target is 30,000,000 gas; blocks may temporarily use up to the limit, and the next base fee rises when parent usage exceeds target. EIP-7825 separately caps a user transaction’s declared gas limit at 2^24 = 16,777,216 gas, while EIP-7934 imposes an independent 8,388,608 bytes RLP execution-block limit. These values are mainnet and date specific, not universal EVM constants.

How it works

  1. Pin the chain, network, block hash and number, active fork, client or RPC and observation time. Read the block header’s gasLimit, gasUsed and baseFeePerGas; do not substitute a website’s static parameter table.
  2. Separate block gas limit, EIP-1559 gas target, transaction-declared gas limit, transaction actual gas used and price per gas. Also separate execution gas from blob gas, RLP execution-block bytes and any L2-specific metering.
  3. Reproduce transaction validity and execution under the active gas schedule. Include intrinsic gas, calldata, access lists, memory expansion, cold and warm access, storage writes, precompiles and refunds. An estimate is state- and block-tag-dependent, not a guarantee.
  4. Reconcile block capacity. Sum receipt gas usage or use the final receipt’s cumulative value, confirm gasUsed <= gasLimit, and account for transaction ordering and state-dependent costs. Transaction count equals neither gas limit nor a fixed TPS.
  5. Apply EIP-1559 correctly. With elasticity 2, target is gasLimit / 2; parent use above target raises the next base fee and use below target lowers it. Under the current rule, a child block’s limit must also stay within the strict parent-relative band of approximately 1/1024. The base fee prices demand, while the limit constrains accepted execution work.
  6. Check operational boundaries. A transaction exceeding the active per-transaction cap is invalid even if the block has gas space, and an oversized RLP execution block is invalid even when aggregate gas remains below limit. Unused transaction gas allowance is released; the refund counter is a separate fork-capped reduction. REVERT preserves remaining gas, while top-level out-of-gas reverts state and consumes the full supplied execution allowance.
  7. Stress and monitor full-block execution time, state growth, block propagation, missed slots, reorganization behavior, builder and validator capacity, client diversity and parameter changes. Compare actual blocks and node metrics before treating a higher limit as sustainable throughput.

Worked examples

  • Simple-transfer ceiling. At 60,000,000 gas, a block could theoretically fit floor(60,000,000 / 21,000) = 2,857 plain ETH transfers. The 30,000,000 gas target fits 1,428; over an idealized 12-second slot that is 1,428 / 12 = 119 transactions/second. This is a homogeneous upper-bound illustration, not observed TPS.
  • Mixed target block. Suppose a target block has 400 * 21,000 = 8,400,000 gas of transfers, 80 * 180,000 = 14,400,000 gas of swaps and 6 * 1,200,000 = 7,200,000 gas of deployments. Total use is 30,000,000 gas across 486 transactions, or 486 / 12 = 40.5 transactions/second under the stated slot assumption. The same gas target supports very different transaction counts.
  • Transaction limit versus actual charge. A transaction declares 200,000 gas but succeeds with gasUsed = 146,000. At an effective price of 22 gwei, the fee is 146,000 * 22 = 3,212,000 gwei = 0.003212 ETH; the unused 54,000 gas is not charged. By contrast, a declaration of 18,000,000 gas exceeds the current 16,777,216 gas protocol cap and is invalid regardless of spare block capacity.
  • Base-fee response. With gasLimit = 60,000,000, target is 30,000,000. Starting from 24 gwei, a parent block at the full 60,000,000 gas moves the next base fee up by the maximum 12.5% to 27 gwei; an empty parent moves it down by 12.5% to 21 gwei. This does not change the block limit or guarantee the next block’s utilization.

Risks

  • Using a stale mainnet gas-limit value.
  • Applying Ethereum parameters to another EVM chain or L2.
  • Confusing block limit with EIP-1559 target.
  • Confusing block limit with the per-transaction cap.
  • Confusing declared transaction gas with actual gas used.
  • Treating gas as a fixed CPU, byte or transaction unit.
  • Using an obsolete opcode, calldata or refund schedule, or ignoring the independent RLP block-size cap.
  • Relying on eth_estimateGas without the intended state and block tag.
  • Ignoring state-dependent execution and transaction ordering.
  • Confusing unused transaction allowance with the separate refund counter.
  • Ignoring charged gas when execution runs out of gas or reverts.
  • Treating execution gas and blob gas as one resource.
  • Deriving TPS from homogeneous transfers alone.
  • Ignoring missed slots, reorgs and finality delays.
  • Increasing worst-case block execution and propagation time.
  • Accelerating state growth and archive requirements.
  • Raising validator, builder and RPC hardware requirements.
  • Increasing centralization or client-divergence risk.
  • Missing validator preference, client-default or fork changes.
  • Treating higher capacity as guaranteed lower fees or demand.

Common misconceptions

  • The block gas limit is a fixed universal Ethereum or EVM constant.
  • A 60,000,000 gas limit means every block should use 60 million gas or that the EIP-1559 target is also 60 million.
  • Dividing the block limit by 21,000 gives the chain’s real TPS.
  • A transaction may consume the whole block as long as its block has room; the current per-transaction cap is independent.
  • Raising the gas limit automatically lowers fees without node, state, propagation, demand or centralization tradeoffs.

Sources

Navigation

Search the wiki...