Block Elasticity and How the Base Fee Moves

The previous page introduced the two prices you pay after EIP-1559: a base fee that every transaction in a block pays and that gets burned, plus a priority fee tip that goes to the block proposer. It left one question hanging: the base fee is set by the protocol, not bid by users — so what actually sets it, and why does it move?

This page answers that. The base fee is the output of a small feedback controller baked into the protocol. To understand the controller you first have to unlearn one thing from earlier parts: an Ethereum block is not a fixed-size box. It is elastic. Once you see the block as a target it can overshoot, the base-fee rule becomes obvious — it is just the thermostat that pushes usage back toward that target. This is the mechanism that turns the chaotic first-price auction into something whose price you can predict one block ahead.

The block is elastic, not fixed

Before EIP-1559, a block had one number: a gas limit, a hard ceiling on the total gas of all transactions it contained. Blocks filled up to that ceiling and stopped. EIP-1559 split that single number into two:

• Gas target — the size the protocol wants the average block to be. It is set to half the gas limit.
• Gas limit — the hard ceiling, now twice the target. A block may stretch all the way up to it, but never past.

So a block breathes. In a quiet moment it can be nearly empty; under a burst of demand it can swell to twice the target. The “limit” is the wall; the “target” is the resting size the protocol steers toward over time.

   gas
   used
   per      hard ceiling ────────────────────  gas LIMIT   (≈ 2 × target)
   block                    ▲
                            │  elastic range: blocks may overshoot
                            │  target during bursts …
            target ─────────────────────────── gas TARGET  (½ of limit)
                            │
                            │  … or undershoot it in a lull
                            ▼
                0 ───────────────────────────

Three words get confused constantly, so pin them down now, because their relationship is exactly what drives the next block’s base fee:

Term	What it is	Who sets it
target	the size the controller aims for (½ the limit)	protocol constant
limit	the hard ceiling a block may not exceed (2× target)	protocol / proposer within bounds
used	the gas the block actually consumed	whatever transactions got included

used is the measured signal. target is the setpoint. The gap between them is the error the controller corrects. limit just caps how far used can run in a single block.

By the numbers — target, limit, and elasticity

Use round figures and treat the exact numbers as time-sensitive — the durable point is the ratio, not the absolute value.

   For most of Ethereum's post-1559 life:
     gas LIMIT   ≈ 30,000,000 gas
     gas TARGET  ≈ 15,000,000 gas   (= limit / 2)
     elasticity  = limit / target = 2

   Through 2025 the limit was raised in steps toward:
     gas LIMIT   ≈ 60,000,000 gas
     gas TARGET  ≈ 30,000,000 gas   (still limit / 2)

   A "full" block is one at the limit; a "target" block is
   half-full. The average block, over time, sits at target.

The elasticity multiplier of 2 is a protocol constant. Whatever the limit becomes, the target is always half of it, so the controller’s job — “steer the average block to half the ceiling” — never changes even as the ceiling is raised.

The base fee is a controller, not an auction

Here is the core idea. After each block is produced, the protocol looks at how full that block was relative to target and computes the next block’s base fee. Nobody bids. The rule is mechanical:

• Block was above target (used > target) → raise the base fee for the next block.
• Block was below target (used < target) → lower it.
• Block was exactly at target (used == target) → leave it unchanged.

And the size of each step is bounded: at most ±12.5% per block. The base fee can never more than double or halve across two consecutive blocks; the most it can move in one step is one-eighth. That bound is what makes the fee smooth — it ratchets rather than jumps.

   block N produced
        │
        ▼
   how full vs target?
        │
   ┌────┴─────────────────────────┐
   │ used > target  →  base fee ↑  (up to +12.5%)
   │ used = target  →  base fee =  (no change)
   │ used < target  →  base fee ↓  (up to -12.5%)
   └──────────────┬───────────────┘
                  ▼
   base fee for block N+1  ← knowable the instant block N lands

The exact adjustment scales with how far the block was from target. A block right at the limit (twice target, the maximum overshoot) triggers the full +12.5%. A block only slightly over target nudges the fee up by a sliver. Symmetrically, a completely empty block pulls the fee down the full −12.5%; a block just under target eases it down slightly. The controller is proportional: the bigger the error, the bigger the correction, capped at one-eighth either way.

