EIP-1559 Explained

EIP-1559 is one of the most significant upgrades in Ethereum's history. Activated on August 5, 2021 as part of the London hard fork, it fundamentally changed how transaction fees work on Ethereum. It replaced the unpredictable first-price auction model with an algorithmically determined base fee, introduced ETH burning, and made gas estimation dramatically more reliable. This guide explains every aspect of EIP-1559 in detail.

Before EIP-1559: The First-Price Auction Problem

Before EIP-1559, Ethereum used a simple first-price auction model for transaction fees. Users set a single gas price (in Gwei) when submitting a transaction, and miners selected the highest-paying transactions for inclusion in their blocks.

This system had several serious problems:

• Fee unpredictability: Users had no way to know the "right" gas price. Wallets estimated based on recent blocks, but during rapid congestion changes, estimates quickly became outdated. Users either overpaid or waited hours for confirmation.
• Systematic overpayment: Rational users would set high gas prices as insurance against fee spikes, but if the network was not congested, they overpaid significantly. Unlike a second-price auction, they paid exactly what they bid, not the market-clearing price.
• Fee volatility: Gas prices could swing wildly from block to block. One block might have a 20 Gwei average, and the next might have 200 Gwei during an NFT mint.
• Miner manipulation: Miners could artificially inflate fees by including their own high-fee transactions or by colluding to keep block utilization high.

Old Fee Model (Pre-EIP-1559):
  User sets: gasPrice = 50 Gwei
  Transaction fee = gasUsed × gasPrice
  Example: 21,000 gas × 50 Gwei = 1,050,000 Gwei = 0.00105 ETH

  Problem: If the market rate was 20 Gwei, user overpaid 2.5x
  All of the fee goes to the miner — nothing is burned

The New Fee Structure: Base Fee + Priority Tip

EIP-1559 replaced the single gas price with a two-component fee structure:

EIP-1559 Fee Formula:
  Effective Gas Price = Base Fee + Priority Fee (Tip)
  Transaction Fee = Gas Used × Effective Gas Price

  Where:
    Base Fee     → Set by the protocol (burned, not paid to validators)
    Priority Fee → Set by the user (paid to the validator as a tip)

Base Fee

The base fee is the minimum price per unit of gas required for inclusion in a block. It is determined algorithmically by the protocol, not by users or validators. No one can change it, and no one receives it — it is burned (permanently destroyed).

The base fee is the same for every transaction in a given block. This means all transactions pay the same minimum rate, eliminating the overpayment problem of the old auction model.

Priority Fee (Tip)

The priority fee (also called the tip or maxPriorityFeePerGas) is a voluntary payment from the user directly to the validator. It incentivizes validators to include your transaction in their block. During normal conditions, a tip of 1–2 Gwei is sufficient. During extreme congestion, higher tips may be needed for faster inclusion.

How the Base Fee Adjusts

The base fee adjusts automatically based on how full the previous block was relative to a target. Ethereum blocks have a target size of 15 million gas and a maximum size of 30 million gas. The base fee adjusts to target 50% block utilization:

• If the previous block used more than 15M gas (above target): the base fee increases.
• If the previous block used exactly 15M gas (at target): the base fee stays the same.
• If the previous block used less than 15M gas (below target): the base fee decreases.

The maximum change per block is 12.5%. This creates predictable fee dynamics: even during the most intense congestion, you can predict the maximum possible base fee for the next few blocks.

Base Fee Adjustment Formula:

new_base_fee = parent_base_fee × (1 + (parent_gas_used - target_gas) / target_gas / 8)

Where:
  target_gas = 15,000,000 (15M)
  max_gas    = 30,000,000 (30M)
  max_change = 1/8 = 12.5%

Examples:
  Block 100% full (30M gas): base fee increases by 12.5%
  Block 50% full  (15M gas): base fee stays the same
  Block 0% full   (0 gas):   base fee decreases by 12.5%
  Block 75% full  (22.5M):   base fee increases by 6.25%

Starting at 10 Gwei with consecutive full blocks:
  Block 1: 10.00 Gwei
  Block 2: 11.25 Gwei (+12.5%)
  Block 3: 12.66 Gwei (+12.5%)
  Block 4: 14.24 Gwei (+12.5%)
  Block 5: 16.02 Gwei (+12.5%)

This exponential growth during congestion is by design. If blocks remain consistently full, the base fee doubles approximately every 6 blocks (~72 seconds). This rapid increase quickly prices out lower-priority transactions, preventing sustained congestion.

