EIP-1559 Community Outreach Report

This report was co-authored by Pooja Ranjan and Tim Beiko. Along with them, William Schwab, Alita Moore and Edson Ayllon also helped with community outreach.

Key Findings

• Projects’ general impression of EIP-1559 was equally split between being positive and negative (with a minority being neutral). If we exclude miners from this, 60% of projects were generally positive, and there were twice as many projects who were neutral than were negative.
• The main benefits that projects see with EIP-1559 are the predictability of gas prices, especially for projects who set them for their users, and the fact that ETH is burnt in each transaction.
• The main issues that projects found with EIP-1559 were its negative impact on miners, the fact that the proposal is hard to thoroughly analyze and potential implementation or tooling issues.
• Proper tooling, clear communications, good documentation and public testnets would all help projects add support for EIP-1559, but many projects still want the EIP to be scheduled for a network upgrade before they invest significant time implementing the EIP.
• Wallets and Exchanges represented a low volume of participant responses. Subsequent community outreach should focus on these two types of projects.
• In our calls with projects, several questions repeatedly came up. These are answered in an FAQ at the end of this report.

Background

Over the past few months, a lot of progress has been made on EIP-1559 [1], a proposal to reform Ethereum’s fee market. While it could bring significant UX and economic benefits to Ethereum, this EIP changes several fundamental parts of the protocol, including block headers, the transaction format and the transaction pool. In the last implementers’ call, the need to better understand the impact of these changes on projects and to gauge community sentiment around EIP-1559 was highlighted. This led to the decision of having a more structured approach to community outreach for this particular EIP.

Shortly after, the Ethereum Cat Herders put together a community outreach questionnaire and had several 1:1 meetings with projects building on Ethereum. The meetings allowed us to answer projects’ questions about EIP-1559, gather their feedback on the proposal and discuss what can be done to make it easier for projects to add support for it. This report shares the aggregated feedback from both the meetings and form responses collected by Wednesday, October 8 2020.

[1] For an overview of EIP-1559, see this recent explainer and Vitalik’s FAQ.

Participants Overview

In total, 25 projects shared their thoughts on EIP-1559. Of these, 15 shared them via the questionnaire and the other 10 had video calls with us. Most projects did not want to be cited directly in the final report, and one wanted to stay fully anonymous so their data is not part of the report.

The projects who were fine being cited as having participated in the study were Gitcoin, Argent, Infura, Kyber Network, ethers.js, POAP, TrueBlocks, Bitfly (etherchain.org/beaconcha.in), Nanopool and 0xBitcoin.

We asked projects to identify as one of the following categories: On-Chain Application, Wallet, Exchange, Miner and Other Tool or Infrastructure. The breakdown in responses is shown below:

Self-reported category by projects

It is worth highlighting both the high percentage of responses provided by miners and the low participation rate of wallets and exchanges. The only exchange that participated, was a DEX, Kyber Network. When appropriate, this report will separate out miners’ feedback from other projects for clarity. Subsequent outreach will place an emphasis on contacting more exchanges and wallets.

General Awareness and Thoughts on EIP-1559

All the projects we were in contact with were aware of EIP-1559, with almost half of them following the latest developments on the EIP. The most common way people stayed up to date with the EIP was via Twitter. Other popular ways to keep track of the latest updates were Github, Discord, Ethereum Magicians and the EIP-1559 implementers’ calls. Almost every project we talked to used multiple sources to stay updated on EIP-1559.

When asked what their general impression of EIP-1559 was, 10 projects (42%) had an overall positive impression of EIP-1559, 4 (17%) were neutral or not informed enough to have an opinion and 10 (42%) had an overall negative impression of the EIP. Miners as a group were the most negative, with 8/9 (89%) of responses being negative. If we exclude miners, then 9/15 (60%) of respondents had a positive impression of EIP-1559.

Benefits of EIP-1559

When asked what benefits they expected EIP-1559 would bring, respondents most frequently listed these two:

1. Gas price predictability (7 mentions): Projects were generally happy that EIP-1559 would allow them to reliably set correct gas prices. Projects who set gas prices for their users were especially positive about this.
2. ETH burn (5 mentions): The burning of the base fee was mentioned frequently as a benefit of the EIP, even in cases where the respondents didn’t seem to value this benefit themselves (e.g. “people like EIP-1559 because it burns ETH”).

