EEPs

EOSIO Enhancement Proposals (EEPs) describe standards for EOSIO platforms, including core protocol specifications, client APIs, and contract standards.

Contributing

First review EEP-1. Then clone the repository and add your EEP to it. There is a template EEP here. Then submit a Pull Request to EOS Canada's EEPs repository. (this repo shall be changed once a permanent repo is determined)

EEP status terms

• Draft - an EEP that is open for consideration.
• Accepted - an EEP that is planned for immediate adoption.
• Final - an EEP that has been adopted previously.
• Deferred an EEP that is not being considered for immediate adoption. May be reconsidered in the future.

EEP Types

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

Standard Track (0)

Describes any change that affects most or all EOSIO 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.

Core (0)

Improvements requiring a consensus fork, as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions.

Networking (0)

Includes improvements around devp2p, as well as proposed improvements to network protocol specifications.

Interface (0)

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.

EEP (0)

Application-level standards and conventions, including contract standards such as token standards, name registries, URI schemes, library/package formats, and wallet formats.

RFC (4)

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

Meta (1)

Describes a process surrounding EOSIO 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 EOSIO protocol itself. They may propose an implementation, but not to EOSIO'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 EOSIO development. Any meta-EEP is also considered a Process EEP.