EIPs & ERCs

Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards. Network upgrades are discussed separately in the Ethereum Project Management repository.

Contributing

First review EIP-1, then clone the repository and add your proposal to it. There is a template here. Finally, submit a pull request to the ethereum/EIPs or ethereum/ERCs repository, as appropriate.

Proposal Statuses

• Idea: An idea that is pre-draft. This is not tracked within a repository.
• Draft: The first formally tracked stage of a proposal in development. A proposal is merged as a Draft by an EIP Editor into either the EIP or ERC repository when properly formatted.
• Review: An EIP Author marks their proposal as ready for and requesting peer review. Proposals at this stage are fully specified, but still subject to significant change.
• Last Call: An EIP Author marks their proposal as complete and begins the last review window (last-call-deadline, typically 14 days) before moving to Final. If the review window passes without significant changes, the proposal can advance to Final, otherwise it should return to Review or Draft.
• Final: This proposal represents the completed standard. A Final proposal is, with few exceptions, immutable. It should only be updated to correct errata and add non-normative clarifications.
• Withdrawn: An EIP Author has withdrawn the proposal. This state is immutable, and the proposal can no longer be resurrected using its same number. If the idea is pursued at later date it will be considered a new proposal, with a new number.
• Living: A special status for EIPs that are designed to be continually updated and not reach a state of finality. This includes, most notably, EIP-1.

Proposal Types

Proposals are separated into a number of types, and each has its own list.

Standards Track

Describes any change that affects most or all Ethereum implementations, such as a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Ethereum. Furthermore Standards Track proposals can be broken down into the following categories.

Core

Improvements requiring a consensus fork (e.g. EIP-5 or EIP-211), as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions (for example, the PoA algorithm for testnets described in EIP-225).

Networking

Includes improvements around devp2p (EIP-8) and Light Ethereum Subprotocol, as well as proposed improvements to network protocol specifications of whisper and swarm.

Interface

Includes improvements around client API/RPC specifications and standards, and also certain language-level standards like method names (EIP-6) and contract ABIs.

ERC

Application-level standards and conventions, including contract standards such as token standards (ERC-20), name registries (ERC-137), URI schemes (ERC-681), library/package formats (ERC-190), and account abstraction (ERC-4337).

Meta

Describes a process surrounding Ethereum or proposes a change to (or an event in) a process. Process EIPs are like Standards Track EIPs but apply to areas other than the Ethereum protocol itself. They may propose an implementation, but not to Ethereum's codebase; they often require community consensus; unlike Informational EIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Ethereum development.

Informational

Describes a Ethereum design issue, or provides general guidelines or information to the Ethereum community, but does not propose a new feature. Informational EIPs do not necessarily represent Ethereum community consensus or a recommendation, so users and implementers are free to ignore Informational EIPs or follow their advice.