Along with these two, other benefits mentioned were the lowering of fees, better incentive alignment across the network, not having all excess transaction fees going to miners, and quicker transaction inclusion for users. Given that EIP-1559 is not intended to lower fees on Ethereum dramatically, it may be worth making that explicit in future communications about the EIP.

Risks of EIP-1559

When asked what risks they saw with EIP-1559, the three most frequently cited risks were:

1. Negative impact on miners (10 mentions): Almost all the miners answering the survey mentioned that EIP-1559 would negatively impact them and that they would consider mining on another chain than Ethereum if it went through. Some miners suggested that 1559 would be better as part of Ethereum 2.0 exclusively. Other mining concerns included potential collusion between miners, miners not upgrading their clients to support the EIP, and centralization of mining risks if small miners are pushed out of Ethereum.
2. Difficulties analyzing the EIP (7 mentions): The second major concern (first if we exclude miners’ responses) was the difficulty of analyzing EIP-1559. This was brought up in several contexts: the lack of a formal specification or proof for the mechanism that people can independently evaluate and critique, the fact that EIP-1559 touches many parts of Ethereum and second-order effects are hard to predict, and the fact that it may be impossible to properly test the incentive design of the EIP until it is live on mainnet, with real ether at stake.
3. Implementation issues (6 mentions): Implementation issues both at the client and tooling level was the third most cited risk. Specifically, respondents were concerned that if there are no standard APIs for EIP-1559, it may make handling multiple clients harder than it currently is. There were also concerns about tooling breaking when EIP-1559 goes live and around the ease with which tooling developers can test their conformance with the EIP.

Other Notable Concerns

These concerns were not necessarily raised frequently but were noteworthy enough to include in this report for the attention of implementers and researchers. Note that we did not try to refute any of these concerns or validate their soundness. All legitimate-sounding concerns raised throughout the interviews are listed here.

Effectiveness Concerns

• Due to the base fee increasing 12.5% per block, and hence going up ~100,000x in 30 minutes, there is a mismatch between EIP-1559’s adjustment period and the spikes in usage we see on the network (typically lasting hours to days). Hows does EIP-1559 help with the next UNI token launch, Maker liquidation crisis, etc.?
• EIP-1559 is trying to do too many things at once: improve UX and create a deflationary pressure. Why do we not split these two goals into separate EIPs to make it easier to analyze?
• Does EIP-1559 reduce the net usable block space? Nodes will need hardware able to process the largest theoretical block but will, on average, only process blocks half that large.
• What if people keep using legacy transactions instead of 1559-style ones because it is simpler for them to do so?

Mining Concerns

• Is there a way for miners to collude to keep the base fee high or low, or otherwise incentivize users to provide a larger tip? How do we prove that?
• Miners/stakers have nothing to lose by colluding to drive the base fee to 0. This does not have the same negative effects on users and the ecosystem like miners colluding for 51%-style attacks.
• Reduced incentives for miners can lead to more ASICs on the network.
• BribeProxy contracts, which forward more fees out-of-protocol to the coinbase, could become common.

Tooling Concerns

• Will the tx.gasPrice opcode be deprecated? Will smart contracts using this opcode who want to leverage EIP-1559 need to be rewritten? It was frequently noted that while rewriting the contracts may not be a lot of work, it would require projects to have them re-audited, which can have significant costs and cause delays.
• It will require a lot of work for some tools to implement. And in some cases, if they drop the legacy transaction format in the latest version, it is difficult for them to go back to an older version in case the new transaction type is not well accepted by the users and they continue to use the older version.

Implementation Concerns

• Keeping both types of transactions (legacy and 1559) adds a lot of complexity to Ethereum.
• Will EIP-1559 increase the risk of denial of service (DoS) attacks on Ethereum?
• How does this impact transaction ordering? What are the second-order effects?
• What are the effects of EIP-1559 on the various parts of the client stack, like devp2p, the mempool, the database, etc.?
• Can the problems EIP-1559 tries to address be solved at the client level, without requiring a consensus change?
• The implementation will be too complex for EIP-1559 to ever go live.

Economic Concerns

• There is no research on the economics side explaining the impact of burning the base fee.
• Why increment the base fee by 12.5% and not another value?
• There is no incentive to exploit issues in EIP-1559 prior to it being live on the mainnet.

Political Concerns

• What if miners do not want to upgrade to support EIP-1559?
• How can we be sure that there is significant enough support for EIP-1559 to go ahead with such a large change?

It would be valuable for implementers and researchers to try and address or refute these concerns.

