Let’s get to know the current EIP process (as documented in EIP-1):
We intend EIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Ethereum.
Three types of EIP
- Standard Track EIP
- ERC - application-level standards and conventions
Informational EIP - design issue, or provides general guidelines or information to the Ethereum community
Meta EIP - procedures, guidelines, changes to the decision-making process, and changes to the tools
EIP Work Flow
The EIP process begins with a new idea for Ethereum.
- Each EIP must have a champion
- A draft EIP should be presented as a pull request
Standards Track EIPs consist of three parts, a design document, implementation, and finally if warranted an update to the formal specification.
- It must be a clear and complete description of the proposed enhancement.
- The enhancement must represent a net improvement.
- The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.
Once an EIP has been accepted, the implementations must be completed. When the implementation is complete and accepted by the community, the status will be changed to “Final”.
What belongs in a successful EIP?
- Simple Summary
- Backwards Compatibility
- Test Cases
- Copyright Waiver
EIP Editor Responsibilities and Workflow
For each new EIP that comes in
- Read the EIP to check if it is ready: sound and complete.
- Edit the EIP for language
Once ready for the repository:
- Assign an EIP number
- Accept the corresponding pull request
- List the EIP in README.md
The editors don’t pass judgment on EIPs. We merely do the administrative & editorial part.