# EIP 1559 FAQ ## What is EIP 1559 [EIP 1559](https://eips.ethereum.org/EIPS/eip-1559) is a proposal to reform the Ethereum fee market, with the following key changes: * The current gas limit is replaced by two values: a "long-term average target" (equal to the current gas limit), and a "hard per-block cap" (twice the current gas limit) * There is a BASEFEE (which is burned) which transactions are required to pay, which gets adjusted on a block-by-block basis with the goal of targeting a value so that average block gas usage remains at a level close to the current gas limit. Essentially, instead of all of the short-term volatility in demand for transaction space within a block translating into volatility in transaction fees, some of the volatility instead translates into volatility in block size. ## Why is EIP 1559 good? Copying from [an older post](https://github.com/zcash/zcash/issues/3473): ----------------------- There are three major problems with the status quo of transaction fee markets: * **Mismatch between volatility of transaction fee levels and social cost of transactions**: transaction fees on mature public blockchains, that have enough usage so that blocks are full, tend to be extremely volatile. On Ethereum, minimum fees are typically around 2 gwei (10^9 gwei = 1 ETH), but sometimes go up to 20-50 gwei and have even on one occasion gone up to over 200 gwei: https://etherscan.io/chart/gasprice. This clearly creates many inefficiencies, because it's absurd to suggest that the cost incurred by the network from accepting one more transaction into a block actually is 100x more when gas prices are 200 gwei than when they are 2 gwei; in both cases, it's a difference between 8 million gas and 8.02 million gas. * **Inefficiencies of first price auctions**: see https://ethresear.ch/t/first-and-second-price-auctions-and-improved-transaction-fee-markets/2410 for a detailed writeup. In short, the current approach, where transaction senders publish a transaction with a fee, miners choose the highest-paying transactions, and everyone pays what they bid, is well-known in mechanism design literature to be highly inefficient, and so complex fee estimation algorithms are required, and even these algorithms often end up not working very well, leading to frequent fee overpayment. See also https://blog.bitgo.com/the-challenges-of-bitcoin-transaction-fee-estimation-e47a64a61c72 for a Bitcoin core developer's description of the challenges involved in fee estimation in the status quo. * **Instability of blockchains with no block reward**: in the long run, blockchains where there is no issuance (including Bitcoin and Zcash) at present intend to switch to rewarding miners entirely through transaction fees. However, there are [known results](http://randomwalker.info/publications/mining_CCS.pdf) showing that this likely leads to a lot of instability, incentivizing mining "sister blocks" that steal transaction fees, opening up much stronger selfish mining attack vectors, and more. There is at present no good mitigation for this. EIP 1559 has these benefits: * It mitigates the economic inefficiencies from social cost mismatch due to fee volatility. There is a fairly nuanced economic argument here; see particularly pages 16-20 of the paper linked in https://ethresear.ch/t/draft-position-paper-on-resource-pricing/2838 (though I recommend reading the whole paper) for a detailed argument of why this is the case. Intuitively, the adjusting fee mechanism works like a fixed fee in the short run and a cap in the long run, and it turns out that because of [arguments from Martin Weitzman's 1974 paper](https://scholar.harvard.edu/weitzman/files/prices_vs_quantities.pdf) fixed fees are likely better than a cap in the circumstances that basically all public blockchains are in today and will likely continue to be in. * It replaces the auction with a fixed price sale (except during short periods where blocks fill up completely until fees catch up), eliminating first-price-auction inefficiencies and making fee estimation extremely simple: calculate the fee `f` for the next block, if you can afford it pay it, otherwise don't. * It creates a mechanism similar to a permanent block reward (the 1/N coming from the pot), mitigating many of the instability issues with fee-only blockchains without requiring actual permanent issuance. ----------------------- Another underrated benefit of EIP 1559 is that it makes gas prices _securely measurable_. Today, just looking at gas prices on chain and using them as an index is exploitable, because miners could include either very-low-fee or very-high-fee dummy transactions where the fee would go to themselves. But under EIP 1559, the BASEFEE can only be manipulated at high cost, as dummy transactions would requre even the miner to pay fees (that get burned). ## Are current fee markets really that inefficient? Yes. The difference between average gasprice and 10th percentile gasprice in a regular block is something like 3x for median and 5-8x for mean. People needlessly overpay massively. Everyone who does not overpay suffers a delay of 1-2 minutes or even longer, and this delay does not actually benefit anyone; the total load to the chain is the same regardless of whether a given unit of load hits the chain at time N or time N + 60. **There is no actual social benefit from participants "expressing a low time preference"** in the fee market mechanism, at least under normal conditions; it is pure deadweight loss. We would all be better off if more transactions were just included immediately, which EIP 1559 allows. ## Why not just use a second price(or kth price auction) to solve the first-price-auction inefficiencies? Kth-price auctions (where everyone pays a gasprice equal to the lowest gasprice that was included in the block) are indeed "efficient" in a traditional economic analysis*, but have the flaw that they are vulnerable to collusion. <small> \* Yes of course technically you want to use the _highest gasprice not included_ in the block; but in practice given that most ethereum blocks have hundreds of transactions the difference would be negligible.</small> ## Might EIP 1559 run the risk of over-stressing nodes and miners during periods of high usage? EIP 1559 can at most increase block size by 2x, even in the short term. Each "full block" (ie. a block whose gas is 2x the TARGET) increases the BASEFEE by 1.125x, so a series of constant full blocks will increase the gas price by a factor of 10 every ~20 blocks (~4.3 min on average). Hence, periods of heavy on-chain load will not realistically last longer than ~5 minutes. Note that currently, periods of double load that last 5 minutes already happen by random chance roughly once per ~63888 blocks (~10 days) because of variance in the rate of block production. So the introduction of EIP 1559 would not bring in any unprecedented level of load to the system. Additionally, the gas limit being only 12.5 million and not higher is justified to a large extent not by hard network limits (uncle rates are [near historic lows](https://etherscan.io/chart/uncles), though risks to non-miner nodes such as bootstrap nodes, may be higher), but by concerns that are fundamentally long-term in character: * Centralization risk of somewhat higher uncle rates: if uncle rates shoot up to 20%, that would disproportionately benefit well-connected large pools * Limits to state size * Difficulty of syncing after a short period offline In all three of these cases, what matters is not the upper bound on capacity within a very short window of time, but rather the long-term average capacity. Uncle rates being 2% during odd hours and 18% during even hours would have the same effect on all three of the above, as uncle rates always being 10%. Because EIP 1559 still bounds the long-run gas usage to a ~12.5 million per block average, it does not affect the long-term average. ## How would a spike of high usage look like under EIP 1559 compared to the status quo? Consider a "mathematically ideal spike" (eg. this could happen in real life because of a sudden market event leading to many arbitrage opportunities on DEXes, bidding on liquidated CDPs, etc), where N * 12.5 million gas worth of transactions, each with a very very high gasprice, are all broadcasted. Currently, this would lead to the following situation: * The next N blocks are filled exclusively with new spiky transactions * After that other transactions, as well as transactions that people send after the spike, get included in descending order of gasprice An average "normal user" would have to wait more than N blocks. Now, consider the situation under EIP 1559: * The next N/2 blocks are filled exclusively with new spiky transactions, each with twice the normal amount of gas * If all other transactions get sent with a gas price cap equal to the old gasprice, then the next N/2 blocks would be empty, and after that things would revert to normal. But realistically, higher-priority transactions would set higher gas price caps and get included first, and other transactions later. An average "normal user" would have to wait somewhere between N/2 and more than N blocks. Hence, even including the post-spike "recovery period" during which block capacity would be smaller than normal, most transactions get included sooner. Here's a very rough simulation (there are lots of strange assumptions here, but modeling a full system that covers both supply/demand curves *and* waiting times is hard); spreadsheet source [here](https://docs.google.com/spreadsheets/d/1iid0PnO5UTMECW2RylVwEOECFbW5iWsJSHmP4zj7Lr4/edit?usp=sharing). ### Status quo:  ### EIP 1559:  ## What would EIP 1559 do under larger and more prolonged spikes (eg. day-long spikes) Not much. The BASEFEE would rise and there would be a short period at the beginning where a few transactions get in faster, but after that the fee market would function just as it would under "ordinary" conditions, just at a higher fee level. The main benefit of EIP 1559 in spikes is that the harms from inefficiency of regular fee markets are magnified when fees are high, so having a functioning fee market becomes more important. ## If the chain _can_ handle 2x block size spikes, doesn't that mean the chain can handle just making _all_ blocks 2x larger? No. See this post for why: https://notes.ethereum.org/@vbuterin/eip_1559_spikes ## Why limit = target * 2? Why not 4? Or 8? It could easily be higher than 2. The higher the limit/target ratio the greater the fee market efficiency benefits of EIP 1559. It depends on how severe the short term spikes are that we are willing to accept; 2x is fairly conservative. We could even launch EIP 1559 with a limit/target of 2 to start off, and increase it over time as we see the network functioning okay even under short-term spikes. ## Why would miners include transactions at all? The EIP includes a "tip" that transaction senders can include, that goes to the miner. The tip has two functions: first, if there are suddenly far more transactions than expected, miners will include transactions with higher tips first, so the fee-based prioritization mechanism exists as a backup. Second, it compensates miners for uncle risk (the increased risk their block will not be included in the main chain because adding one more transaction will slow it down). The tip level that compensates for uncle risk has been calculated to be about 0.8 gwei (uncle blocks get on average a 1.67 ETH reward instead of the 2 ETH base, so that's a ~0.33 ETH = 330m gwei loss, 12.5 million gas blocks add ~0.031 to the uncle rate ckompared to empty blocks, so the expected cost of 1 gas is = 330m / 12.5m * 0.031 = 0.825 gwei) and miners do actually set about this value when the chain is empty. This tip level is independent of the BASEFEE, so client implementations can confidently set 1-1.5 gwei and expect their transactions to be accepted. ## How might wallets choose tips? Is there a risk of bidding wars for tips? Wallets could simply choose tips by looking at what tips have been accepted on chain historically, and increasing their tip if they see that a transaction they send was not accepted immediately. Note that in "normal conditions" there is no incentive to set a tip higher than the bare minimum. In cases of sudden congestion, tips _do_ degrade into a bidding war; wallets can detect congestion, and in this case they could offer users the option of setting low or high priority for their transaction. ## What is the escalator mechanism? How might the escalator mechanism be combined with EIP 1559? The escalator mechanism is a different proposed transaction fee reform, where instead of specifying a single fee, users specify their fee as a function, usually with a beginning, an increase-per-block and a maximum, for example "5 gwei if this transaction is included in block 10123456, add 1 gwei for every block after that (eg. 8 gwei if included in block 10123459), up to a maximum of 100 gwei". This would be four parameters: beginning fee, beginning block, per-block increment, max fee. The goal is to be "safer" against mistakes in fee estimation, as if the fee turns out to be too low it would naturally rise over time until the transaction is included. In an EIP 1559 context, this could be used to set the tip. The fact that the tip would generally be in a constant range means that even a wallet using fixed parameters for the escalator would deliver reasonably good outcomes to users. ## Won't miners have the incentive to collude to push down the BASEFEE by making all their blocks less than half full? In general, the effectiveness of such strategies is limited, because unless truly almost everyone colludes, a transaction not included in one block will get included will just get included in the next block and so the effect of this action on the long-run BASEFEE will be negligible. However, what miners _can_ do is a kind of "monopoly pricing". Suppose transaction senders are willing to pay some extra fee to avoid getting delayed one block. Miners can refuse to include transactions that do not include some minimum tip `T`; they lose out on some fee revenue, but gain from senders increasing their fees if they value the extra probability you will be the next miner and include their transaction highly enough. This strategy is heavily tilted against the miner: they suffer the full cost of lost fee revenue, but gain only a small portion of the increased transaction fees that others send. Note that even if a miner using such a strategy is successful, they will increase other miners' revenue more than it will increase their own revenue (as other miners free-ride on the higher tips due to your actions), so it is not a centralization vector. This will _not_ reduce BASEFEEs down to zero; rather, it will hit an equilibrium where BASEFEEs remain the bulk of the fee and tips take up the remainder. This is because unless miners are all colluding (in which case we have bigger problems), miners suffer the entire cost of not including transactions but gain only some of the benefit of tips being higher. **If the risk of miners deploying such a strategy is _still_ deemed unacceptably high, we can direct some (eg. 50%) of the revenue from EIP 1559 into a pool from which a small percentage is drained every block to be added to the miners' block reward**; this ensures miners benefit from the BASEFEE being high, further reducing the gains from such an attack. Here is a proposed sketch of a change to the EIP to do this: * Define the account 0x35 as `FEE_SMOOTHING_BUFFER`, and define `FEE_SMOOTHING_CONSTANT = 8192` * Add an additional term to the block reward (added at the same time as the base block reward and uncle+nephew rewards). Let `smoothing_reward = FEE_SMOOTHING_BUFFER.balance // FEE_SMOOTHING_CONSTANT`. Transfer `smoothing_reward` wei from `FEE_SMOOTHING_BUFFER` to `block.coinbase` * After applying the block rewards, 1/2 of EIP-1559 fees from that block (rounding down) get added to `FEE_SMOOTHING_BUFFER`'s balance. The remainder (ie. 1/2 rounding up) gets burned. Note that in a proof of stake context, it would be desirable to implement secret leader elections along with penalties for early revelation, to prevent validators from acquiring reputations as only accepting high tips and gaining the entire benefit of this themselves as transaction senders would know which validators are creating blocks soon. ### Other resources * The original paper: https://ethresear.ch/t/first-and-second-price-auctions-and-improved-transaction-fee-markets/2410 * ethresear.ch thread on Barnabe's simulations: https://ethresear.ch/t/eip-1559-simulations/7280 * Tim Roughgarden's report: http://timroughgarden.org/papers/eip1559.pdf