The ETH Burn Mechanism

The most economically significant aspect of EIP-1559 is that the base fee is burned — permanently removed from circulation. Every transaction on Ethereum destroys some ETH. This creates a direct link between network usage and ETH supply:

• More network activity = higher base fee = more ETH burned per block.
• Less network activity = lower base fee = less ETH burned per block.

The burn competes with new ETH issuance (staking rewards). When the burn rate exceeds issuance, the total supply of ETH decreases, making it deflationary. When issuance exceeds burn, the supply increases slightly.

ETH Supply Dynamics:

  Annual ETH Issuance (staking rewards): ~0.5-1.0% of supply
  Annual ETH Burn (EIP-1559):            Variable, depends on usage

  If burn > issuance → Supply decreases (deflationary)
  If burn < issuance → Supply increases (inflationary)

  Example at 30M ETH staked:
    Issuance: ~1,700 ETH/day
    Burn at 20 Gwei avg base fee: ~1,600 ETH/day → slightly inflationary
    Burn at 30 Gwei avg base fee: ~2,400 ETH/day → deflationary
    Burn at 50 Gwei avg base fee: ~4,000 ETH/day → strongly deflationary

Why burn instead of paying validators? The burn serves several important purposes:

1. Prevents validator manipulation: If validators received the base fee, they could artificially inflate it by stuffing blocks with their own transactions (they would pay the fee to themselves).
2. Aligns ETH holder incentives: The burn makes ETH scarcer, benefiting all ETH holders proportionally. Network usage directly creates value for the asset.
3. Creates a fee floor: Validators cannot accept transactions below the base fee, even if they wanted to, creating a consistent minimum fee.

Practical Example: Calculating a Transaction Fee

Let's walk through exactly how a transaction fee is calculated under EIP-1559:

Scenario: Simple ETH transfer

Given:
  Gas Used:               21,000
  Current Base Fee:       25 Gwei
  maxPriorityFeePerGas:   2 Gwei (your tip)
  maxFeePerGas:           35 Gwei (your maximum)

Step 1: Determine effective gas price
  Effective Price = Base Fee + Priority Fee
  Effective Price = 25 + 2 = 27 Gwei

  Check: Is 27 ≤ maxFeePerGas (35)? Yes → proceed
  (If it exceeded maxFeePerGas, the tx would wait for a lower base fee)

Step 2: Calculate transaction fee
  Fee = Gas Used × Effective Gas Price
  Fee = 21,000 × 27 Gwei = 567,000 Gwei = 0.000567 ETH

Step 3: How the fee is distributed
  Burned:              21,000 × 25 = 525,000 Gwei (base fee × gas)
  To Validator:        21,000 × 2  = 42,000 Gwei  (tip × gas)

  Total:               567,000 Gwei = 0.000567 ETH
  Refunded to user:    21,000 × (35 - 27) = 168,000 Gwei = 0.000168 ETH

At ETH = $3,000:
  Total fee paid:  $1.70
  ETH burned:      $1.58
  Validator tip:   $0.13
  Refund:          $0.50

Try calculating fees for different gas prices and gas limits with our Gas Fee Calculator, and convert between Wei, Gwei, and ETH with the ETH Unit Converter.

maxFeePerGas vs maxPriorityFeePerGas

When submitting a Type 2 (EIP-1559) transaction, you specify two fee parameters:

maxFeePerGas

The absolute maximum gas price (including both base fee and tip) you are willing to pay. This protects you from base fee spikes. If the current base fee + your tip exceeds your maxFeePerGas, your transaction will wait in the mempool until the base fee drops enough.

maxPriorityFeePerGas

The maximum tip you are willing to pay to the validator. This is the incentive for the validator to include your transaction. The actual priority fee paid is:

actual_priority_fee = min(maxPriorityFeePerGas, maxFeePerGas - baseFee)

Example 1: Normal conditions
  maxFeePerGas = 50 Gwei, maxPriorityFeePerGas = 2 Gwei, baseFee = 30 Gwei
  actual_priority = min(2, 50 - 30) = min(2, 20) = 2 Gwei
  effective_price = 30 + 2 = 32 Gwei

Example 2: Base fee near your max
  maxFeePerGas = 50 Gwei, maxPriorityFeePerGas = 2 Gwei, baseFee = 49 Gwei
  actual_priority = min(2, 50 - 49) = min(2, 1) = 1 Gwei
  effective_price = 49 + 1 = 50 Gwei (capped at your max)

