<p>Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards.</p>
<p>First review <ahref="EIPS/eip-1">EIP-1</a>. Then clone the repository and add your EIP to it. There is a <ahref="https://github.com/ethereum/EIPs/blob/master/eip-X.md">template EIP here</a>. Then submit a Pull Request to Ethereum's <ahref="https://github.com/ethereum/EIPs">EIPs repository</a>.</p>
<li><strong>Draft</strong> - an EIP that is open for consideration.</li>
<li><strong>Accepted</strong> - an EIP that is planned for immediate adoption, i.e. expected to be included in the next hard fork (for Core/Consensus layer EIPs).</li>
<li><strong>Final</strong> - an EIP that has been adopted in a previous hard fork (for Core/Consensus layer EIPs).</li>
<li><strong>Deferred</strong> an EIP that is not being considered for immediate adoption. May be reconsidered in the future for a subsequent hard fork.</li>
<p>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.</p>
<p>Improvements requiring a consensus fork (e.g. <ahref="EIPS/eip-5">EIP5</a>, <ahref="EIPS/eip-101">EIP101</a>), as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions (for example, <ahref="EIPS/eip-90">EIP90</a>, and the miner/node strategy changes 2, 3, and 4 of <ahref="EIPS/eip-86">EIP86</a>).</p>
<p>Includes improvements around devp2p (<ahref="EIPS/eip-8">EIP8</a>) and Light Ethereum Subprotocol, as well as proposed improvements to network protocol specifications of whisper and swarm.</p>
<p>Includes improvements around client API/RPC specifications and standards, and also certain language-level standards like method names (<ahref="EIPS/eip-6">EIP6</a>) 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.</p>
<p>Application-level standards and conventions, including contract standards such as token standards (<ahref="EIPS/eip-20">ERC20</a>), name registries (<ahref="EIPS/eip-137">ERC137</a>), URI schemes (<ahref="EIPS/eip-681">ERC681</a>), library/package formats (<ahref="EIPS/eip-82">EIP82</a>), and wallet formats (<ahref="https://github.com/ethereum/EIPs/issues/85">EIP85</a>).</p>
<p>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.</p>
<p>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.</p>