23 September 2026 · 6 min read

Base fee takes six blocks to double

EIP-1559 caps the base fee change at 12.5 percent a block, so it needs about six blocks to double and twenty to rise tenfold. In that lag the tip is the whole auction.

Ethereum's fee market has a thermostat, and the thermostat has a speed limit. Since EIP-1559 the protocol sets a base fee for every block, raises it when the previous block was fuller than its target and lowers it when emptier, and the rule caps the change at one eighth per block in either direction. That cap has a consequence that is easy to state and easy to forget: after a step change in demand, the base fee takes about six blocks, seventy-two seconds, to double, and about twenty blocks, four minutes, to rise tenfold. During that lag the base fee is not the price. The priority fee is the whole auction, which is why bots overpay in the first minute of a spike and why any fee estimator that reads the base fee is wrong at exactly the moments it matters.

The rule and the arithmetic

The mechanism is in EIP-1559 and it is short. Each block has a gas limit and a target of half that limit, set by an elasticity multiplier of two. If the parent block used more gas than the target, the base fee rises in proportion to the excess, up to a maximum of one eighth when the block was full; if it used less, the base fee falls in proportion, down to one eighth when the block was empty. The denominator of eight is the whole story of the lag. A sustained run of full blocks raises the base fee by a factor of 1.125 per block, and the number of blocks needed to reach a multiple m is the logarithm of m in base 1.125: 5.9 blocks to double, 19.5 blocks for ten times, 39 blocks for a hundred. I call that the doubling distance, and the six and the twenty are the numbers to carry around.

Base fee response to a step in demand under the one-eighth cap, with the doubling and tenfold distances marked A line rising from a base fee of 1 at block zero: with every block full, the base fee multiplies by 1.125 each block, reaching 2 at about block six and 10 at about block twenty, on a logarithmic axis where the line is straight. Vertical markers at six and twenty blocks show the doubling and tenfold distances, and a note says the lag is 72 seconds and about four minutes at twelve-second blocks. Six blocks to double, twenty to rise tenfold Base fee as a multiple of its start under sustained full blocks, log scale base fee distance 20x 10x 5x 2x 1x 0 6 12 20 24 Blocks since the step, twelve seconds each doubles at 5.9 blocks, 72 s tenfold at 19.5 blocks, 234 s
Illustrative: the response computed from the rule in EIP-1559, a factor of 1.125 per full block; the marks are the logarithms of 2 and 10 in that base.

What a real spike looks like

The rule is easy to see in live data, because the base fee history is a standard call on any node. I pulled a day of blocks from a public RPC endpoint through eth_feeHistory, 7,168 blocks ending at block 26,000,047 on 18 September 2026, with a gas limit of 60 million, and looked for the sharpest rise within any twenty-block window. It came at block 25,996,624: a run of full blocks, gas used at or near the limit, took the base fee from 0.15 gwei to 0.55 in fourteen blocks, a factor of 3.6, and the blocks that fell below target in the middle of the run show as the small dips where the fee paused. Absolute fees on mainnet are tiny in 2026; the shape is what matters, and the shape is the one the arithmetic predicts.

Base fee per block across the sharpest rise in a day of mainnet blocks, 18 September 2026 A line over 45 consecutive blocks from 25,996,619 to 25,996,663. The base fee sits near 0.15 gwei for the first six blocks, then climbs steeply to 0.55 gwei by block 25,996,638 during a run of full blocks, dips briefly as a few blocks come in under target, and continues to about 0.9 gwei by the end of the window. Small marks below the line show blocks that were full. A run of full blocks, and the fee climbing at the speed limit Base fee in gwei per block, blocks 25,996,619 to 25,996,663, Ethereum mainnet base fee marked 1.0 0.75 0.5 0.25 0 619 629 639 649 659 Block number, last three digits of 25,996,6xx 0.15 gwei 0.55, fourteen blocks later pauses in the climb are blocks under target; every full block is a step of one eighth
Source: pulled by the author from a public Ethereum mainnet RPC via eth_feeHistory on 18 September 2026; the window is the twenty-block span with the largest multiplicative rise in the preceding day.

The lag is where the tip lives

