Fee Estimation and the Economics of Blockspace
The last page showed the base fee moving: block elasticity and the base-fee controller makes each block’s base fee a deterministic function of the previous block’s fullness, nudged up or down by at most 12.5%. That single fact quietly rewrote the wallet’s job. Under the pre-1559 first-price auction, a wallet had to guess one blind number — the whole price — against a sealed field of competing bids. Now the largest part of that number, the base fee, is derivable. The wallet no longer guesses the price of blockspace; it predicts one small piece and pads for the rest.
This page is about that shift and what sits underneath it. First, how a modern wallet actually estimates a fee: predict the next few base fees, pick a tip, and cap your exposure. Then the bigger picture the whole Part has been circling — blockspace as a market: a bounded, per-block resource that strangers bid for, where one part of the price is burned (charged to every holder of ether) and the other part is paid to the block’s proposer. Getting that split right is what makes a permissionless world computer verifiable at all.
Two numbers, not one
Section titled “Two numbers, not one”Recall the EIP-1559 mechanism. A type-2 transaction does not carry a single “gas price.” It carries two ceilings:
maxPriorityFeePerGas— the tip. The most you are willing to pay the proposer, per unit of gas, on top of the base fee. This is your bid for inclusion priority.maxFeePerGas— the ceiling. The most you are willing to pay in total, per unit of gas, base fee plus tip combined. This caps your worst case.
The base fee itself is not something you set. The protocol computes it for the block your transaction lands in, and it is burned — destroyed, paid to no one. What you actually pay per gas is:
effective_price = min( maxFeePerGas , baseFee + maxPriorityFeePerGas ) paid_to_proposer(per gas) = effective_price - baseFee # the realised tip burned(per gas) = baseFee # destroyedAnd the crucial line, the one that changes how estimation works:
refund(per gas) = maxFeePerGas - effective_priceIf the base fee comes in lower than you feared, you do not pay your ceiling. You pay
baseFee + tip, and the gap up to maxFeePerGas is simply never charged. The ceiling is a
safety limit, not a price. That asymmetry is the whole reason estimation got easier: you can
set maxFeePerGas generously without overpaying, because overshooting the base fee costs you
nothing — the excess is refunded by construction.
maxFeePerGas ───────────────────────────── ← ceiling you set (never exceeded) │ refunded (never charged) baseFee + tip ────────────── ← what you actually pay │ tip → proposer baseFee ────────── ← burned │ 0 ────────────────How a wallet estimates a fee
Section titled “How a wallet estimates a fee”Estimation under 1559 is two smaller problems, each easier than the old single blind guess.
Predicting the base fee
Section titled “Predicting the base fee”The next block’s base fee is not a prediction at all — it is arithmetic. From the current
block’s gasUsed and baseFeePerGas, the controller formula gives the exact base fee of the
very next block. There is nothing to estimate for the immediate next block; a node that has the
head block has the number.
The estimation only re-enters for blocks further out, because your transaction might not land
in the next block, and each future base fee depends on how full the blocks between now and then
turn out to be. But even here the uncertainty is tightly bounded: the base fee can change by at
most ±12.5% per block. So a wallet that wants to be safe for the next n blocks pads the
current base fee by the maximum the controller could raise it:
buffer over n blocks = baseFee × (1.125)^n
n = 1 → ×1.13 (safe for the next block, generously) n = 3 → ×1.42 n = 6 → ×2.03 (safe even if every block for a minute is completely full)This is why wallets often show a maxFeePerGas that looks much higher than the base fee you
end up paying. It is deliberate headroom: set the ceiling as if the base fee climbed at its
maximum rate for several blocks, so your transaction stays valid through a fee spike — and rely
on the refund to give the padding back when the spike does not happen.
Choosing the tip
Section titled “Choosing the tip”The base fee buys you inclusion once there is space; the tip buys you priority for the space. Because the base fee is burned regardless, the tip is the only lever that competes for ordering within a block. A proposer building a block sorts the eligible transactions by the tip they will actually pay and fills the block from the top.
Wallets estimate the tip empirically, by looking at what recently-included transactions
actually tipped. The standard tool is the JSON-RPC method eth_feeHistory, which returns, for
a window of recent blocks, the base fees and a set of priority-fee percentiles — “in the
last 20 blocks, the 10th / 50th / 90th percentile tip among included transactions was X.”
# Ask a node for the last 5 blocks' base fees and the 25/50/75th# percentile priority fees paid by included transactions.cast rpc eth_feeHistory 5 latest '[25,50,75]'A wallet then maps its urgency to a percentile: fast picks a high percentile (outbid almost everyone), normal picks the median, cheap picks a low one and accepts waiting a few blocks. The tip is genuinely a competitive bid — but a bid over a small residual, typically a few gwei, not over the entire price. During calm periods the “right” tip is often near the proposer’s minimum acceptable tip; only under contention does it climb.
Under the hood — why the refund makes over-provisioning free
Section titled “Under the hood — why the refund makes over-provisioning free”In a first-price auction, bidding high is paying high: your bid is your price, so headroom is pure waste. That is why pre-1559 fee estimation was so fraught — every gwei of safety margin was a gwei you actually spent, and the field was sealed, so you were guessing against invisible rivals with real money on the line.
EIP-1559 breaks the link between what you authorise and what you pay. maxFeePerGas is an
authorisation ceiling; the realised price is baseFee + tip, computed after the fact from the
block you actually landed in. Because the protocol charges the realised price and refunds the
rest, the dominant strategy flips: set the ceiling comfortably high and the tip honestly,
and you are protected against spikes without penalty. Estimation stops being a bluff and becomes
a calculation — predict a bounded quantity, pad it, and let the mechanism reconcile the
difference. That is the practical payoff of turning a first-price auction into a
posted-price-plus-tip market.
Blockspace is a market
Section titled “Blockspace is a market”Step back from the wallet and look at what is being bought and sold. Every block has a gas target (around 15 million gas) and a hard gas limit (around 30 million) — the elastic band from the previous page. That is the entire supply of computation and state the world computer offers in one ~12-second slot. It is bounded on purpose: it has to be, because every full node re-executes every transaction in the block and stores the result forever (why gas exists at all).
A bounded resource that strangers want more of than exists is, definitionally, a market. Demand for blockspace sets a clearing price, and 1559 splits that price into two economically distinct halves that answer two different questions:
┌──────────────────────────────────────────┐ what you pay ──▶ │ baseFee (burned) + tip (to proposer) │ └───────┬──────────────────────┬───────────┘ │ │ "is there demand for "should MY tx go blockspace right now?" before that one?" │ │ a congestion price, a priority price, paid by destruction, paid to the builder, shared by ALL holders earned by ordering- The base fee is a congestion signal. It rises when blocks run above target and falls when they run below, so it measures aggregate demand. Because it is burned, no single party profits from it being high — which is exactly what stops the party who sets block contents (the proposer) from manufacturing congestion to enrich themselves.
- The tip is a priority price. It is the only thing that competes for ordering within a block, and it is paid to the proposer as their reward for including you. This is where the actual auction still lives — but over a thin residual, not the whole fee.
Who pays, who is paid — and what “cheap” costs
Section titled “Who pays, who is paid — and what “cheap” costs”Trace the money and the incentives fall out.
The burn shares the cost of congestion among everyone who holds ether, not just the sender. When base fees are high and a lot of ether is destroyed, the total supply shrinks, which (all else equal) makes every remaining unit slightly more valuable. So a busy chain quietly charges its congestion cost to the whole holder base by making the money scarcer — the sender pays in ether, but the value of that payment is distributed across all holders rather than handed to one miner. That is a deliberate redesign of who benefits from congestion.
The tip pays the one party doing the work of ordering and proposing: the validator who built the block (validators and staking). It is a direct, local reward for inclusion — the incentive that keeps proposers actually packing blocks instead of leaving them empty.
And “cheap”? A low fee is never free computation — it is computation whose true cost (re-execution and permanent storage on every node, forever) is simply not being reflected in the price right now because demand happens to be low. The floor under “cheap” is the base fee’s minimum, and the whole point of keeping that floor non-trivial is the next section.
The spam filter, restated
Section titled “The spam filter, restated”This is the Part’s thesis, and it is worth stating plainly because everything above is in service of it. Fees are the spam filter that makes a permissionless world computer verifiable at all.
Anyone, anywhere, with no permission, can broadcast a transaction that every node on Earth must re-execute and remember forever. If that were free, the shared machine would be flooded into uselessness in minutes — the rational move would be to submit infinite work at zero cost. Gas meters the work; the fee formula prices it; EIP-1559 makes the price legible and honest. The base fee’s job is to keep a non-zero floor under that price so the machine stays scarce enough that honest users can verify it on modest hardware. Free computation and a verifiable public chain are mutually exclusive: the fee is not a tax bolted on afterward, it is the thing that makes the permissionless part survivable.
Keep L1 lean, export throughput to L2
Section titled “Keep L1 lean, export throughput to L2”There is an obvious-looking objection: if fees are just a congestion signal, why not raise the gas limit — make blocks bigger, supply more blockspace, and let the price fall? Bigger blocks would make L1 cheaper today.
Ethereum deliberately does not do this, and the reason is the throughline of the whole book. Every extra unit of gas per block is extra work every full node must do to stay a full node. Enlarge blocks enough and only well-funded operators can keep up; the set of independent verifiers shrinks, and a chain that fewer and fewer people can actually check is a chain that has quietly traded away its decentralization — the very property that made it worth trusting. This is the scalability trilemma: you cannot cheaply have decentralization, security, and raw L1 throughput at once.
So Ethereum’s answer is to keep L1 base fees high enough to keep the node light, and export cheap throughput to rollups. An L2 executes transactions off-chain in bulk and posts compressed data back to L1 (the rollup pattern), amortising one L1 fee across thousands of L2 transactions. EIP-4844 blob space even gives rollups their own 1559-style fee market — a separate bounded resource with its own base fee and burn — so that L2 data does not compete with L1 execution for the same blockspace. The design intent is explicit: L1 stays scarce and verifiable; L2 carries the volume. “Cheap transactions” on Ethereum increasingly means “cheap on an L2 that settles to an expensive, trustworthy L1,” not “cheap on L1 itself.”
Where the fee goes: pre-1559 vs EIP-1559
Section titled “Where the fee goes: pre-1559 vs EIP-1559”The whole redesign is clearest when you put the two fee destinations side by side, because the destination is the incentive.
PRE-1559 (first-price auction) sender pays gasPrice × gasUsed └──────────────► 100% to the miner Incentive: the miner keeps every fee, so the miner wants fees HIGH. A miner can (and did) stuff or reorder blocks to lift the price they collect. The party setting block contents profits directly from congestion.
EIP-1559 (base fee + tip) sender pays (baseFee + tip) × gasUsed (capped by maxFeePerGas) ├── baseFee × gasUsed ──► BURNED (destroyed, paid to no one) └── tip × gasUsed ──► to the proposer Incentive: the proposer profits ONLY from the tip, never from the base fee. Manufacturing congestion raises the base fee — which the proposer does not receive — so the incentive to fake demand is removed. The base fee becomes an honest congestion meter.Two changes in incentive fall out of that one change in destination:
- The proposer no longer profits from congestion. Under first-price, the party who decides what goes in the block is the same party who pockets the whole fee — a direct conflict of interest. Burning the base fee severs it: the proposer’s income (the tip) is decoupled from the congestion price (the burn), so there is no gain in faking scarcity.
- The cost of congestion is socialised, not captured. Pre-1559, a busy chain enriched miners. Post-1559, a busy chain destroys ether, distributing the “cost” across all holders as scarcity rather than handing it to whoever happened to mine. The fee stopped being a transfer to one actor and became a burn shared by all.
The tip preserves the one thing a pure posted price cannot do — let an urgent transaction pay to jump the queue — while the burn removes the perverse incentive that made the old auction hostile to users.
The architect’s lens
Section titled “The architect’s lens”- Why does it exist? Because blockspace is a bounded, contested resource on a permissionless chain, and both estimating its price and distributing its cost were broken under a first-price auction. Modern fee estimation plus the base-fee burn exist to make the price predictable to pay and honest to charge.
- What problem does it solve? It turns fee-setting from a blind bid into a calculation (predict a bounded base fee, cap it, tip the residual, get the rest refunded), and it turns the congestion price from a proposer’s profit into a burn shared by all holders — removing the incentive to manufacture congestion.
- What are the trade-offs? L1 stays deliberately expensive so nodes stay light and the verifier set stays broad; cheap throughput is pushed onto L2s, which adds bridging and data-availability complexity. And the burn means fees leave the system entirely rather than paying for security directly — security is funded separately by issuance.
- When should I avoid it? You never opt out of the fee market on L1. What you avoid is treating a low base fee as permanent — it is a live congestion signal that can more than 2× in a minute — and doing high-volume work on L1 when an L2 exists to carry it far cheaper.
- What breaks if I remove it? Remove the fee and the shared machine is flooded for free — it stops being verifiable. Remove the burn and the proposer profits from congestion again, so the base fee stops being an honest meter. Remove the tip and there is no legitimate way to pay for urgency, which pushes priority back into opaque side-channels.
Check your understanding
Section titled “Check your understanding”- Under EIP-1559 a wallet sets
maxFeePerGaswell above the current base fee, yet the sender usually does not pay that much. Why is over-provisioning the ceiling free, and what mechanism gives the excess back? - The next block’s base fee is described as “arithmetic, not a prediction,” yet wallets still pad the base fee by factors like ×1.42. Reconcile those two statements — what exactly is being estimated, and why?
- Explain the two economically distinct halves of an EIP-1559 fee. Which one is a congestion signal shared among all holders, which one is a priority price paid to the proposer, and why does that split matter for incentives?
- Ethereum could make L1 transactions cheaper by raising the block gas limit. Give the first-principles reason it deliberately does not, and where it sends cheap throughput instead.
- Restate the Part’s thesis: in what sense are fees the “spam filter” that makes a permissionless world computer verifiable at all, and why are free computation and a verifiable public chain mutually exclusive?
Show answers
- Because
maxFeePerGasis an authorisation ceiling, not the price. The realised price ismin(maxFeePerGas, baseFee + tip), and the protocol charges only that — the gap up to the ceiling isrefund = maxFeePerGas − effective_priceand is simply never charged. So a generous ceiling protects against a base-fee spike at zero cost, because overshooting the base fee is refunded by construction rather than paid. - The base fee of the immediate next block is a deterministic function of the current block’s
gasUsedand base fee, so for that one block there is nothing to estimate. Padding covers the case where the transaction lands several blocks later: each future base fee depends on how full the intervening blocks are, but the change is bounded at ±12.5% per block, so a wallet pads by1.125^nto stay valid through the worst-case rise overnblocks. - The base fee is a congestion signal: it rises above target and falls below, measuring aggregate demand, and it is burned — destroyed, so its cost is shared across all ether holders as scarcity rather than paid to anyone. The tip is a priority price: it competes for ordering within a block and is paid to the proposer. The split matters because burning the base fee decouples the proposer’s income (the tip) from the congestion price, removing any incentive to manufacture congestion.
- Every extra unit of gas per block is extra work every full node must redo and store forever. Raising the limit prices out smaller verifiers, shrinking the set of independent nodes and quietly trading away decentralization — the scalability trilemma. Ethereum instead keeps L1 lean and exports cheap throughput to rollups (L2s), which batch many transactions into one L1 footprint, aided by dedicated blob space (EIP-4844).
- Anyone can broadcast work that every node must re-execute and store forever; if that were free, the rational move would be to submit infinite work at zero cost and flood the machine into uselessness. Fees put a non-zero floor under the cost of imposing work, keeping the chain scarce enough to verify on modest hardware. Free computation would make the shared machine unverifiable, so a truly free, truly permissionless world computer cannot exist — the fee is what makes the permissionless part survivable.