Gas fee

Gas is a unit of work, not a unit of money

Gas measures computational effort. Every operation the virtual machine performs carries a cost fixed by the protocol's fee schedule, a transaction declares how many units it authorises, and the fee is that number multiplied by a price per unit.⁵ Ethereum's documentation states the formula directly: units of gas used times base fee plus priority fee.³

Congestion therefore changes what your transaction costs, not what it does. A plain ETH transfer consumes 21,000 gas on a quiet Sunday and 21,000 gas during a liquidation cascade.³ Contract calls cost more because they do more, and writing to storage is far more expensive than arithmetic, because the network is being paid to carry that state indefinitely.

That separation is useful at design time. Gas units are a property of your code and you control them. Gas price is a property of a market and you do not. Any mechanism that assumes a fee level rather than a fee range has an untested assumption sitting inside it.

EIP-1559: base fee, tip, and the burn

Before August 2021 Ethereum ran a first price auction and users guessed. EIP-1559 replaced the guess with a base fee per gas set in protocol, which moves up or down each block according to a formula based on gas used in the parent block against a gas target.¹

Three things changed at once. The base fee is calculated rather than bid. It is burned rather than paid to the proposer, which removes it from circulating supply permanently. And a transaction now carries two fields, a maximum fee per gas and a maximum priority fee per gas, so the user sets a ceiling and receives the difference back instead of overpaying by default.¹

The priority fee is the part that is still an auction. Under congestion, inclusion in the next block is decided by what you tip, which is why fee estimators quote a range rather than a number, and why the entire difference between a wallet's fast and slow settings is the tip.

A worked example: what 252,000 gwei is made of

Ethereum's own documentation works a simple transfer. 21,000 gas at a base fee of 10 gwei plus a priority fee of 2 gwei gives 21,000 times 12, which is 252,000 gwei, or 0.000252 ETH.³

Split that and the design shows itself. 21,000 times 10 gwei is 210,000 gwei of base fee, destroyed. 21,000 times 2 gwei is 42,000 gwei of priority fee, paid to the proposer who included it.¹ Five sixths of what the user paid went to nobody at all. One sixth went to a validator.

Scale the same arithmetic and it stops being a curiosity. The burn is proportional to demand for blockspace, so a busy chain removes supply faster than a quiet one, and a network whose issuance sits below its burn rate contracts while it is being used. Whether that is desirable is a separate argument, and it is an argument about the chain's own tokenomics rather than about fees. The point for a builder is that the fee mechanism and the supply schedule are one mechanism viewed from two directions.

Why fees spike, in the mechanism's own terms

Two constants in EIP-1559 explain the shape of a spike. The elasticity multiplier is 2, so a block can carry up to twice the gas target when demand allows. The base fee maximum change denominator is 8, so the base fee moves by at most one eighth, 12.5 percent, from one block to the next.¹

That cap sounds gentle and compounds quickly. If demand stays high enough to keep every block at double the target, the base fee rises 12.5 percent per block: about 3.2 times higher after ten blocks, about 10.5 times after twenty, about 34 times after thirty. It falls the same way once blocks drop below target, which is why fee spikes tend to be sharp and short rather than sustained.

So a spike is the mechanism working, not failing. Demand for blockspace during a mint, a liquidation cascade or a sharp market move is close to inelastic for a few minutes, and the base fee climbs until enough users decide to wait. What EIP-1559 removed was the overpayment and the guesswork. It did not make blockspace cheap, and it was not designed to.

Layer 2 fees carry a component you do not control

A rollup user's fee has two parts. The first is execution on the L2, which is cheap because the sequencer is not bidding for L1 blockspace. The second is the cost of publishing data to Ethereum, because a rollup executes transactions off L1 and posts transaction data and proofs back to it, which is how it inherits L1 security instead of standing up its own trust assumptions.⁴

Since the Dencun upgrade in March 2024 that data goes into blobs. EIP-4844 introduced a blob carrying transaction type whose data is not accessible to EVM execution while its commitment is, held available for a limited window, and priced in a fee market of its own.² An L2 fee is now a blend of two independent markets: L2 execution, and blob space priced by how many rollups want it at the same moment.

The design consequence is direct. Your users' costs on an L2 are partly a pass-through of a market you have no influence over, and blob demand is set by every other rollup's traffic rather than yours. If your product's unit economics depend on a fee staying under a cent, that is an assumption about somebody else's activity.

What gas costs do to a token design

The failure is always the same shape: a mechanism requiring users to transact more often than the fee environment supports. Reward claiming is the usual case. If a weekly reward is worth four dollars and claiming it costs three, the reward is one dollar, and your users will work that out before your model does.

Governance is the quieter case. Voting costs gas, so participation falls, so a quorum threshold set at launch becomes either unreachable or reachable by a single large holder. Rebasing, staking, unstaking, migrating, bridging: each is a toll booth, and every toll booth filters out your smallest users first, which is usually the exact cohort your distribution was designed to reach.

The fixes are not exotic. Batch claims. Accrue rather than distribute. Sign off-chain and settle in aggregate. Move the mechanism to an L2 and accept the pass-through described above. What matters is running the arithmetic at design time against a high fee scenario rather than a median one, because the moments your mechanism most needs to work are the moments the chain is busiest.

What we check on any fee sensitive mechanism

Four things, in order. The gas cost of every user action on your critical path, measured rather than estimated. The fee level at which each of those actions stops making economic sense for the smallest user you intend to serve. Whether any action becomes mandatory during exactly the conditions that raise fees, which is true of liquidations, redemptions and unstaking. And whether the chain you picked has a fee market you can model at all.

Then a question that is easy to forget: who pays. Sponsored transactions and paymasters move the cost onto the protocol's balance sheet, turning a user experience problem into a treasury line item that grows with usage. That is often the right trade. It should be a decision with a number attached to it rather than a default that surfaces in month six.