Alternatives to EIP-1559

When asked about alternatives to EIP-1559, the only alternative proposal that some respondents were aware of was EIP-2593, a.k.a. “Escalator fees”, proposed by Dan Finlay of MetaMask.

Implementation Willingness & Blockers

Respondents were asked what changes their projects would have to do to support EIP-1559, how long they expected to spend doing those changes and whether the EIP champions could do anything to make the process easier for them.

Here is a list of changes projects listed they would have to do to support EIP-1559:

1. Rewrite block reward calculations;
2. Rework transaction handling logic, including updating serialization and parsing libraries;
3. Update mining pool software;
4. Re-write contracts to use new opcodes and remove usage of deprecated ones;
5. Ensure that third-party dependencies still function (i.e. Chainlink oracles);
6. Rework “gas abstraction” feature for users to take 1559-style transactions into account;
7. Update client software;
8. Change the API used to estimate gas prices;
9. Re-work UI to conform with 1559-style transactions;
10. Adapt to changes in clients’ RPC interfaces;
11. Extensive testing/QA using 1559-enabled testnets and other available resources;
12. Changes to API used to share block and transaction data to users.

Most changes mentioned were project-specific. To preserve projects’ privacy, the above list aggregates similar changes mentioned by projects and is meant to give a qualitative overview of the impact of 1559 on existing projects.

When asked what would help them prioritize EIP-1559 support, the most frequent answers were the following:

1. Testnets (5 mentions): Having a public EIP-1559 testnet, which is suitable for applications to use (e.g. has JSON RPC support for 1559) would be the first step for most projects to begin their implementation. Some projects would be eager to use any public EIP-1559 testnet, while others would rather wait for testnets they already support (e.g. Ropsten, Goerli, etc.) to add EIP-1559 support.
2. Network Upgrade Inclusion (3 mentions): Several projects mentioned that they would want to wait until EIP-1559 has been properly accepted for a network upgrade before starting their work implementing it. It is not worth it for these projects to implement something that is not guaranteed to be on the mainnet.
3. Incentives (3 mentions): Several projects mentioned that incentives to use EIP-1559 (e.g. lower gas prices) would push them to implement it sooner.

Other things mentioned by projects were updated tooling (i.e. ethers.js or web3.js support for EIP-1559), relevant RPC endpoints in clients, clear opcode definitions and deprecation schedules, a public API endpoint to estimate the next block’s base fee, proper documentation, clear communications, channels for support, and, again, proper economic modeling for the EIP.

Similarly, respondents were asked what would cause them to hold off implementing EIP-1559. The most common response, in this case, was “nothing” (7 mentions), indicating a strong desire to support the EIP. In order of frequency, here are the potential concerns that were raised:

1. EIP/Spec Issues (3 mentions): If early efforts from clients find major issues in the spec, projects would take this as a red flag to hold off implementing EIP-1559 support until these are resolved.
2. Uncertainty of Mainnet Deployment (2 mentions): Similarly to how some projects wanted to see EIP-1559 included in a network upgrade to prioritize its implementation, others noted that uncertainty around mainnet inclusion would cause them to hold off on their implementation.
3. Competing Priorities (2 mentions): Some projects mentioned that other high priority features they are working on could potentially add more value to their users than supporting EIP-1559 and would prioritize implementing those first.
4. Poor Documentation & Support (2 mentions): If it is unclear for projects how to add support for EIP-1559, how to test it properly and where to go if they have issues, some of them would hold off adding EIP-1559 support until that was in place.
5. Lack of Community Support (2 mentions): Some projects mentioned that if they perceive some opposition to EIP-1559, they would be reluctant to add support for it, both because of the potentially wasted effort, and also because they do not want to get involved in politics.

Aside from these, other potential concerns mentioned were poor testnet support, lack of adapted tooling, the possibility of simply using legacy transactions for as long as possible and the impossibility of testing the economics of EIP-1559 prior to a mainnet deployment.

Finally, it is worth noting that some respondents who are very opposed to EIP-1559 mentioned they would not implement it under any circumstances. 6/7 (~86%) of these were from miners.

Implementation Timelines

We asked projects when they would start working on adding support for EIP-1559, how much time they expected to invest to do so and how long they would want to see legacy transactions supported once EIP-1559 was live on mainnet.

When would your project begin working on adding EIP-1559 support?