Now put a bot in that window. A trading opportunity appears at block 25,996,624, demand steps up, and the base fee is 0.15 gwei, which was the right price a block ago and is wrong now. For the next six blocks the base fee is below where it will settle, because the cap will not let it get there faster, and the protocol has nothing else to say about who gets included. The tip does. Every transaction that wants a place in those blocks bids a priority fee, the builder orders by it, and the tip market is briefly the entire fee market, running on top of a base fee that is still catching up. That is why bots overpay in the first minute of a spike: the base fee tells them the block is cheap, the block is not cheap, and the only signal that says so is what other people are tipping.

An EIP-1559 block: limit, target, base fee burned and tip paid A block drawn as a bar with a gas limit of 60 million and a target of 30 million marked at the midpoint. Gas used above the target raises the next base fee by up to one eighth; below lowers it. Beside it, a transaction's fee is split into the base fee, which is burned, and the priority fee, which goes to the builder, with the note that during the lag the priority fee is the whole auction. What the block knows and what it does not target: 30M gas up to the limit: 60M above target: next base fee up, at most one eighth below target: next base fee down, at most one eighth base fee: burned tip base fee: from the last block tip: everyone else, right now In the lag the base fee is stale by construction; the tip carries the auction. an estimator reading the base fee reads the previous block's demand, not this one's The limit was 60 million gas at the time of writing; the target is always half of it.
Illustrative: the block and fee split as EIP-1559 defines them; the gas limit is the mainnet value read from the chain on 18 September 2026.

The rule for a bot follows from the doubling distance. When you detect a spike, the base fee will be wrong for about six blocks and materially wrong for more, and during that window the decision is a bid on tips, not a wait for the base fee to price the block. After the doubling distance the base fee has caught up to a doubling of demand and the tip market cools toward normal; after the tenfold distance it has caught up to nearly anything. So the window in which paying a high tip is rational is bounded by the arithmetic: bid on tips for roughly six blocks, watch the base fee's trajectory to see whether the step was a doubling or a tenfold, and stop bidding when the base fee's climb flattens, because a flattening climb means the blocks stopped being full, which means the demand step is over.

What the arithmetic says about atomic transactions

The reason I care about six blocks is that the transactions I send are atomic: a flash-loan arbitrage either executes in full within one block or reverts and pays gas for nothing. For a transaction like that, the fee decision is not "what is the fair price" but "what gets me into the next block, and is the opportunity still there when I land". During a spike the second question dominates. The opportunity that appeared at block one is being competed for by everyone who saw it, the base fee says nothing about that competition for six blocks, and the tip is the only lever that moves inclusion order. Paying a high tip for those six blocks is not overpaying if it wins the block; it is overpaying if the opportunity was gone before the block was built, which is a question about the opportunity's lifetime rather than the fee.

That splits the bot's fee logic into two regimes with a boundary the arithmetic supplies. Inside the doubling distance from a detected step, the base fee is treated as a floor rather than a price, the tip is bid from the observed tips in the last block or two rather than from any estimator, and the bid is capped by the opportunity's expected value net of the reverted-gas cost. Outside it, when the base fee's climb has flattened, the estimator is trusted again and the tip drops back to a small margin. The boundary is not a tuning parameter. It is six blocks, because the denominator is eight.

Why estimators fail here

Fee estimators fail during spikes for a reason the arithmetic makes precise. Most of them look at recent blocks and report a base fee plus a tip percentile, which is the right thing to do in steady state and exactly the wrong thing in the first six blocks of a step, when the base fee is lagging and the tip percentiles from the last few blocks describe a market that no longer exists. An estimator that understood the cap would do something different: notice that the last block was full, project the base fee forward by 1.125 per block for as long as it expects full blocks, and report a tip that reflects the gap between the projected and current base fee rather than the historical tip. That projection is a one-line calculation, and the doubling distance is its horizon.

There is a mirror image on the way down. When a spike ends, the base fee falls by at most one eighth per block too, so it stays high for six blocks after the demand is gone, and a bot that keeps paying the spike's tip on top of a still-elevated base fee is overpaying in the other direction. The thermostat is symmetric, and so is the rule: the base fee tells you where demand was a block ago, the cap tells you how far it can move by the next block, and everything in between is the tip.

GasEthereumFee Markets
All writing

Written by Mohd Shayan

Get new posts by email

Occasional essays on engineering, AI, and building for the people technology leaves behind.

One email per new post. Unsubscribe any time.

Subscribe with RSS