--- layout: default title: Home ---

EIPs

Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards.

Contributing

First review EIP-1. Then clone the repository and add your EIP to it. There is a template EIP here. Then submit a Pull Request to Ethereum's EIPs repository.

EIP status terms

Draft - an EIP that is open for consideration.
Accepted - an EIP that is planned for immediate adoption, i.e. expected to be included in the next hard fork (for Core/Consensus layer EIPs).
Final - an EIP that has been adopted in a previous hard fork (for Core/Consensus layer EIPs).
Deferred an EIP that is not being considered for immediate adoption. May be reconsidered in the future for a subsequent hard fork.

EIP Types

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

Standard Track ({{site.pages|where:"type","Standards Track"|size}})

Describes any change that affects most or all Ethereum implementations, such as a change to the 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 Standard EIPs can be broken down into the following categories.

Core ({{site.pages|where:"type","Standards Track"|where:"category","Core"|size}})

Improvements requiring a consensus fork (e.g. EIP5, EIP101), as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions (for example, EIP90, and the miner/node strategy changes 2, 3, and 4 of EIP86).

Networking ({{site.pages|where:"type","Standards Track"|where:"category","Networking"|size}})

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

Interface ({{site.pages|where:"type","Standards Track"|where:"category","Interface"|size}})

Includes improvements around client API/RPC specifications and standards, and also certain language-level standards like method names (EIP6) and contract ABIs. The label “interface” aligns with the interfaces repo and discussion should primarily occur in that repository before an EIP is submitted to the EIPs repository.

ERC ({{site.pages|where:"type","Standards Track"|where:"category","ERC"|size}})

Application-level standards and conventions, including contract standards such as token standards (ERC20), name registries (ERC137), URI schemes (ERC681), library/package formats (EIP82), and wallet formats (EIP85).

Informational ({{site.pages|where:"type","Informational"|size}})

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.

Meta ({{site.pages|where:"type","Meta"|size}})

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. Any meta-EIP is also considered a Process EIP.