The Ethereum block gas limit describes the maximum gas allowed in one block. A transaction gas limit describes the maximum gas its sender is willing to consume on one transaction. Gas used describes consumption. Keeping these three quantities separate makes capacity discussions easier to follow.
The distinction also helps when reading technical records: a maximum, a measured amount, and a price answer different questions. This guide explains those relationships without quoting a current block capacity or predicting transaction prices.
Three gas quantities, three different questions
Gas measures the computational effort required to execute operations on Ethereum. Think of the following questions as labels to attach to every gas number you encounter:
- Transaction gas limit: What is the sender’s maximum gas bound for this transaction?
- Transaction gas used: How much gas did this particular transaction use?
- Block gas limit: What is the maximum gas allowed across this block?
A transaction’s bound is not a promise that it will consume that amount or execute successfully. Ethereum’s gas documentation includes a simple-transfer example where consumption is below the transaction limit. That demonstrates the possibility of lower consumption; it does not establish a universal amount for other transactions.
Block consumption adds another view of the same distinction. A block has its own maximum and its own total gas used. The total concerns all transactions in that block, whereas a transaction’s consumption concerns that transaction alone.
Block capacity is a ceiling; the target is separate
The block gas limit is an upper bound. The documented gas target is half the current block gas limit. These are distinct reference points: the target does not require every block to use exactly that amount, and the maximum should not be relabeled as the target.
For example, when an explanation says a block is below its limit, that statement compares consumption with the ceiling. It does not, by itself, tell you whether consumption is above or below the separate target. To answer that second question, the comparison needs the target as well.
The block gas limit can change over time through validator signaling and network upgrades. Consequently, a capacity number belongs with the block or period it describes. This article gives no current numeric capacity and makes no prediction about when capacity might change.
There is also a distinction between network parameters and sender controls. A sender specifies a transaction-specific gas bound. The block has a separate maximum. From those definitions and the documented mechanisms for block-limit changes, we can deduce that changing a transaction’s limit does not itself change block capacity.
Why a gas limit is not a gas price
A gas limit answers a quantity question. A price per gas answers a monetary-cost question. The execution gas fee combines consumption with cost per unit: gas used multiplied by the price of each gas unit. This describes the execution gas fee, without claiming to inventory every possible transaction charge.
The distinction follows from the units involved. A maximum measured in gas and a price measured in money per gas cannot be read as interchangeable values. This is a deduction from their definitions, rather than a claim that capacity and prices are economically unrelated.
The JSON-RPC method eth_gasPrice, for instance, returns an estimate of the current price per gas in wei. Its result is a price estimate, not a block capacity reading or a guaranteed future execution price.
For the separate question of how an execution fee differs from the amount being transferred, see our explanation of Ethereum gas fees versus transfer amounts. Here, the focus remains on distinguishing capacity, transaction bounds, and consumption.
A hypothetical comparison with explicit boundaries
Imagine an invented classroom block with a limit of 1,000,000 gas. Stipulate that it contains only two transactions, both already executed:
- Transaction A has a transaction gas limit of 100,000 and uses 60,000 gas.
- Transaction B has a transaction gas limit of 120,000 and uses 90,000 gas.
These are fictional inputs, not live Ethereum measurements or suggested transaction settings. Lower consumption than the transaction bound is consistent with the possibility demonstrated in the documentation.
Because block gas used totals the consumption of its transactions, the stipulated block uses 150,000 gas: 60,000 plus 90,000. That total is below its invented 1,000,000-gas limit. This conclusion is arithmetic derived from the assumptions and the block-field definitions.
The comparison deliberately stops at consumption versus capacity. It does not predict inclusion. Eligibility also requires the offered price per gas to be at least the block’s base fee. A capacity comparison contains no offered price, so it cannot establish that separate condition. Meeting that necessary price condition is not an inclusion guarantee either.
Likewise, this exercise supplies no complete block-construction algorithm. It should not be expanded into a rule that adding transaction gas limits alone decides which transactions will be included.
Read gas fields in their object context
Ethereum’s JSON-RPC documentation distinguishes the relevant fields. In a block object, gasLimit is the maximum gas allowed, while gasUsed is total gas used by all transactions in that block. In a transaction receipt, gasUsed concerns that specific transaction alone.
The surrounding object therefore matters as much as the field name. Label a copied value as block consumption or transaction consumption before comparing it with a limit. Otherwise, two values sharing the name gasUsed can appear to answer the same question when they describe different scopes.
A checklist for reading capacity explanations
- Identify the object. Is the number attached to a transaction, its receipt, or a block?
- Identify the role. Is it a maximum, actual consumption, the target, or a price per gas?
- Preserve the block context. Treat block capacity as a parameter that can change over time.
- Keep deductions bounded. Consumption below a ceiling establishes that comparison, not transaction eligibility or guaranteed inclusion.
- Check invented assumptions. A hypothetical example should identify its capacity, transaction inventory, and consumption explicitly.
The conceptual definitions and target distinction come from Ethereum’s gas and fees documentation. Together with the API field descriptions, they support reading the quantities separately; they do not turn a simplified example into a complete inclusion model.
This educational article was prepared with AI assistance. Its fictional example illustrates technical definitions and is not financial advice or a recommendation to submit a transaction.