index.html

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

<h1 class="page-heading">EEPs


</h1>
<p>EOS Improvement Proposals (EEPs) describe standards for the EOSIO-based EOS mainnet, including core protocol specifications, client APIs, and contract standards.</p>

<h2>Contributing</h2>
<p>First review <a href="EEPS/eep-1">EEP-1</a>. Then clone the repository and add your EEP to it. There is a <a href="https://github.com/eoscanada/EEPs/blob/master/eep-X.md">template EEP here</a>. Then submit a Pull Request to EOS Canada's <a href="https://github.com/eoscanada/EEPs">EEPs repository</a>.</p>

<h2>EEP status terms</h2>
<ul>
  <li><strong>Draft</strong> - an EEP that is open for consideration.</li>
  <li><strong>Accepted</strong> - an EEP that is planned for immediate adoption.</li>
  <li><strong>Final</strong> - an EEP that has been adopted previously.</li>
  <li><strong>Deferred</strong> an EEP that is not being considered for immediate adoption. May be reconsidered in the future.</li>
</ul>

<h2>EEP Types</h2>

<p>EEPs are separated into a number of types, and each has its own list of EEPs.</p>

<h3>Standard Track ({{site.pages|where:"type","Standards Track"|size}})</h3>
<p>Describes any change that affects most or all EOS 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 EOSIO. Furthermore Standard EEPs can be broken down into the following categories.</p>

<h4><a href="{{"core"|relative_url}}">Core</a> ({{site.pages|where:"type","Standards Track"|where:"category","Core"|size}})</h4>
<p>Improvements requiring a consensus fork, as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions.</p>

<h4><a href="{{"networking"|relative_url}}">Networking</a> ({{site.pages|where:"type","Standards Track"|where:"category","Networking"|size}})</h4>
<p>Includes improvements around devp2p, as well as proposed improvements to network protocol specifications.</p>

<h4><a href="{{"interface"|relative_url}}">Interface</a> ({{site.pages|where:"type","Standards Track"|where:"category","Interface"|size}})</h4>
<p>Includes improvements around client API/RPC specifications and standards, and also certain language-level standards like method names and contract ABIs. The label “interface” aligns with the interfaces repo and discussion should primarily occur in that repository before an EEP is submitted to the EEPs repository.</p>

<h4><a href="{{"erc"|relative_url}}">EEP</a> ({{site.pages|where:"type","Standards Track"|where:"category","EEP"|size}})</h4>
<p>Application-level standards and conventions, including contract standards such as token standards, name registries, URI schemes, library/package formats, and wallet formats.</p>

<h3><a href="{{"RFC"|relative_url}}">RFC</a> ({{site.pages|where:"type","RFC"|size}})</h3>
<p>Describes a EOS design issue, or provides general guidelines or information to the EOS community, but does not propose a new feature. RFC EEPs do not necessarily represent EOS community consensus or a recommendation, so users and implementers are free to ignore RFC EEPs or follow their advice.</p>

<h3><a href="{{"meta"|relative_url}}">Meta</a> ({{site.pages|where:"type","Meta"|size}})</h3>
<p>Describes a process surrounding EOS or proposes a change to (or an event in) a process. Process EEPs are like Standards Track EEPs but apply to areas other than the EOS protocol itself. They may propose an implementation, but not to EOS's codebase; they often require community consensus; unlike RFC EEPs, 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 EOS development. Any meta-EEP is also considered a Process EEP.</p>