What Is Gas on Ethereum? Two Numbers Multiplied, and One of Them Is Burned.

A transaction on an account-based chain passes through the same stages every time. It is constructed by software, simulated against current state, priced by two separate mechanisms, placed in a queue, selected into a block, executed against the state, and either accepted or reverted. Most networks hide those stages behind a commission. This one publishes a price list for the work, computes one half of the price from a formula that nobody negotiates, and destroys that half on completion. Following a single transaction through all of it is the fastest way to understand what a fee on this network actually is.

The transaction followed below is an ordinary swap on a decentralised exchange, chosen because it contains every stage including the ones that cost money without moving anything. The numbers used are illustrative magnitudes rather than a quote for any particular day, and the rules being applied are the ones in production: a base fee computed per block, a priority fee that competes, and a separate market for data.

Stage one: the transaction is constructed, and the wallet guesses

The first thing that happens is a simulation. A wallet builds the transaction, runs it against the current state of the chain without committing anything, and reads how much work it consumed. That number becomes the gas limit, usually padded upward by a margin, because a transaction that exceeds its limit halts and is still charged for the work it performed. A plain transfer to another account consumes about 21,000 units and has no variance to speak of. Everything else does.

The reason the estimate is a guess rather than a measurement is that the state moves. If another transaction takes the same trading opportunity or changes a pool balance first, the same transaction can consume a different amount of work, or fail entirely, and the wallet learns this only from the receipt. A quote is therefore a prediction about the world at inclusion time, which is one of the few places in payments where a price can change because somebody else acted first.

Two terms are worth fixing before the arithmetic begins. Gas is a unit of work, priced per operation in the protocol: storage writes are expensive, arithmetic is cheap, reading is cheaper than writing. Gas used is the work a transaction actually performs, and it is determined by the code path rather than by the sender. The gas limit is the ceiling the sender authorises, and unused gas is returned, which is why a generous limit is not itself wasteful.

Stage two: the base fee is computed, not negotiated

The second stage has no analogue in a normal payment system. Before the transaction is broadcast, the price per unit of gas for the next block is already determined, and it was determined by the previous block rather than by any party. The protocol holds a target for how full a block should be, measures the block before, and moves the base fee in proportion, with a limit of 12.5 percent in either direction for a single block.

The consequences of a computed price are worth spelling out, because they are unusual. A user cannot pay a lower base fee by being important, and cannot be charged a higher one by a venue. A transaction that offers less than the current base fee is not rejected by a person but simply cannot be included, and it waits until the ebb of activity brings the number down. And because the adjustment is capped at 12.5 percent per block, a spike decays over the following blocks instead of vanishing, which is the mechanic behind the pattern where fees are highest for a few minutes after a popular event and then drift back over an hour.

The same rule explains why the number is rarely zero. A base fee of zero would mean blocks at or below target indefinitely, which a network with any sustained demand for space does not have. What a quiet period produces is a low price rather than no price, and a low price is exactly what makes a transaction cheap at three in the morning and expensive at three in the afternoon.

Stage three: the tip is the only part that bids

The second half of the price is discretionary. The priority fee is what a sender adds on top of the base fee to be chosen sooner when there are more valid transactions than space, and it is the only part of the cost that behaves like a market. On a block that is not full, a minimal tip is enough and the total cost is essentially the base fee. On a contended block, the tip is the whole story and it is being set by everyone transacting at that moment.

The split has a structural consequence that is easy to miss. Because the base fee is destroyed and cannot be raised by the block producer, the producer’s only lever over its own revenue is which transactions to include and in what order. The tip is therefore not a toll charged by an operator but a bid for position, and it rises with the value of being early rather than with the cost of the service. That distinction is why tips can spike far above the base fee during liquidations and arbitrage, when being first is worth more than the fee itself.

Stage four: the queue, and what waiting costs

A broadcast transaction that is not yet included sits in a queue, and the queue has a rule that differs from a first-in-first-out system: each account has a counter, and a transaction is valid only with the next expected number. That means transactions from one account execute in order, with no gaps, and it means the sender has exactly one lever to move a stuck transaction: send another one with the same counter and a higher fee, which replaces the first.

Replacement is useful and it is also irreversible in the ordinary sense, since the replaced transaction is gone rather than paused. The practical cases where this matters are well known. A payment stuck below the current base fee can be pushed through by replacing it. A transaction that becomes undesirable after broadcast can sometimes be pre-empted the same way. And an account whose counter is blocked by a single underpriced transaction cannot send anything else until that transaction lands or is replaced, which is the fee mechanism’s one true queue-jamming failure mode.

The queue also explains the difference between two failure modes that look identical on a wallet screen. A transaction that is pending forever has been broadcast and is not decaying; it will land when the base fee falls or it will be replaced. A transaction that failed has been included in a block, executed, and reverted, and it cost money without changing anything. Neither is a network error, and the second is the one that surprises people who assume a failed action is free.

Stage five: inclusion, execution, and the receipt

Inclusion is where the arithmetic closes. A block builder selects transactions by fee per unit of work, executes them in an order that respects each account’s counter, and produces a block. Each transaction consumes some amount of gas, is charged at the base fee plus its tip, and either changes the state or reverts. The receipt tells the sender which happened, how much gas was used, and what the effective price was.

