What is an Ethereum Improvement Proposal (EIP)?

Image 1

EIP stands for Ethereum Improvement Proposal. An EIP is a design document providing information to the Ethereum community, or describing a new feature for Ethereum or its processes or environment. The EIP should provide a concise technical specification of the feature and a rationale for the feature. The EIP author is responsible for building consensus within the community and documenting dissenting opinions.

There are three types of EIP:

  • Standards Track EIP: Describes any change that affects most or all Ethereum implementations, such as a change to the network protocol, block or transaction validity rules, proposed application standards/conventions, or any change that affects interoperability of applications using Ethereum. Standards Track EIPs include:
  • Meta EIP: Describes a process surrounding Ethereum or proposes a change to (or an event in) a process. These EIPs apply to areas other than the Ethereum protocol itself and often require community consensus. Examples include procedures, guidelines, and tools used in Ethereum development.
  • Informational EIP: Provides general guidelines or information to the Ethereum community but does not propose new features. Informational EIPs are non-binding recommendations and do not necessarily represent community consensus.

It is highly recommended that an EIP focuses on a single proposal or idea to ensure clarity and success. A clear and complete description of the proposed enhancement must be included, representing a net improvement without undue protocol complexity.

Special Requirements for Core EIPs: If a Core EIP mentions or proposes changes to the EVM, it should use instruction mnemonics and define opcodes, for example:

REVERT (0xfe)

EIP Workflow: Before drafting an EIP, it is crucial to vet the idea with the Ethereum community through platforms like the Ethereum Magicians forum. After obtaining feedback, the EIP author (or champion) must write the EIP, invite feedback from editors, developers, and the community, and gauge interest in the proposal.

  • For Core EIPs, presenting them on an AllCoreDevs agenda can help gain client implementer support and coordinate implementation for network upgrades.
  • Building community consensus is vital for the EIP process. Authors should ensure that discussions and feedback from stakeholders are well-documented and accessible.

The EIP process aims to foster collaboration and standardization, ensuring technical soundness and alignment within the Ethereum ecosystem.

EIP Process

Statuses

  • Idea: An idea that is pre-draft. This is not tracked within the EIP Repository.
  • Draft: The first formally tracked stage of an EIP in development. An EIP is merged by an EIP Editor into the EIP repository when properly formatted.
  • Review: An EIP Author marks an EIP as ready for and requesting Peer Review.
  • Last Call: This is the final review window for an EIP before moving to Final. An EIP editor will assign Last Call status and set a review end date (last-call-deadline), typically 14 days later. If this period results in necessary normative changes, it will revert the EIP to Review.
  • Final: This EIP represents the final standard. A Final EIP exists in a state of finality and should only be updated to correct errata and add non-normative clarifications.
  • Stagnant: Any EIP in Draft, Review, or Last Call that is inactive for 6 months or greater is moved to Stagnant.
  • Withdrawn: The EIP Author(s) have withdrawn the proposed EIP. This state has finality and can no longer be resurrected using this EIP number.
  • Living: A special status for EIPs that are designed to be continually updated and not reach a state of finality. This includes EIP-1.

*EIP Authors are notified of any algorithmic change to the status of their EIP*

What belongs in a successful EIP?

  • Preamble: Metadata about the EIP, including its number, title, and description.
  • Abstract: A concise, technical summary of the specification.
  • Motivation: *(Optional)* Explains why the existing specification is inadequate.
  • Specification: Describes the syntax and semantics of any new feature in detail.
  • Rationale: Explains design decisions and discusses alternate approaches.
  • Backwards Compatibility: *(Optional)* Describes incompatibilities, if any.
  • Test Cases: *(Optional)* Mandatory for EIPs affecting consensus changes.
  • Reference Implementation: *(Optional)* Provides example implementations.
  • Security Considerations: Discusses risks and security implications.
  • Copyright Waiver: All EIPs must be in the public domain.

EIPs should be written in Markdown format. Use the EIP Template.

Current EIP Editors

  • Matt Garnett (@lightclient)
  • Sam Wilson (@SamWilsn)
  • Zainan Victor Zhou (@xinbenlv)
  • Gajinder Singh (@g11tech)

Emeritus EIP editors

  • Alex Beregszaszi (@axic)
  • Casey Detrio (@cdetrio)
  • Gavin John (@Pandapip1)
  • Greg Colvin (@gcolvin)
  • Hudson Jameson (@Souptacular)
  • Martin Becze (@wanderer)
  • Micah Zoltu (@MicahZoltu)
  • Nick Johnson (@arachnid)
  • Nick Savers (@nicksavers)
  • Vitalik Buterin (@vbuterin)