Reviewing the current EIP process


I will be attending and presenting at Exploring 721 in Dallas next weekend (discussing ERC-721). One of the topics is reviewing the standards process.

Maybe I am not the most qualified to speak on this panel, but I will do my best to inspire the next round of EIP contributors.

I hope this thread can be active in the next week so that I may learn more and be useful at the event. Of course you are all welcome to attend.


Thanks @fulldecent, this is a great opportunity to educate people in the community about the process and then to get them involved.


Here’s all my open questions, and others I’ve heard about the current EIP-1:

  1. Who assigns the editors?
  2. Are the term limits or any other qualifications or restrictions on editor participation?
  3. How does the champion summon an editor to initiate review?
  4. What is the “Ethereum philosophy”?
  5. How do you get from draft to final?
  6. How do you “win” as an EIP author?

Here is every problem I see with the current process:

  1. There is a strong incentive for anybody who has an interface in their program to go and standardize that interface. This results in a heaping pile of ERCs for use cases that are imagined at best. Personally I have a much higher threshold for use cases and consensus.
  2. Because of the noise, it is difficult for interested and useful people to find EIPs that have a reasonable chance of passing.
  3. The needs of the deciding stakeholders (“the community”? Ethereum Foundation? people with commit access to ethereum/EIPs?) are not well documented. Personally for any open source project I work with, it is nice to know you are working on a welcome problem before sending a pull request.
  4. The identity of the stakeholder is unclear. If [ the Ethereum Foundation will decide on EIPs during the Project Management/All Core Devs meetings and if that meeting sets the direction of go-ethereum/Parity and if those projects are critical for Ethereum ] then effectively only the people that can vote there matter. It should be more clear whether this is the case.
  5. The process to amend EIP-1 is not defined.


One issue is that the notion of a “mature” draft is ill-defined. There should probably be a status called Ready which means that the Editors have approved it so far as meeting editorial standards, and the author believes it is ready for consideration by the core developers.

  • Authors will likely not move a proposal forward absent consensus by the Fellowship, but (again) the Fellowship has no power here, it is the author’s proposal and the author’s choice.
  • Alternatively, the Editors can choose not to move a proposal to Ready status absent Fellowship consensus. Though again, anyone is free to submit proposals to the core devs independently.


I’ve written up an EIP draft proposing a revision to the EIP process here. Feedback appreciated.


Useful “flow chart for how changes are currently made to the Ethereum platform”, tweeted by Dan Finlay:


Has there been any suggestion about an EIP status called ‘Withdrawn’?

There’s been discussion about ‘closing’ EIPs if they never enter Final Call or if the do enter Final Call but get rejected, but there doesn’t seem to be a way to remove an EIP from active consideration.

The reason this matters to me is, if one thinks about new entrants to the space, whose best way to learn about what’s going on in a deeply technical way is to read every comment on every EIP, it would be helpful if they could easily identify EIPs that have little or no chance of ever becoming part of the spec (to the extent that there is a spec).

If there was a status called ‘Withdrawn’ the author could, much like moving an EIP to ‘Final Call’ simply move the EIP to ‘Withdrawn.’ The Core Devs then have a bit of an easier path. If they simply ignore the EIP, or speak about it briefly and don’t suggest that the author moves it forward, then hopefully, the author will get the idea that it’s best to move the EIP to withdrawn.

The header of withdrawn EIPs could be colored pink or something to make them obvious.