Analysis of EIP-1559

If implemented, Ethereum improvement proposal (EIP) 1559 will be the largest change to how users bid for blockspace in any of the major blockchains. While the proposed rules are relatively simple, the proposal would mean significant changes for users, miners, and wallet providers, and even affect the security of Ethereum overall.

In this analysis, we untangle the different building blocks of the proposal to make it easier to reason about. We then analyze the proposal against its own design goals. Finally, we look into possible weaknesses.

Design goals

1. Better UX: First price auctions, as used by blockchains like Bitcoin and Ethereum, are easy to understand and implement, but also inefficient. (If you want to learn more, there are good explainers here and here). One of the biggest problems is fee estimation. EIP-1559 seeks to solve this by having all transactions pay the same fee rate, most of the time. Users would have to decide whether to pay the fee or not, but no longer how much to bid. This hopefully leads to lower fees due to better fee estimation.
2. Slack mechanism: Demand for blockspace can be volatile. As a result, some blocks are half-full while others are highly congested. A slack mechanism would allow some blocks to be larger, as long as other blocks are smaller. That way we could enforce a longer-term average blocksize limit, but allow for variation across individual blocks.
3. Better security: Blockchains that rely only on transaction fees for security (such as Bitcoin in the future) can run into problems when the block subsidy runs out. If transaction fees are burned, we could extend the block subsidy without increasing the overall coin supply.
4. Prevent economic abstraction: When users can pay transaction fees in any token (e.g. stablecoins), this could threaten the reserve status and hence monetary premium of the native token. By demanding that fees must be paid in Ether and then burning them, EIP-1559 seeks to make economic abstraction more difficult.

How it works

BASEFEE + Tip

As the first building block, a minimum fee called BASEFEE is commanded by the protocol.

Minimum fees are usually not enforceable since the protocol cannot prevent external price discovery for transaction inclusion. The protocol can always command a price, but if miners and users agree on a lower price, users can pay miners in-protocol, and miners can refund users off-protocol.

EIP-1559 solves this by burning the entire BASEFEE, so it cannot be refunded.

Since miners get none of the fee, users must incentivize them in a different way to include their transactions. This brings us to the perspective of users. When submitting transactions, users have to configure two values:

First, they determine a GAS_PREMIUM (from now on just called “tip”) as a bid for inclusion. Most often, it must only be high enough to compensate miners for the marginal increase in uncle risk (e.g. 1 Gwei). During times of congestion, it allows for the old first-price auction between transactors.

Second, users determine a FEECAP that represents the most they are willing to pay for inclusion (incl. the tip). This is necessary because BASEFEE can actually move up or down, as we will see in a minute, and users who set an insufficient FEECAP should be able to wait for inclusion in a later block.

In summary, BASEFEE allows the protocol to enforce a minimum fee without incentivizing the formation of an off-chain market. It serves as a foundation for more flexible blockspace utilization mechanisms, such as uniform price auctions and elastic block sizes.

Elastic blocksize cap

More flexibility in blocksize is desirable, but allowing an unbounded blocksize has known incentive problems. The ability to drive up uncle rates with larger blocks creates an incentive for miners to centralize. Further, validation costs must be contained so the network can remain trustless.

Here is where elastic block size mechanisms come in. The goal is to allow miners to make larger blocks, but only at a provable cost. Increased orphan rate on its own is not a provable cost, since it can be mitigated by increased centralization, but burning fees in-protocol is.

In EIP-1559, miners can periodically exceed the blocksize cap in order to react to burst demand, but will only do so if there is real user demand to pay for it. The BASEFEE primitive discourages miners from propping up their blocks with garbage transactions by introducing a real cost (the fee burn) for doing so.

Reacting to burst demand becomes possible because EIP-1559 replaces the existing hard cap on block size with two values: a long-term target of 10m gas per block and a new hard ceiling of 20m gas per block1.

Over the long-term, the network adjusts the BASFEE up and down to target the desired average blocksize. While blocks are under the target, the fee decreases over time to encourage demand. While blocks are over the limit, the fee increases over time to discourage demand. The size of the change is determined by the distance from 10m, but is capped at 12.5% in either direction per block.

