EEP stands for EOSIO Enhancement Proposal. An EEP is a design document providing information to the EOSIO community, or describing a new feature for EOSIO or its processes or environment. All EEPs should provide a concise technical specification of the feature as well as rationale for the feature. The EEP author is responsible for building consensus within the community and documenting dissenting opinions for the proposal.
An EEP must meet certain minimum criteria. It must provide a clear and complete description of the proposed enhancement and provide technical specification and use cases. The enhancement must also represent a net improvement to the EOSIO protocol and how it will benefit the community. Learn more about EEPs guidelines and submission requirements.
Draft: the EEP is currently a work in progress and has not yet been submitted
Submitted: the final draft of the EEP has been submitted by the EEP author
Ready for Review: the EEP has been reviewed by an EEP editor and has been added to the agenda for the next EEP review meeting
Accepted: the EEP was analyzed and discussed by the EEP reviewers and has sufficient support for implementation
Under Development: the EEP is currently under development
Pending PR Review: the EEP implementation is currently being reviewed for final acceptance
Final: the EEP has been successfully implemented and is now active
Deferred: the EEP has been shelved for future consideration
Living: this is similar to Final, but denotes an EEP which requires regular updates for accuracy (good for token/wallet standards)
Archived: the EEP is no longer under consideration (withdrawn by author, not enough support for the proposal, etc.)
Improvements requiring a consensus fork, as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions
| EEP Number | Title | Author | Status |
| 2 | Linking Accounts to Web Properties | Josh Kauffman, Alexandre Bourget, Marc-Antoine Ross, Stephane Duschesneau, Matthieu Vachon | Draft |
| 8 | Time-Bound Permissions | Corvin Meyer auf der Heide | Draft |
| 9 | Exception-safe recover_key intrinsic | Jeeyong Um | Draft |
Includes improvements around the p2p protocol
| EEP Number | Title | Author | Status |
| 5 | Silent alerting through on-chain permissions | Alexandre Bourget | Draft |
| 6 | EOS Mainnet Extension Chains | Alexandre Bourget, Richard Reiner, Guillaume Babin, Mathieu Boulianne | Draft |
Includes improvements around client API specifications and standards, and also certain language-level standards like contract ABIs. For contract ABIs, it aligns with the eosio.contracts repo and discussion should primarily occur in that repository before an EEP is submitted to the EOSIO/EEPs repository
| EEP Number | Title | Author | Status |
| 3 | Proposed EOSIO Token Standard | Buddy Deck | Under Development |
| 7 | ESR (EOSIO Signing Request) | Aaron Cox, Johan Nordberg | Under Development |
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.
| EEP Number | Title | Author | Status |
| 1 | EEP Purpose and Guidelines | EOS Canada Team | Ready for Review |
Describes a previously submitted EEP submission that does not have a type or category from the list above.
| EEP Number | Title | Author | Status |
| 4 | Creating standard `type` for use with eosio.forum contract | Josh Kauffman, Alexandre Bourget, Matthieu Vachon, Shaq Kheder | Submitted |
EEPs is not a channel to obtain funding through Block.one. The purpose of EEPs is to create an official channel for open source collaboration, community ideas and input for the EOSIO protocol.