Two arithmetic examples fix the scale. A transfer of the native asset on an idle chain consumes about 21,000 gas, and at a base fee of a few gwei the total cost is a fraction of a cent. A swap on a decentralised exchange typically consumes two to four times that, plus a tip that can reach multiples of the base fee when the pool is busy. The difference between the two is not the amount transferred, which is irrelevant to the fee, but the storage a contract writes and the calls it makes.

A parallel stage: data is priced elsewhere

Rollups add a second cost path that does not follow the stages above. Their transaction data does not compete with ordinary transactions for execution space; it is published in blobs, which have their own capacity and their own fee market. A blob transaction pays execution gas to submit a commitment and a separate blob fee for the space the data occupies, and the two prices move independently because they are set by different supply and demand.

That independence is the reason a rollup can be cheap on a day when the base layer is not. The batch shares one data commitment across many transactions, so the marginal cost of the next transaction inside the batch is close to nothing, and the base layer’s congestion is paid once per batch rather than once per action. The trade is that the layer above inherits the base layer’s settlement guarantees and its ultimate capacity limits, which is why the two markets are separate in price and not in security.

Where the money ends up

At the end of the sequence the fee has been divided in two and given to two different places. The base fee is gone, removed from the supply of the token rather than paid to a party. The priority fee is income for whoever assembled the block, alongside the small block reward that the protocol pays for producing it.

The supply effect gets more discussion than the design intent, and the two should be kept apart. Burning the base fee means that total supply can fall during busy periods, because fees removed from circulation can exceed the new tokens issued. That is a consequence rather than a policy: the burn is largest when demand for block space is highest, and it approaches nothing when activity recedes, so the supply responds to congestion rather than following a schedule.

The design intent was narrower. Paying the entire fee to the block producer made inclusion itself a revenue position with discretion attached, and it made the price of inclusion a guess that only the producer could price well. Splitting a computed half from a competitive half removed the discretion and made the estimate something a wallet can perform offline. The burn was the way to do that without leaving the computed half as a new pool of value for somebody to capture.

Where the sequence breaks

The stages above work as described under ordinary conditions, and the interesting behaviour appears when one of them fails.

The pattern across those rows is that the mechanism provides one repair, which is to pay again. There is no cancellation, no adjustment and no negotiation, because pending is not a commitment by the network and inclusion is not reversible. That is a coherent design for a system where the queue is public and the price is public, and it is a hard design for anyone who has used a payment system where a wrong number can be fixed with a phone call.

The stage that is not priced in the receipt

The five stages above describe what a sender experiences. There is a sixth process running underneath them that never appears in a receipt and shapes the price substantially: the market for ordering. A block builder receives far more valid transactions than it can include, and the order it chooses affects the outcome of each one, because transactions in the same block can change the state the next transaction sees. A liquidation is profitable only if it lands before a competing one, and an arbitrage exists only until somebody else takes it.

That value is not hypothetical and it has its own supply chain. Searchers construct bundles of transactions that profit only if executed in a specific order, builders assemble blocks from those bundles plus ordinary traffic, and relayers pass bundles between the two. The consequence for a user is that the priority fee is not only a congestion price. During a liquidation cascade or a popular mint, being early is worth more than the fee, and tips can jump to multiples of the base fee while the base fee itself is still adjusting at 12.5 percent per block.

The practical reading is that two different markets set the cost of a transaction. The base fee prices block space and moves slowly by protocol rule. The tip prices position and moves instantly by competition, including competition from participants whose transactions are worth far more than the average user’s. A wallet that displays a single-number fee is adding the two together, and the ceiling on that number is not the protocol but the profitability of whoever else is transacting in the same block.

The same sequence on a rollup, stage by stage

Run the five stages again on a rollup and one of them disappears, which is the whole reason rollups are cheap. There is no separate data stage competing with user transactions, because data is submitted to the base layer in batches. The stages become shorter and the arithmetic changes shape.

Two properties follow from that table and explain most of what users notice. The first is that a rollup’s fee does not track base-layer execution fees, because the resource it buys is data rather than computation, and data space has its own market and its own price movement. The second is that a rollup does not remove the base layer from the calculation; it moves it to a batch boundary, so a period of extreme contention on the base layer eventually reaches the user through the data line rather than through the execution line.

The trade behind all of this is worth stating without the marketing. A rollup gives up some of the base layer’s verification story in exchange for cost, and it inherits the base layer’s settlement as its security backstop. The stages above are therefore not equivalent products with different prices; they are different arrangements of the same five steps, with the cost pushed to whichever stage the design decided to optimise.

Two rows, one meter

The sequence reduces to two multiplied quantities and a direction of payment. Gas used is the work, measured by the code and not by the sender. The price per unit is a formula plus a bid, where the formula comes from the previous block and is destroyed, and the bid comes from the sender and goes to the producer. Data has its own meter, priced in a market that moves independently and that determines how cheap a rollup can be on any given day.

Everything surprising about Ethereum fees follows from that arrangement. A price that cannot be negotiated but can be predicted is what makes the transaction cost the same for a fund and for a wallet. A price that decays at 12.5 percent per block is why a spike is a window rather than a plateau. A fee that nobody receives is why the tip is a bid for priority rather than a payment for service. The execution environment is a shared computer with a meter attached, and the stages above are simply what the meter records between the moment a transaction is built and the moment its result is final.