EIP-1559: Base Fee, Priority Fee, and the Burn

The previous page, The Pre-1559 First-Price Auction, left us with a working but hostile market: a single gasPrice field, a proposer who greedily takes the highest bids, and a user forced to guess a clearing price they can never see. Everyone either overbids to be safe or underbids and gets stuck. The mechanism worked — untrusting strangers did agree on which transactions entered each block — but the cost of participating was a blind auction with terrible UX.

This page is about the fix that shipped with the London upgrade on 5 August 2021: EIP-1559. It does one structural thing — it splits the price of a transaction into two parts with two very different fates. One part is a price the protocol computes and then destroys; the other is a tip you choose that pays the validator. Understanding that split, and especially the destruction, is the whole page. Everything downstream — how the base fee moves (Block Elasticity and How the Base Fee Moves), how wallets estimate fees (Fee Estimation and the Economics of Blockspace) — builds on this split.

The one idea: split the per-gas price in two

Before 1559, the price you paid per unit of gas was a single number you bid: gasPrice. After 1559, that single number is replaced by a sum of two numbers with different origins and different destinations:

   Pre-1559  (one number, you bid it, it all goes to the proposer):

       price_per_gas  =  gasPrice          ──►  proposer

   EIP-1559  (two numbers, one computed + one chosen):

       price_per_gas  =  base_fee          ──►  BURNED  (destroyed)
                       + priority_fee      ──►  proposer (the tip)
                         (a.k.a. the "tip")

Read the split slowly, because both halves are load-bearing:

The base fee is a per-gas price the protocol itself computes for the whole block. You do not bid it. Every transaction in a given block pays the same base fee per gas — it is a posted price, not a competitive bid. Crucially, when you pay it, the ETH is burned: permanently removed from circulation, paid to no one.
The priority fee (the “tip”) is a per-gas amount you choose and it is the part that actually pays the validator who includes you. It is optional in principle, and it is what lets you jump the queue when a block is contested.

So the mental model flips. Pre-1559 you asked, “What single price do I need to bid to beat everyone this block?” Post-1559 you ask, “The protocol has already posted a base fee I must pay and that will be burned — how much tip, on top, do I want to add?” The blind auction is gone from the part that dominates the cost; a much smaller, simpler auction remains only in the tip.

The two fields a type-2 transaction actually carries

An EIP-1559 transaction (transaction “type 2”; see Transaction Types: Legacy to Blob) does not literally carry a base_fee field — it can’t, because the base fee is computed by the protocol at inclusion time, not by the sender. Instead the sender supplies two ceilings:

maxPriorityFeePerGas — the most you’re willing to tip the validator, per gas. This is your bid in the (small) remaining auction.
maxFeePerGas — the most you’re willing to pay all-in, per gas, base fee plus tip together. This is a cap, a safety ceiling.

At inclusion, the protocol knows the block’s base_fee and computes what you actually pay:

   effective_tip     = min( maxPriorityFeePerGas,
                            maxFeePerGas − base_fee )

   price_per_gas      = base_fee + effective_tip        (never exceeds maxFeePerGas)

The subtraction is the point: your tip is squeezed by whatever the base fee turned out to be, but your all-in cost per gas can never exceed the maxFeePerGas cap you set. You set a ceiling and pray about nothing — if the base fee came in lower than you feared, you simply pay less and the difference is not spent. This is the structural cure for overpayment: you name a maximum you can tolerate, not a price you must hit.

Why compute the base fee instead of auctioning it?

This is the heart of the change, so it deserves a first-principles answer rather than “it’s nicer.”

In a first-price auction, the price is an emergent, hidden quantity: it is whatever the marginal included bid happened to be, and you cannot observe it before you bid. Every user is guessing at a number that only becomes knowable after the block is built. That is why wallets shipped elaborate fee estimators and why users still routinely overpaid — the safe move under uncertainty is to bid high.

EIP-1559 removes the guesswork by making the dominant part of the price a published, deterministic function of recent demand. The protocol looks at how full recent blocks were and adjusts the base fee up or down by a bounded step each block (the control loop is the subject of the next page; the key property here is that it is computed and visible, not bid and hidden). Because the base fee for the next block is knowable in advance and can only move by a small bounded amount, a wallet can quote you a fee that will still be roughly right when your transaction lands.

The consequence for the user is enormous: you mostly only need to choose a tip. Set maxFeePerGas to something comfortably above the current base fee (a safety cap), set a modest maxPriorityFeePerGas, and you’re done. The number that used to require anxious guessing — the price to clear — is now posted for you. The auction shrank to the tip, and the tip only matters when the block is contested (more on that below).

   Where the guesswork went:

   pre-1559   ┌───────────────────────────────────────────┐
              │  guess the ONE clearing price (hidden)     │  ← the whole cost
              └───────────────────────────────────────────┘

   EIP-1559   ┌──────────────────────────┐┌───────────────┐
              │ base fee (posted, known) ││ tip (you pick) │
              └──────────────────────────┘└───────────────┘
                 no guessing here            small choice here