Most of the respondents were willing to start implementing changes when the EIP is live on existing testnets. Again, many projects mentioned that while the EIP would not require major changes in terms of development, it could lead to having to re-audit parts of their code, which would add both time and costs to the process.

This is also supported by the responses on another question: “How much time (for one full-time person) do you expect you will need to invest to support EIP-1559?”

We can see here that most projects expect to spend a relatively short amount of time to add support for EIP-1559.

Finally, there was a strong desire from projects to see legacy transactions supported for a long period of time on mainnet after EIP-1559 is live. More than half of the respondents mentioned they would like to see legacy transactions supported for over 12 months after 1559 goes live. This validates that a recent change to EIP-1559 to enable long-term support of legacy transactions is likely to be well-received by the broader community.

How long would you like to see pre-1559 transactions supported once EIP-1559 is deployed on mainnet?

Conclusion

This community outreach effort shows that while there is certainly excitement around EIP-1559 by a large number of projects, with over 60% of respondents wanting to see EIP-1559 deployed on mainnet in the next year, there is also some fear that the EIP is underspecified and notable pushback by miners against the EIP.

The number of concerns and questions raised highlight a need for more EIP-1559 explainers and potentially rebuttals against specific concerns. Finally, respondents made it clear that having frequent communications across multiple platforms, upgraded tooling and channels for support would go a long way towards helping them add support for EIP-1559.

We hope that this report is useful for the community! We will leave the questionnaire open for other projects wanting to share their thoughts and try to reach out to more wallets and exchanges to increase their sample size in this outreach study. An updated version of this report will be published once a sufficient number of additional projects have been contacted.

Frequently Asked Questions

Several questions came up repeatedly during the interviews conducted with projects. The questions and some answers are provided here for the community.

General comments & concerns

What is the motivation behind this proposal?

• The EIP details some of the motivations, and so does Vitalik’s recent FAQ.

Are there people opposed to the proposal?

• Yes, as this survey shows. There is no extensive list of opposers, but miners as a group seem most opposed. It is worth noting that there are also non-miners who oppose the proposal in its current form. Concerns included the lack of formal economic analysis or a preference for another alternative, such as EIP-2593.

Is there an alternate simpler proposal to handle transaction fee concerns?

• One alternate proposal is EIP-2593 which helps with better transaction sending UX but does not introduce a base fee that gets burnt.

Changes planned

What are the noticeable differences end users can expect?

• The EIP should make it easier for application developers to estimate gas prices for their transactions and users should see quicker inclusion of their transactions most of the time due to blocks almost always having extra space.

What changes will it bring from the smart contract developer’s perspective?

• The EIP will change the block header to add a field for the base fee and change the transaction format by removing the “gas price” field and introducing the “fee cap” and “tip” field.

Release plans

How will it be rolled out?

• The EIP will first be rolled out on ephemeral EIP-1559 testnets. Once it is proven to work, it will go through the network upgrade process and, if accepted, then be deployed on existing testnets and mainnet.

Is it backward compatible?

• No, the EIP will require a network upgrade to be activated and nodes will need to be updated to support this.

How would the network handle the legacy transaction, will there be a transition period?

• The original version of the EIP had a transition period where legacy transactions were slowly deprecated. The current version of the EIP allows legacy transactions to be included in blocks by treating their “gas price” as the “fee cap” and setting the difference between “fee cap” and “base fee” as the “tip” for miners. This means that legacy transactions will likely overpay for their tips, but will always be supported.

Gas Prices, Base Fees, Fee Caps and Tips

Will EIP-1559 raise/lower gas prices?

• EIP-1559 should not make gas prices consistently higher or lower. Gas prices are a function of demand for Ethereum block space. The EIP will make gas prices easier to predict (and helps users avoid overpaying), but it will not drive the “equilibrium price” of gas down. In other words, EIP-1559 won’t get us from 300 to 30 Gwei gas prices.

What is the base fee? What is the fee cap? What is the tip?

• The base fee is the minimum gas price a transaction must pay to be included in a certain block. It is set depending on how full or empty blocks are. If blocks are more than 50% full, it goes up, and if they are less than 50% full, it goes down. The base fee is the part of the transaction fee that is burnt.
• The fee cap is the maximum a transaction is willing to pay to be executed, including both the base fee and miner tip. It allows a user to set their fee cap higher than the current base fee if they suspect it will increase in the next block. The excess part of the fee cap (fee cap minus the base fee minus the tip) is returned to the user.
• The tip is the portion of the transaction fee that is sent to miners.