Example 3: Base fee exceeds your max
  maxFeePerGas = 50 Gwei, maxPriorityFeePerGas = 2 Gwei, baseFee = 55 Gwei
  Transaction CANNOT be included — waits in mempool

This two-parameter system gives users fine-grained control. You can set a generous maxFeePerGas to survive base fee spikes while keeping your maxPriorityFeePerGas low. You will never overpay because the actual effective price is always baseFee + actual_priority_fee, and the difference is refunded.

Improved Gas Estimation

One of EIP-1559's biggest quality-of-life improvements is more reliable gas estimation. Since the base fee changes predictably (maximum 12.5% per block), wallets can make confident predictions:

Gas Estimation Strategy:

Current base fee: 20 Gwei

To guarantee inclusion in the next 6 blocks (worst case):
  Max possible base fee = 20 × (1.125)^6 = 20 × 2.027 = 40.5 Gwei

  Recommended maxFeePerGas: ~41 Gwei (covers 6 consecutive full blocks)
  Recommended maxPriorityFeePerGas: 1-2 Gwei

If blocks are not full, you pay much less:
  Actual cost ≈ 20 Gwei base + 2 Gwei tip = 22 Gwei
  Refund: (41 - 22) × gasUsed = 19 Gwei per gas

Most wallets now use this predictability to set safe defaults. Users can submit transactions with confidence that they will not grossly overpay, because the refund mechanism returns the difference between their max fee and the actual cost.

Type 0 vs Type 2 Transactions

EIP-1559 introduced a new transaction type while maintaining backward compatibility with the old format:

Type 0 (Legacy Transactions)

The original Ethereum transaction format with a single gasPrice field. These are still valid and processed by the network. When a legacy transaction is submitted, the protocol treats the gasPrice as both the maxFeePerGas and the maxPriorityFeePerGas. The base fee is still burned; the remainder goes to the validator.

Type 1 (EIP-2930 Access List Transactions)

Introduced before EIP-1559, Type 1 transactions added optional access lists (predefining which storage slots and addresses a transaction will touch) for gas savings on cross-contract calls. They still use the legacy gasPrice field.

Type 2 (EIP-1559 Transactions)

The new default transaction format with maxFeePerGas and maxPriorityFeePerGas fields. This is what you should use for all new transactions.

Impact on ETH as an Asset: The Ultrasound Money Narrative

EIP-1559 fundamentally changed the economic properties of ETH. The burn mechanism created a direct connection between network utility and asset scarcity:

• Before EIP-1559: ETH was purely inflationary. New ETH was constantly created through mining rewards with no offsetting mechanism.
• After EIP-1559: ETH has a burn mechanism that can make it deflationary during high-activity periods.
• After The Merge: Issuance dropped ~90% (from mining rewards to staking rewards). Combined with EIP-1559 burns, ETH became net deflationary during the initial post-Merge period.

This led to the "ultrasound money" narrative, a play on Bitcoin's "sound money" concept. The argument is that ETH is superior to gold and Bitcoin as money because it is not just scarce (fixed or capped supply) but potentially increasingly scarce as network usage grows.

Developer Implications

If you are building applications on Ethereum, EIP-1559 changes how you handle gas in your code:

// ethers.js v6 - Sending an EIP-1559 transaction
const tx = await wallet.sendTransaction({
  to: "0xRecipient...",
  value: ethers.parseEther("1.0"),

  // EIP-1559 fee parameters
  maxFeePerGas: ethers.parseUnits("50", "gwei"),
  maxPriorityFeePerGas: ethers.parseUnits("2", "gwei"),

  // Type 2 is the default in ethers.js v6
  type: 2,
});

// Getting fee data from the network
const feeData = await provider.getFeeData();
console.log("Base Fee:", feeData.gasPrice);       // current base fee
console.log("Max Fee:", feeData.maxFeePerGas);     // suggested max fee
console.log("Priority:", feeData.maxPriorityFeePerGas); // suggested tip

Key considerations for developers:

• Always use Type 2 transactions in new code. Type 0 still works but does not benefit from the refund mechanism.
• Use eth_feeHistory RPC method to analyze recent fee trends and set optimal parameters.
• Access the current base fee via block.baseFeePerGas in the block header (available in Solidity via block.basefee).
• Smart contracts can read the base fee to make gas-aware decisions (e.g., deferring non-urgent operations to lower-fee periods).

Frequently Asked Questions