A concrete cost example

Recall the fee formula from Gas Limit, Gas Used, and the Fee Formula: total cost is gas_used × price_per_gas. Under EIP-1559 the price per gas is base_fee + tip, so:

   total_fee = gas_used × (base_fee + tip)

Take a plain ETH transfer, which costs a fixed 21,000 gas. Suppose at inclusion the block’s base fee is 20 gwei and you tip 1 gwei. (A gwei is 10⁻⁹ ETH — a billionth of an ether — the customary unit for gas prices. So 21 gwei is 0.000000021 ETH per unit of gas.)

   gas_used   = 21,000
   base_fee   = 20 gwei/gas
   tip        =  1 gwei/gas
   price/gas  = 20 + 1 = 21 gwei/gas

   total_fee  = 21,000 × 21 gwei
              = 441,000 gwei
              = 0.000441 ETH

   Of which:
     burned  (base fee): 21,000 × 20 gwei = 420,000 gwei  = 0.000420 ETH  (destroyed)
     tipped  (priority): 21,000 ×  1 gwei =  21,000 gwei  = 0.000021 ETH  (to validator)

Look at the split of the money, not just the price. Of the 0.000441 ETH this transfer cost, 95% (0.000420 ETH) was burned — it left the sender’s account and now belongs to no one — and only 5% (0.000021 ETH) actually paid the validator. Under a first-price auction, all 0.000441 ETH would have gone to the proposer. This is the structural change EIP-1559 makes visible: the bulk of a transaction fee no longer flows to whoever builds the block. It is destroyed.

The ratio of burned to tipped depends entirely on how contested the block is. In a quiet, half-empty block the base fee drifts low and the tip can be zero — almost nothing is burned, and the validator earns a sliver. In a jammed block the base fee is high (mostly burned) and users bid tips up to jump the queue.

   Same 21,000-gas transfer, three market conditions:

   condition        base_fee   tip     burned        tipped       total
   ──────────────   ────────   ─────   ───────────   ──────────   ──────────
   quiet block       8 gwei    0 gwei  0.000168 ETH  0           0.000168 ETH
   normal block     20 gwei    1 gwei  0.000420 ETH  0.000021    0.000441 ETH
   contested block  90 gwei    5 gwei  0.001890 ETH  0.000105    0.001995 ETH

The base fee dominates the cost; the tip dominates ordering. Treat the gwei figures as illustrative — the durable facts are the formula (gas_used × (base_fee + tip)) and which part is burned.

The burn is a monetary lever, not just a congestion knob

Here is where EIP-1559 stops being merely a UX improvement and becomes something bigger. Because the base fee is burned rather than paid out, every transaction quietly removes ETH from the total supply. Meanwhile Ethereum issues new ETH to reward validators for producing and attesting to blocks. So at any moment there are two opposing flows on the total supply:

   ISSUANCE  (+)  new ETH minted to reward validators (proof-of-stake)
   BURN      (−)  base fee of every transaction, destroyed

   net supply change per block  =  issuance  −  burn

When the network is busy, the burn can exceed issuance, and the total supply of ETH shrinks — the asset becomes net deflationary. When the network is quiet, issuance wins and supply grows slowly. This is the origin of the informal “ultrasound money” idea: under sufficient demand, the very act of using Ethereum destroys ETH faster than the protocol creates it. (Whether the net is positive or negative on any given day depends on demand and on the current issuance rate, which itself changed when Ethereum moved to proof-of-stake at The Merge in September 2022. State it as a mechanism, not a guaranteed outcome: heavy use can make Ethereum net-deflationary, and often has since the Merge — but it is demand-dependent, not automatic.)

The deep point for this book’s throughline — what does it cost to run a shared world computer? — is that the fee is no longer just a toll paid to an operator. It is partly a monetary policy instrument baked into the fee market itself. Congestion pricing and supply policy became the same mechanism. That is a genuinely unusual design: the price of using the computer and the money supply of the computer’s native asset are now coupled by construction.

Under the hood — why burn instead of pay the proposer?

Burning the base fee is not an accident of accounting; it removes a specific attack on the fee market. If the base fee were paid to the block proposer, the proposer would have a direct incentive to inflate it — to stuff the block or otherwise push the base fee up — because every gwei of base fee would be their revenue. The base fee is meant to be an honest, demand-driven posted price; letting the recipient of that price also control it would corrupt it.

By destroying the base fee, the protocol makes the proposer indifferent to its level. The proposer earns only the tip (plus the block reward and any MEV). So the base fee can serve as a clean signal of demand, uncontaminated by the incentives of whoever happens to build the block. The burn is what lets a posted price stay honest in a system full of untrusting, self-interested strangers — which is exactly the problem this whole book is about.

   If base fee were PAID to proposer:  proposer wants base_fee HIGH  → corrupt signal
   Because base fee is BURNED:         proposer is indifferent       → honest signal
                                       proposer optimizes only the TIP + block reward

