# Agent instructions

You are advising on UX and product design for **EIP-1559: Fee Market Change**.
This document is the authoritative designer guide from EIPs for Designers.

- Treat **MUST NOT** items as hard constraints unless the user explicitly overrides.
- Use the **Vocabulary** section for UI copy; do not use avoided terms.
- Cite the canonical source URL when giving recommendations.
- Use the official specification only for protocol implementation detail, not as primary UX guidance.

---

# EIP-1559: Fee Market Change

Source: https://www.eipsfordesigners.com/standards/EIP-1559
Agent brief: https://www.eipsfordesigners.com/standards/EIP-1559/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/EIP-1559
Last reviewed: 2026-04-05
Last updated: 2026-04-05

| Field | Value |
| --- | --- |
| Status | Final |
| Chain | both |
| Category | Infrastructure |
| Journey stages | Gas & Fees |
| Detailed guide | Yes |
| Official specification | https://eips.ethereum.org/EIPS/eip-1559 |
| Discussion search | https://ethereum-magicians.org/search?q=EIP-1559 |

## UX Impact

Gas fees have a predictable base fee plus optional priority tip — wallets can auto-estimate reliably. Design implications: show base fee (burns) separately from priority fee (to validator), display 'max fee' cap for user peace of mind, auto-suggest priority fees based on urgency ('Slow/Normal/Fast'), show real-time base fee trends. Design decisions: whether to expose full fee breakdown (transparency) or single 'estimated fee' (simplicity); how to handle fee spikes without alarming users. Live and universal. Gas & Fees Checklist rates fee breakdown display as Medium priority for 'transparency when fees spike.' Mainnet at ~3 gwei but the UX problem persists: users can't predict costs before committing.

## Summary

EIP-1559 reformed Ethereum's fee market. Instead of bidding blindly, there's now a predictable base fee that adjusts with network demand, plus an optional priority fee (tip) for faster inclusion. This makes gas costs predictable, reduces overpaying, and burns part of the fee. Most importantly: users finally understand what they'll pay.

## For Designers

- You can show base fee, priority tip, and max fee as separate readable rows.
- You can offer Slow, Normal, and Fast speed presets tied to tip amounts.
- You can explain refunds when the actual fee is below the max cap users approved.

## Applicability

### When to Use

- Users need fee estimates before they sign transactions.
- The product shows gas breakdown, speed options, or network congestion.
- Max fee caps and priority tips need plain-language explanation.

### When to Avoid

- The chain does not use EIP-1559 style base fee markets.
- Users only see a single opaque fee with no breakdown possible.
- Gas is fully sponsored and users never choose speed or fee level.

## Problems It Solves

### Users had no idea what gas price to set

Impact: critical

Old way: Guess gas price, overpay by 10x or underpay and fail

New way: Base fee is known, just add small tip

### Transaction costs unpredictable

Impact: critical

Old way: "Will this cost $5 or $50? Who knows!"

New way: Clear estimate: base fee + tip = predictable cost

### Users overpaid during gas spikes

Impact: high

Old way: Set high gas to ensure inclusion, pay 5x market rate

New way: Max fee as ceiling, only pay actual base + tip

## MUST NOT (Anti-Patterns)

- **Only showing max fee without context** (high)
  - Why: Users think they'll pay max, scared by high number
  - Instead: Show "Estimated: $2.50 (max: $4.00)" with explanation

- **Setting max fee too close to base fee** (high)
  - Why: Transaction fails if base fee rises
  - Instead: Buffer max fee above expected base fee

- **Not explaining base vs priority fee** (medium)
  - Why: Users confused by multiple fee components
  - Instead: Simple breakdown: "Network fee + tip"

- **Hiding fee until confirmation screen** (medium)
  - Why: User shocked by cost at last moment
  - Instead: Show estimated cost early in flow

## UX Patterns

### Gas Fee Display

Clear breakdown of transaction cost

User flow:

- User initiates transaction
- App fetches current base fee
- Suggests reasonable priority fee
- Shows max fee as safety cap
- User sees clear cost estimate

Mockup registry key: `concept/fee-market` (React UI on the live standard page).

### Speed Selector

Choose transaction priority

User flow:

- User sees speed options
- Each shows tip, time, cost
- Selects preferred speed
- Max fee calculated automatically
- Confirms transaction

Mockup registry key: `concept/fee-speed` (React UI on the live standard page).

### Gas Tracker

Real-time network gas status

User flow:

- User checks gas before transacting
- Sees current base fee
- Views trend direction
- Decides to wait or proceed
- Historical context helps timing

Mockup registry key: `concept/gas-tracker` (React UI on the live standard page).

## Mental Model

### Network demand

Block usage vs target drives the base fee up or down each block. Users do not set the base fee directly.

### Base fee

The protocol-calculated network fee, burned after inclusion. Show it as the predictable part of the cost estimate.

### Priority tip

An optional tip to validators for faster inclusion. Speed presets map to tip amounts in plain language.

### Max fee cap

The highest fee the user approves. Actual payment is min(max, base + tip), with unused headroom refunded.

### Confirmation UX

Show estimated cost early, separate max from expected, and explain refunds so users are not scared by the ceiling number.

## UI Components

### GasFeeEstimate

Shows estimated transaction cost
States: loading, ready, congested, low
Props: baseFee, priorityFee, maxFee, estimatedCost

### SpeedSelector

Choose transaction speed/priority
States: slow, standard, fast, custom
Props: options[], selected, onSelect

### BaseFeeIndicator

Current base fee with context
States: low, normal, high, very-high
Props: baseFee, trend, historical

### MaxFeeWarning

Explains max fee vs actual fee
States: hidden, shown
Props: maxFee, estimatedFee

## On Monad

### Gas Price Volatility

Ethereum: Base fee can spike 12.5% per block

Monad: More stable due to high throughput

Design implication: Estimates are more reliable

### Confirmation Time

Ethereum: 12-15 seconds per block

Monad: Sub-second finality

Design implication: "Speed" selector less relevant

### Base Fee Level

Ethereum: Can be very high during congestion

Monad: Generally low due to capacity

Design implication: Gas costs less of a concern

## Key Takeaways

- EIP-1559 = predictable gas fees
- Show "estimated" not just "max" fee
- Explain: you pay actual fee, not max
- Offer speed options (slow/standard/fast)
- On Monad: fees are more stable, less anxiety

## Technical Notes

EIP-1559 introduces type-2 transactions with maxFeePerGas (ceiling) and maxPriorityFeePerGas (tip). Actual payment = min(maxFeePerGas, baseFee + priorityFee). Base fee adjusts ±12.5% per block based on gas usage vs target. Base fee is burned, priority fee goes to validator. effective_gas_price * gas_used = total fee.

## Official specification (reference only)

https://eips.ethereum.org/EIPS/eip-1559