Under the hood — the exact adjustment formula

The protocol computes the next base fee from three inputs: the current base fee, the block’s gas used, and the gas target. The rule from EIP-1559 is, in effect:

   if used == target:
       next = current                       # dead centre, no change

   if used > target:
       delta = current * (used - target) / target / 8
       next  = current + max(delta, 1)       # rise, but at least 1 wei

   if used < target:
       delta = current * (target - used) / target / 8
       next  = current - delta               # fall

The division by 8 is where the 12.5% cap comes from: the term (used - target) / target is at most 1 (when used hits the limit, i.e. 2 × target), so the largest possible delta is current / 8 — one-eighth, or 12.5%. Written as a small controller in Rust, matching the arithmetic the protocol performs:

/// Compute the base fee for the *next* block from the current block's fullness.
/// `denominator` is the EIP-1559 BASE_FEE_MAX_CHANGE_DENOMINATOR (8 → ±12.5%).
fn next_base_fee(base_fee: u128, gas_used: u64, gas_target: u64) -> u128 {
    const DENOM: u128 = 8; // ⇒ max change of 1/8 = 12.5% per block

    if gas_used == gas_target {
        return base_fee; // exactly at target: hold steady
    }

    if gas_used > gas_target {
        // Above target: ratchet up, proportional to the overshoot.
        let delta_gas = (gas_used - gas_target) as u128;
        let delta = base_fee * delta_gas / gas_target as u128 / DENOM;
        base_fee + delta.max(1) // always move by at least 1 wei
    } else {
        // Below target: decay down, proportional to the undershoot.
        let delta_gas = (gas_target - gas_used) as u128;
        let delta = base_fee * delta_gas / gas_target as u128 / DENOM;
        base_fee - delta
    }
}

Two details matter. The rise clamps to a minimum of 1 wei so that a base fee near the floor still creeps upward under sustained pressure rather than getting stuck by integer rounding. And the whole thing is pure integer arithmetic — deterministic across every client, because every node must compute the identical next base fee or they’d disagree on the state.

Why a controller instead of an auction

Contrast this with the world two pages back. Under the first-price auction, the price of the next block was a mystery: it depended on what other people would secretly bid, which you could only guess. You over-bid to be safe and often overpaid, or under-bid and got stuck. There was no signal you could read.