In summary, the BASEFEE adjustment mechanism makes transacting more or less expensive for users to target the desired level of blockspace utilization.

Expected behavior

Better UX

To evaluate the UX for users and wallet providers, we have to consider the system in different states of congestion.

State of no congestion: Whenever blocks are below the maximum cap of 20m gas, there is no reason for users to increase their tips beyond the minimum. This remains true even as the BASEFEE adjusts up and down over time.

As a result, inclusion in blocks can be entirely determined by BASEFEE.

Users who are willing to pay the BASEFEE plus the minimum tip will get into the next block2. Whenever there is no congestion, users can buy blockspace at a fixed price. It’s the same experience as going to Amazon today and seeing a fixed price for the item you want versus having to bid for it in an auction. The user can then either take the deal or leave it. As a result, fee estimation for users and wallets becomes highly predictable.

Users can even set their FEECAP lower than the current BASEFEE to wait for inclusion in a later block when fees are lower.

State of occasional congestion: As blocks above 10M gas are mined, the BASEFEE starts to rise. In fact, it continues to rise until a block with 10M or below gas is mined. If the next block is 10M, the BASEFEE will stabilize at wherever the fee is at right now. If the next block is below 10M, the BASEFEE will start to decline.

This is an important realization. If blocks have been above 10m for some time, transacting can get very expensive, and this eventually pushes demand back down. How fast do transaction costs rise?

Consider a BASEFEE of 1 billion wei per gas at block 0. At an ETH price of 240, a typical 21k gas transaction costs 0.0005. After only 10 blocks of 20M gas, the transaction will cost 0.02. After 100 blocks, it will cost 657. This is the power of exponential growth.

As blocks approach the cap of 20M gas, we expect users with urgent transactions to engage in tip auctions because there is no longer a binary way for the protocol to determine priority among them (previously either a user was willing to pay BASEFEE or not).

As a result, in times of congestion the protocol falls back to the existing first-price auction model.

Even during a tipping auction, the size of BASEFEE remains predictable for transactors. If BASEFEE has a fictitious starting value of 100 at block 0, it can at most go to 100 * 112.5% at T1, to 100 * 112.5%2 at T2, to 100 * 112.5%3 at T3, and so on. The same applies to the case of the decreasing fee.

The colored area in Figure 2 illustrates the potential values the BASEFEE may receive in the future blocks based on its initial value (100 in this example).

State of extended congestion: It should be now clear that EIP-1559 allows for larger blocks for a short period of time, but not a longer period. After only 30 min of burst demand, the BASEFEE for a simple 21000 gas transaction will have surpassed $1000 (assuming initial BASEFEE = 1 Gwei).

The only way for BASEFEE to return to more “normal” levels is for blocks below 10m to be mined.

Imagine there have been 100 blocks with 20m gas in a row. To stick with the previous example, the cost of an average transaction has increased to $657 plus tip. For BASEFEE to return to its starting point, 89 empty blocks must be mined. Alternatively, we can also mine 183 blocks of 5m gas, 371 blocks of 7.5m gas, and so on.

Hence, a typical pattern under high congestion will be a series of large blocks followed by a series of very small to small blocks. This makes sense, as users with a high time-preference can now get their transactions mined faster. But eventually, the BASEFEE outgrows the demand from transactors, and they have to wait for BASEFEE to come down again.

Another way of thinking about this is that the slack mechanism pulls a number of blocks worth of capacity from the near future into the immediate present. But it can’t generate more capacity, eventually the debt has to be repaid.

Slack mechanism

After reviewing how EIP-1559 responds to congestion, we can see that its slack mechanism is closely tied to the maximum amount BASEFEE can change between blocks. The slower it adjusts, the more gracefully the system could handle variations in demand.

A common theme for such variations is the cyclicality of the day-night cycle or the weekday-weekend cycle. In its current form, EIP-1559 does not allow for blocks to be larger at night and bigger at days, because these periods are so long that fees would skyrocket into the billions of dollars during the day and equally swiftly fall close-to-zero during the night.