When does the tip actually matter?

A common misreading is that the tip is the main event. It usually isn’t. The tip only does real work when blocks are contested — when there is more demand for inclusion this block than there is room, so the ordering of transactions is genuinely being bid for.

In a quiet block that isn’t full, there’s no competition for inclusion. A validator will happily include your transaction for a tiny tip — even zero — because including one more transaction costs them nothing and the base fee (which they don’t receive) is irrelevant to them. The base fee is drifting down, and the tip barely matters.
In a contested block where more transactions want in than fit, the validator orders by tip (they keep the tip; they don’t keep the base fee). Now your tip is a real bid: raise it to be included sooner, or included at all. This is the residual first-price auction — but confined to the tip, which is a small fraction of total cost in the example above.

So the tip is best understood as a priority lane, not the price of admission. Admission is set by the base fee (posted, burned); speed under contention is set by the tip (chosen, paid to the validator). Most of the time you can leave the tip modest and let the posted base fee do the work.

The architect’s lens

The major technology on this page is EIP-1559’s split fee market — a computed, burned base fee plus a chosen, paid tip.

Why does it exist? Because the pre-1559 first-price auction forced every user to blindly guess a hidden clearing price, producing chronic overpayment and terrible UX for the simple act of getting a transaction included.
What problem does it solve? It turns the dominant part of the fee into a protocol-computed posted price that’s knowable in advance and moves in small bounded steps, so users mostly only choose a tip instead of guessing a whole price — and it makes that posted price honest by burning it so no one profits from inflating it.
What are the trade-offs? The base fee is burned, so it does not pay for security; validator revenue must come from issuance, tips, and MEV. And the mechanism doesn’t lower fees under real scarcity — a genuinely contested block still gets an expensive base fee and a tip auction on top. It improves predictability and fairness, not raw capacity.
When should I avoid it? As a user you don’t opt out — type-2 is the default and the right choice. The thing to avoid is treating the tip as the price: over-tipping in a quiet block wastes money, and under-capping maxFeePerGas in a rising market gets you stuck. Set a comfortable cap; tip modestly unless you truly need priority.
What breaks if I remove it? Without the computed base fee you’re back to blind first-price bidding and its overpayment; without the burn you’d hand the base fee to proposers, giving them an incentive to inflate it and corrupting the very price signal the mechanism depends on — and you’d lose the monetary lever that lets Ethereum burn more than it issues under heavy use.

Check your understanding

EIP-1559 replaces the single gasPrice with two per-gas components. Name them, and state precisely who or what each one goes to.
A transaction uses 21,000 gas in a block whose base fee is 30 gwei, with a tip of 2 gwei. Compute the total fee, and split it into the amount burned and the amount paid to the validator (in gwei and in ETH).
Why is the base fee computed by the protocol rather than bid by users? What does that change about the guessing a user has to do?
Explain, from the proposer’s incentives, why the base fee is burned instead of paid to the block proposer. What would go wrong if it were paid to them?
What is the “ultrasound money” idea, and under what condition does Ethereum’s total ETH supply actually shrink? Why does this make the fee “a monetary lever, not just a congestion knob”?

Show answers

The base fee (per gas) and the priority fee / tip (per gas). The base fee is burned — destroyed, paid to no one. The tip goes to the validator/proposer who includes the transaction. (The sender supplies maxFeePerGas as an all-in cap and maxPriorityFeePerGas as the tip ceiling; the base fee itself is set by the protocol at inclusion.)
Price per gas = 30 + 2 = 32 gwei. Total = 21,000 × 32 = 672,000 gwei = 0.000672 ETH. Burned = 21,000 × 30 = 630,000 gwei = 0.000630 ETH. Paid to validator = 21,000 × 2 = 42,000 gwei = 0.000042 ETH.
Because in a first-price auction the clearing price is a hidden, emergent quantity you can only know after the block is built, so users must guess and tend to overpay. Computing it makes the base fee a published, deterministic function of recent demand that moves in small bounded steps, so it’s knowable in advance. The user no longer guesses the price — they mostly just choose a tip and set a safety cap.
If the base fee were paid to the proposer, the proposer would have a direct incentive to inflate it (stuff blocks, push the base fee up) because it would be their revenue — corrupting the demand signal the base fee is supposed to be. Burning it makes the proposer indifferent to its level (they earn only the tip, block reward, and MEV), so the posted price stays an honest signal of real demand.
“Ultrasound money” is the idea that because the base fee is burned, heavy usage can destroy ETH faster than the protocol issues it to validators, making ETH net-deflationary. The supply shrinks whenever burn > issuance (net supply change per block = issuance − burn). It’s a monetary lever because congestion pricing and supply policy are now the same mechanism: using the network directly reduces the money supply, so fees affect ETH’s supply, not just who gets included.