Ethereum Governance

New features, protocol changes, API changes, and contract standards are brought to Ethereum via Ethereum Improvement Proposals (EIP). The workflow is as follows:

EIP Workflow and Status terms

The diagram below outlines the workflow and status terms for EIPs.

1. Idea: An idea is a pre-draft version. It should be vetted by community feedback to save time. The Ethereum foundation suggests certain discussion channels.
2. Draft: An EIP with the status Draft is open for consideration. Changes and rapid iterations are common. It is the first formally tracked stage of an EIP. An EIP editor merged it into the EIP repository after checking the formatting requirements.
3. Review: An EIP is marked as ready for review by the community. The initial iterations are done. Now, a broad audience can review the draft.
4. Last Call: Last Call is the final review window for an EIP before the status is changed to final. The EIP editor sets the review end date (typically 14 days later) when assigning the status Last Call.
5. If changes occur, that cannot be fixed within the review-window, the status can be changed back to Review.
6. Accepted: After a core EIP has been in Last Call for at least two weeks and any technical changes that were requested have been addressed by the author this EIP gets the status Accepted. Now, the core developers decide upon whether to implement the EIP into their code or not.
7. Final (non-Core): After an EIP (non core) has been in Last Call for at least two weeks and any technical changes that were requested have been addressed by the author. It represents the final standard. The EIP should only be updated to correct minor errors like errata or adding non-normative clarifications.
8. Final (Core): Once the core developers have decided to implement the EIP, the status changes to Final. This requires the core developers to review this EIP. An author can present its EIP on an AllCoreDevs call.
9. Stagnant: If an EIP is in the state Draft or Review and inactive for at least six months is assigned as Stagnant. It can be moved back to DRAFT, once the work on this EIP is resumed.
10. Withdrawn: An author can withdraw its EIP. This state is final. If the author wants to continue working on it, it is considered as a new draft with a new EIP number.
11. Living: Living is a special state for EIPs that are designed to be continually updated. They don’t reach the state Final. Updates to such an EIP cause it to be moved to Review.

EIP Types and Categories

You can get an idea of an Ethereum Core Devs Meeting here:

There are different EIP types and subcategories, which we will explain here briefly.

• Standard Track EIP

Standard Track EIPs affect most or all Ethereum implementations. They comprise changes of the network protocol, changes of block or transaction validity rules, application standards, and changes that affect interoperability of applications using Ethereum.

• Core: Includes changes that require a consensus fork or may be relevant to “core dev” discussions.
  • Networking: Changes around devp2p, Light Ethereum Subprotocol, Whisper, and Swarm
  • Interface: Changes that affect the API/RPC specifications and standards as well as ABIs, etc.
  • ERC: ERC stands for Ethereum Request for Comments. These are application-level standards and conventions. They include contract standards, name registries, URI schemes, library/package formats, and wallet formats.
• Meta EIP: Meta EIPs describe processes that do not directly affect code. They deal with process improvements, guidelines, procedures, and changes to the decision-making process. Users must not ignore meta EIPs.
• Informational EIP: Informational EIPs describe design issues of Ethereum. They also provide general guidelines or information to the Ethereum community. The community can ignore those EIPs since they don’t necessarily represent the Ethereum community consensus.

EIP Style Guide

EIPs must follow a style guide that defines what belongs to a successful EIP, and in what order each section must be included. It also provides a template for the formation and advises the author on including auxiliary files like images, diagrams, etc. The style guide provides guidance on how to refer to other EIPs.

The link to the EIP style guide is here: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1.md

Coordination among Ethereum Core Developers

Coordination among Ethereum Core developers is achieved through so-called All Core Dev Meetings. They aim to bring together all teams who play a major role in determining the Ethereum protocol development. During these meetings, participants discuss EIPs and provide updates on their projects.

Anyone can add a topic to the agenda. (This is done by opening an issue in a github repository)