Hence the slack mechanism works on the time-frame of minutes to half an hour, but not beyond that. The longer demand pulls the block size into one direction, e.g. towards full blocks, the more violently it is pulled back by the rubberband of a rising BASEFEE.

Better security

Many blockchains have disinflationary monetary policy, meaning the number of new coins they issue goes down over time. When issuance drops low enough, transaction fees are supposed to pay for security. EIP-1559 is not compatible with such a fee-only security model, because the bulk of transaction fees wouldn’t incentivize miners but are burnt instead.

Hence, one could say that EIP-1559 assumes a perpetual block subsidy for miners for the protocol to be secure. But the better way of thinking about this would be to say that it makes perpetual block subsidy much more palatable as a design option. The reason is that the fee burn acts as a deflationary force on the coin supply, thereby allowing new coins to be issued elsewhere without inflating the overall supply.

Because protocols with perpetual block subsidy generate a more stable income stream for miners, it is fair to say that EIP-1559 has a positive effect on the long-term security and stability of Ethereum.

Prevent economic abstraction

Before EIP-1559, transaction fees technically didn’t have to be paid in ETH. While the network supports only fees paid in ETH, users could in theory pay miners in any currency they want out-of-band. But a miner can also be paid indirectly via MEV. For example, a miner could include a DEX transaction without any fees because he could make money elsewhere by front-running it.

EIP-1559 largely fixes this problem. The BASEFEE part of every transaction is denominated in ETH, and it always gets burned. In that case, ETH is removed from the coin supply, no matter who pays for it. A miner is still free to include lower BASEFEE transactions, but only if he pays the difference from his ETH-denominated block subsidy. The miner earns less ETH in that block, but the user retains more. So for the token supply, it’s a wash. Someone has to pay for the transaction in ETH.

We say “largely fixes this problem” because EIP-1559 can prevent economic abstraction of the BASEFEE, but not the tip. Since the tip isn’t burned, the protocol has no way to enforce how or where it is paid. The result is the same kind of off-chain market that is possible pre EIP-1559. However, as we have shown earlier, in most scenarios it is not necessary for users to raise their tips above the minimum.

Possible problems

One major concern with EIP-1559 is whether miners can manipulate the basefee, and whether they want to.

When the BASEFEE is zero, miners receive the entire bid from users since there is no burn. Remember also that a tip auction only starts to take place when the demand for blockspace exceeds the available supply.

Once fees are near zero, miners would have a simple strategy of keeping them there forever. If they never mine a block above 10m gas, the BASEFEE never increases either. If demand never exceeds 10m (or whatever limit below 10m the miners decided to set), miners will earn the entire fee.

However, what is best for miners as a group is not necessarily best for individual miners. This is known as the collective action problem. If blocks are capped at 10m gas, and there is demand to transact for 20m gas, it only takes one miner to break the coalition and include the tip-paying transactions anyway.

Turning this into a stable monopoly would require a miner-activated soft fork (MASF). In a MASF, over 50% of the hashrate would pledge to ignore any blocks larger than 10M gas, thereby incentivizing the minority to follow the newly implemented rules.

Since this attack vector exists on any network and at all times, we don’t perceive it as an EIP-1559 specific risk at this time.

Summary

We find that EIP-1559 largely holds what it promises. It should make fee estimation much more predictable except for very short periods of high congestion, where the system falls back on the established first-price auction model. These periods are bound to last minutes, because of how BASEFEE rises exponentially to throttle demand.

The benefits are made possible by BASEFEE as an interesting building block. Its ability to set minimum fees in the protocol opens a new design space, ranging from elastic blocksize, perpetual block subsidy, better resistance against economic abstraction, to better auction models going forward.

EIP-1559 is promising, but that does not mean it is also the best it can be. We only evaluated the existing set of parameters against its self-reported goals. Further research into different configurations of the mechanism would be a good idea.

If you want to replicate our numbers and graphs or run your own experiments, we made our code available on GitHub.

Acknowledgments: Su Zhu, Patrick McCorry, John Adler, Nick Johnson, Dankrad Feist, Tarun Chitra, James Prestwich, and Caleb Tebbe