The controller replaces that guessing game with a published, one-block-ahead price. The moment block N is included, its gasUsed is known, so anyone can compute block N+1’s base fee exactly — it is a deterministic function of a number already on chain. A wallet does not need to auction against strangers; it reads the current base fee, knows it can move at most ±12.5% next block, and sets its maxFeePerGas with a small buffer.

   FIRST-PRICE AUCTION                 EIP-1559 CONTROLLER
   ───────────────────                 ───────────────────
   price = ??? (others' hidden bids)   price = deterministic from last block
   you guess and hope                  you read it off-chain, exactly
   jumps around wildly                 moves ≤ 12.5% per block, smoothly
   over/underpay is normal             a small buffer is enough

Think of demand as heat and the base fee as a thermostat. A sustained rush of transactions keeps blocks above target, so the base fee ratchets up block after block — +12.5%, +12.5%, +12.5% — until the price is high enough that marginal users drop off and blocks fall back toward target. When the rush ends, blocks run below target and the fee decays back down. The controller does not clear a single auction; it hunts for the price at which demand equals the target block size, and it re-hunts every 12 seconds.

By the numbers — how fast a ratchet compounds

Because each step is multiplicative, sustained full blocks raise the base fee geometrically. Starting at 10 gwei with every block at the limit (the full +12.5% each time):

   block 0:  10.00 gwei
   block 1:  11.25 gwei   (× 1.125)
   block 2:  12.66 gwei
   block 3:  14.24 gwei
   ...
   block 6:  20.27 gwei   (roughly doubled in ~6 blocks ≈ 72 s)

It takes about 6 consecutive full blocks to double the base fee — near 1.125⁶ ≈ 2.03 — and the same to halve it under empty blocks. That is why a demand spike from, say, a hot NFT mint shows up as a fast but bounded climb, not an instant 10× the way a first-price auction could spike. Fees can still get very high under sustained load; they just get there on a predictable curve. (Figures illustrative; the compounding rate is the durable point.)

It actually happened — the base fee did its job in the wild

When EIP-1559 shipped in the London hard fork on 5 August 2021, one worry was that the controller might misbehave under the very demand spikes it was meant to tame. In practice the mechanism held: during heavy NFT-mint congestion later in 2021, blocks pinned at the limit (twice target) for stretches, and the base fee climbed the expected +12.5%-per-block ratchet rather than exploding unpredictably. Users still paid a lot when demand was extreme — the controller sets a market-clearing price, it does not make blockspace cheap — but the price was legible: wallets could show a base fee and a confident estimate for the next block, which the old auction never allowed. The lesson: the controller’s win is predictability and smoothness, not lower absolute cost. When people say “1559 didn’t lower fees,” they are right and it was never supposed to — it made fees knowable.

The architect’s lens

• Why does it exist? Because a fixed-size block plus a blind first-price auction gave users no way to know what the next block would cost, producing chronic over- and under-payment. The controller exists to make the base fee a published, predictable number derived mechanically from on-chain data.
• What problem does it solve? Price discovery for blockspace without an auction. By steering the average block to a target and moving the fee at most ±12.5% per block, it lets a wallet compute the next block’s price exactly instead of guessing against hidden bids.
• What are the trade-offs? Predictability is bought with responsiveness: because the step is capped at one-eighth, a genuine demand shock takes several blocks to price in, during which blocks sit at the limit and some transactions wait. Elasticity also means individual blocks can be twice target-size, so short-term node load is spikier than a hard-fixed block would be.
• When should I avoid it? You don’t opt out — it is protocol-level. But you should not treat the base fee as a stable number: over minutes it can ratchet meaningfully, so a maxFeePerGas set with too thin a buffer can strand a transaction during a climb. Budget for the ratchet, don’t assume the current fee.
• What breaks if I remove it? You fall back to a first-price auction: no one-block-ahead price, no burn-based sink on the fee, and the wild bid volatility EIP-1559 was designed to kill. The predictable fee estimation that wallets now rely on becomes guesswork again.

Check your understanding

1. EIP-1559 replaced a block’s single “gas limit” with two numbers. Name them, state the fixed ratio between them, and explain what “elastic” means in this context.
2. Give the base-fee adjustment rule in full: what happens to the next block’s base fee when the current block is above target, below target, and exactly at target — and what is the maximum step in either direction?
3. Where does the 12.5% cap come from in the formula? Reference the divisor and explain why the maximum overshoot term equals 1.
4. Explain why the base fee is described as a feedback controller rather than an auction, and why this makes the next block’s price knowable in advance.
5. Roughly how many consecutive full blocks does it take to double the base fee, and why does the fee move geometrically rather than linearly?

Show answers

1. The two numbers are the gas target (the size the protocol aims for) and the gas limit (the hard ceiling a block may not exceed). The limit is always twice the target — an elasticity of 2. “Elastic” means a block is not a fixed size: it can range anywhere from near-empty up to the limit (twice target), so blocks breathe with demand rather than being a rigid box.
2. Above target (used > target) → the next base fee rises, by up to +12.5%. Below target (used < target) → it falls, by up to −12.5%. Exactly at target → it is unchanged. The step is proportional to how far used was from target, capped at ±12.5% (one-eighth) per block.
3. The formula divides by the BASE_FEE_MAX_CHANGE_DENOMINATOR of 8. The change is base_fee × (used − target) / target / 8. The term (used − target) / target is at most 1, because the largest possible used is the limit, which equals 2 × target, giving (2×target − target) / target = 1. So the biggest delta is base_fee / 8 = 12.5%.
4. An auction clears a single block by collecting hidden competing bids — you can’t know the price until it clears. The base fee instead is a deterministic function of the previous block’s gasUsed versus target: sustained over-target demand ratchets it up, a lull decays it down. Because the input (last block’s fullness) is already on chain and the rule is fixed, anyone can compute the next block’s base fee exactly, one block ahead — no bidding, no guessing.
5. About 6 consecutive full blocks (≈ 72 seconds), because 1.125⁶ ≈ 2.03. It moves geometrically because each step is a multiplicative ±12.5% of the current base fee, not a fixed absolute amount — so repeated steps compound.