{"id":"EIP-1559","name":"Fee Market Change","status":"Final","chain":"both","category":{"id":"infrastructure","name":"Infrastructure","description":"Foundational patterns enabling other standards"},"journeyStages":[{"id":"gas","name":"Gas & Fees","description":"Paying for transactions"}],"uxImpact":"EIP-1559 defines Ethereum's type-2 fee market: a base fee, optional priority fee, max fee cap, and base-fee burn on Ethereum. Monad supports EIP-1559-compatible type-2 transactions but uses chain-specific accounting: gas is charged from the gas limit and its base-fee controller differs from Ethereum's. Label the network and verify fee accounting instead of reusing Ethereum burn, recipient, adjustment, or capacity claims.","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","officialUrl":"https://eips.ethereum.org/EIPS/eip-1559","kind":"proposal","hasDetailedContent":true,"content":{"id":"EIP-1559","sources":[{"label":"Official EIP-1559 specification","url":"https://eips.ethereum.org/EIPS/eip-1559","type":"official-spec"},{"label":"Monad gas pricing documentation","url":"https://docs.monad.xyz/developer-essentials/gas-pricing","type":"reference"}],"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","summary":"EIP-1559 defines Ethereum's type-2 fee market: a base fee, optional priority fee, max fee cap, and base-fee burn on Ethereum. Monad supports EIP-1559-compatible type-2 transactions but uses chain-specific accounting: gas is charged from the gas limit and its base-fee controller differs from Ethereum's. Label the network and verify fee accounting instead of reusing Ethereum burn, recipient, adjustment, or capacity claims.","applicability":{"whenToUse":["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."],"whenToAvoid":["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."]},"designerTakeaways":["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 current chain estimates.","On Ethereum, you can explain unused max-fee headroom; on Monad, explain gas-limit charging from current wallet or RPC behavior."],"mentalModel":[{"label":"Network demand","description":"On Ethereum, parent-block gas usage versus target drives the base fee up or down each block. Other EIP-1559-compatible chains can use a different controller."},{"label":"Base fee","description":"On Ethereum, the protocol-calculated base fee is burned after inclusion. On another chain, verify the fee destination before showing burn language."},{"label":"Priority tip","description":"An optional priority fee can influence ordering. Verify the beneficiary and urgency model for the selected chain."},{"label":"Max fee cap","description":"For EIP-1559 type-2 transactions, max fee per gas caps the price per gas. On Monad, the gas-limit-based amount is the relevant maximum."},{"label":"Confirmation UX","description":"Show estimated cost early, separate price-per-gas caps from the expected total, and label chain-specific charging and refund behavior."}],"problemsSolved":[{"problem":"Users had no idea what gas price to set","oldWay":"Guess gas price, overpay by 10x or underpay and fail","newWay":"Base fee is known, just add small tip","impact":"critical"},{"problem":"Transaction costs unpredictable","oldWay":"\"Will this cost $5 or $50? Who knows!\"","newWay":"Clear, chain-labeled estimate with base fee, tip, gas limit, and applicable cap","impact":"critical"},{"problem":"Users overpaid during gas spikes","oldWay":"Set high gas to ensure inclusion, pay 5x market rate","newWay":"Use the selected chain's max-price and gas-charging rules as the safety boundary","impact":"high"}],"uxPatterns":[{"name":"Gas Fee Display","description":"Clear, network-labeled breakdown of transaction cost","userFlow":["User initiates transaction","App fetches current chain fee data","Suggests a chain-aware priority fee","Shows the applicable price and total cap","User sees a clear cost estimate"]},{"name":"Speed Selector","description":"Choose transaction priority when the chain's fee market supports it","userFlow":["User sees speed options","Each shows the chain-specific tip, expected time, and cost","Selects preferred speed","Max fee calculated automatically","Confirms transaction"]},{"name":"Gas Tracker","description":"Real-time, network-specific gas status","userFlow":["User checks gas before transacting","Sees the current chain base fee","Views trend direction","Decides to wait or proceed","Historical context helps timing"]}],"uiComponents":[{"name":"GasFeeEstimate","description":"Shows estimated transaction cost","states":["loading","ready","congested","low"],"props":["baseFee","priorityFee","maxFee","estimatedCost"]},{"name":"SpeedSelector","description":"Choose transaction speed/priority","states":["slow","standard","fast","custom"],"props":["options[]","selected","onSelect"]},{"name":"BaseFeeIndicator","description":"Current base fee with context","states":["low","normal","high","very-high"],"props":["baseFee","trend","historical"]},{"name":"MaxFeeWarning","description":"Explains max fee vs actual fee","states":["hidden","shown"],"props":["maxFee","estimatedFee"]}],"antiPatterns":[{"pattern":"Only showing max fee without context","why":"Users think they'll pay max, scared by high number","instead":"Show \"Estimated: $2.50 (max: $4.00)\" with explanation","severity":"high"},{"pattern":"Not explaining base vs priority fee","why":"Users confused by multiple fee components","instead":"Simple breakdown: \"Network fee + tip\"","severity":"medium"},{"pattern":"Setting max fee too close to base fee","why":"If the base fee exceeds the max fee, the transaction is ineligible for that block and may remain pending or be rejected on submission. This is not an included execution revert.","instead":"Show fee headroom and distinguish rejected submission, pending inclusion, and included execution failure. Refresh estimates before offering a replacement.","severity":"high"},{"pattern":"Hiding fee until confirmation screen","why":"User shocked by cost at last moment","instead":"Show estimated cost early in flow","severity":"medium"}],"onMonad":[{"aspect":"Gas charged","ethereum":"EIP-1559's effective price is applied to gas used.","monad":"Monad charges gas limit × price per gas; gas limit, not gas used, determines gas paid.","designImplication":"Show a chain-labeled gas-limit-based maximum and do not reuse the Ethereum gas-used formula."},{"aspect":"Base-fee controller","ethereum":"The base fee follows Ethereum's gas-used-versus-target controller, with a maximum 12.5% adjustment per block.","monad":"Monad uses a different dynamic base_price_per_gas controller with different target and adjustment behavior.","designImplication":"Use current chain data and do not hardcode Ethereum's adjustment or any block-capacity value."},{"aspect":"Fee accounting","ethereum":"The base fee is burned and the priority fee is paid to the block producer under EIP-1559.","monad":"Monad's gas page establishes EIP-1559-compatible pricing and ordering, but does not establish the same burn or universal recipient language.","designImplication":"Qualify burn and beneficiary copy by chain and source; do not present Ethereum accounting as a Monad fact."},{"aspect":"Capacity fields","ethereum":"Base-fee adjustment uses Ethereum's target and block gas parameters.","monad":"Current documentation separates block gas limit from the base-price controller target, and network or revision parameters can change.","designImplication":"Read current network data instead of hardcoding capacity, target, fixed gwei, or USD examples."}],"specConstraints":[{"id":"fee-estimation","constraint":"The EIP addresses first-price auction inefficiency and fee overpayment through a new fee market.","appliesTo":"application","normativity":"normative","specQuote":"* **Inefficiencies of first price auctions**: The current approach, where transaction senders publish a transaction with a bid a maximum fee, miners choose the highest-paying transactions, and everyone pays what they bid. This is well-known in mechanism design literature to be highly inefficient, and so complex fee estimation algorithms are required. But even these algorithms often end up not working very well, leading to frequent fee overpayment.","specSection":"Motivation","specUrl":"https://eips.ethereum.org/EIPS/1559#motivation","designImplication":"Explain fee presets as estimates under the chain’s fee market, not guarantees of inclusion or savings."},{"id":"effective-gas-price","constraint":"GASPRICE returns the effective gas price defined by the EIP fee-market rules.","appliesTo":"application","normativity":"normative","specQuote":"Block validity is defined in the reference implementation below.\nThe `GASPRICE` (`0x3a`) opcode **MUST** return the `effective_gas_price` as defined in the reference implementation below.","specSection":"Specification","specUrl":"https://eips.ethereum.org/EIPS/1559#specification","designImplication":"Label effective gas price separately from the user’s max fee and priority fee in transaction review and history."},{"id":"legacy-pricing","constraint":"Legacy transactions remain valid but do not directly benefit from the new pricing system.","appliesTo":"wallet","normativity":"backwards-compatibility","specQuote":"## Backwards Compatibility\nLegacy Ethereum transactions will still work and be included in blocks, but they will not benefit directly from the new pricing system.  This is due to the fact that upgrading from legacy transactions to new transactions results in the legacy transaction's `gas_price ` entirely being consumed either by the `base_fee_per_gas` and the `priority_fee_per_gas`.","specSection":"Backwards Compatibility","specUrl":"https://eips.ethereum.org/EIPS/1559#backwards-compatibility","designImplication":"Support legacy transactions while clearly showing when the selected transaction type uses type-2 fee controls."},{"id":"block-hash-compat","constraint":"Block-hash consumers must adapt to the additional block-header field introduced by the fee market.","appliesTo":"infrastructure","normativity":"backwards-compatibility","specQuote":"### Block Hash Changing\nThe datastructure that is passed into keccak256 to calculate the block hash is changing, and all applications that are validating blocks are valid or using the block hash to verify block contents will need to be adapted to support the new datastructure (one additional item).  If you only take the block header bytes and hash them you should still correctly get a hash, but if you construct a block header from its constituent elements you will need to add in the new one at the end.","specSection":"Backwards Compatibility > Block Hash Changing","specUrl":"https://eips.ethereum.org/EIPS/1559#block-hash-changing","designImplication":"Chain explorers, indexers, and block-verification surfaces should distinguish unsupported block format from an invalid transaction."},{"id":"gasprice-meaning","constraint":"GASPRICE now represents signer-paid ETH per gas and no longer directly exposes miner payment.","appliesTo":"application","normativity":"backwards-compatibility","specQuote":"### GASPRICE\nPrevious to this change, `GASPRICE` represented both the ETH paid by the signer per gas for a transaction as well as the ETH received by the miner per gas.  As of this change, `GASPRICE` now only represents the amount of ETH paid by the signer per gas, and the amount a miner was paid for the transaction is no longer accessible directly in the EVM.","specSection":"Backwards Compatibility > GASPRICE","specUrl":"https://eips.ethereum.org/EIPS/1559#gasprice","designImplication":"Use explicit labels for signer cost versus validator/miner revenue and do not reuse pre-1559 fee copy."},{"id":"block-capacity","constraint":"The increased maximum block size/complexity can cause short-term processing and memory problems for clients.","appliesTo":"infrastructure","normativity":"security-considerations","specQuote":"### Increased Max Block Size/Complexity\nThis EIP will increase the maximum block size, which could cause problems if miners are unable to process a block fast enough as it will force them to mine an empty block.  Over time, the average block size should remain about the same as without this EIP, so this is only an issue for short term size bursts.  It is possible that one or more clients may handle short term size bursts poorly and error (such as out of memory or similar) and client implementations should make sure their clients can appropriately handle individual blocks up to max size.","specSection":"Security Considerations > Increased Max Block Size/Complexity","specUrl":"https://eips.ethereum.org/EIPS/1559#increased-max-block-size-complexity","designImplication":"Infrastructure status and explorer latency states should account for short-term block-size bursts without treating a delayed index as a user transaction failure."},{"id":"fee-queue-ordering","constraint":"Transaction ordering among similar priority fees is client-specific and should resist pending-pool spam.","appliesTo":"infrastructure","normativity":"security-considerations","specQuote":"### Transaction Ordering\nWith most people not competing on priority fees and instead using a baseline fee to get included, transaction ordering now depends on individual client internal implementation details such as how they store the transactions in memory.  It is recommended that transactions with the same priority fee be sorted by time the transaction was received to protect the network from spamming attacks where the attacker throws a bunch of transactions into the pending pool in order to ensure that at least one lands in a favorable position.  Miners should still prefer higher gas premium transactions over those with a lower gas premium, purely from a selfish mining perspective.","specSection":"Security Considerations > Transaction Ordering","specUrl":"https://eips.ethereum.org/EIPS/1559#transaction-ordering","designImplication":"Do not promise exact ordering from a priority preset; communicate queue uncertainty when many transactions share the same tip."},{"id":"base-fee-supply","constraint":"Burning the base fee means Ether supply is not fixed and may be inflationary or deflationary depending on demand and rewards.","appliesTo":"application","normativity":"security-considerations","specQuote":"### ETH Burn Precludes Fixed Supply\nBy burning the base fee, we can no longer guarantee a fixed Ether supply.  This could result in economic instability as the long term supply of ETH will no longer be constant over time.  While a valid concern, it is difficult to quantify how much of an impact this will have.  If more is burned on base fee than is generated in mining rewards then ETH will be deflationary and if more is generated in mining rewards than is burned then ETH will be inflationary.  Since we cannot control user demand for block space, we cannot assert at the moment whether ETH will end up inflationary or deflationary, so this change causes the core developers to lose some control over Ether's long term quantity.","specSection":"Security Considerations > ETH Burn Precludes Fixed Supply","specUrl":"https://eips.ethereum.org/EIPS/1559#eth-burn-precludes-fixed-supply","designImplication":"If a product explains supply or fee burn, label it as chain/economic context and avoid a fixed-supply claim."}],"keyTakeaways":["EIP-1559 = base fee + priority fee + max fee on compatible networks","Show an estimated total and the applicable maximum with the network name","On Ethereum, explain burn and gas-used × effective price; on Monad, explain gas-limit × price per gas","Do not carry Ethereum's adjustment, burn, or recipient claims onto Monad","Use current chain estimates; avoid hardcoded capacity, fixed gwei, and USD fee examples"],"technicalNotes":"EIP-1559 introduces type-2 transactions with maxFeePerGas (ceiling) and maxPriorityFeePerGas (tip). On Ethereum, the effective gas price is min(maxFeePerGas, baseFee + maxPriorityFeePerGas), the base fee is burned, and effective_gas_price * gas_used is the fee calculation. Monad supports EIP-1559-compatible type-2 parameters with price_per_gas = min(base_price_per_gas + priority_price_per_gas, max_price_per_gas), but its gas-paid rule is gas_limit * price_per_gas and its base-price controller differs. Monad's gas-pricing documentation does not establish Ethereum's burn or universal recipient wording; keep those chain-qualified and do not hardcode capacity or current fixed gwei/USD examples."},"sources":[{"label":"Official specification","url":"https://eips.ethereum.org/EIPS/eip-1559","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=EIP-1559","type":"discussion"},{"label":"Monad gas pricing documentation","url":"https://docs.monad.xyz/developer-essentials/gas-pricing","type":"reference"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/EIP-1559","markdown":"https://www.eipsfordesigners.com/standards/EIP-1559/content.md","agent":"https://www.eipsfordesigners.com/standards/EIP-1559/agent.md","api":"https://www.eipsfordesigners.com/api/standards/EIP-1559","official":"https://eips.ethereum.org/EIPS/eip-1559","discussion":"https://ethereum-magicians.org/search?q=EIP-1559"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}