While tech giants like Apple (AAPL) and Microsoft (MSFT) regulate software updates behind closed doors, Ethereum takes the opposite approach. Anyone with enough technical proficiency can write, edit and submit Ethereum Improvement Proposals (EIPs) for new functionality or features that they would like to implement according to the guidelines in the EIP-1, which was published in 2015.
The EIP-1 is a highly recommended resource for prospective authors or contributors because it outlines all critical aspects related to EIPs, such as the process, definitions and types of EIPs, the EIP format and template, as well as a list editors and more.
If you do have an idea, know that authors of EIPs are also responsible for building engagement and gaining critical feedback in the Ethereum community.
What is an Ethereum Request for Comment (ERC)?
Since Ethereum's inception in 2015, numerous proposals and ensuing contract standards have been approved.
As stated in EIP-1, Ethereum Request for Comment (ERC) relates to a specific category of Standards Track EIP. A Standards Track EIP describes any change that affects most or all Ethereum implementations and can be broken down into different subcategories such as core, networking, interface and ERC.
ERC: While the definition has grown over time, an Ethereum Request for Comment (ERC) was the original draft proposal developers wrote and later refined as an EIP for different application levels and conventions. These include token standards (ERC-20), URI schemes, library/package formats (EIP-82) or wallet formats. If the specific EIP achieves consensus in the Ethereum community, it becomes a new standard that automates the rules outlined in the document through a related smart contract.
The main difference in these subcategories of Standards Track EIP is where it's deployed. For example, ERCs are deployed at the application level. They don't need to be adopted by all participants, unlike core which is deployed at the protocol level and requires a broader consensus in the community, as all core EIPs must be widely adopted (all nodes must upgrade to remain part of the network).
Along with a Standards Track EIP, other types of Ethereum Improvement Proposals include Meta EIP and an Informational EIP.
The participation and decision process for ERCs
As a central and collaborative location that contains all of the project files and entire revision history, the Ethereum Improvement Proposals (EIPs) GitHub repository was created in 2015. It was also based on the Bitcoin Improvement Proposals (BIPs) process, which is modeled on the Python Enhancement Proposals (PEPs). However, before including a document in the repository, a rigorous and specific process needs to be followed as outlined in the EIP 1.
- Idea/Discussion Thread: To avoid any overlap with existing proposals or standards, it is recommended that authors vet their idea by opening a discussion thread on the Fellowship of Ethereum Magicians. If the concept is original and worth pursuing, the next stage is to present and document feedback of it as an EIP proposal, which must include concise technical specifications of features and the rationale behind them.
- Draft: To do this, authors can create a pull request (a method of submitting contributions to an open development project) here and invite editors, reviewers and any interested party to provide feedback. For new ERC proposals, the editor(s) will then guide the author to follow the standard process and merge the proposal to draft status if or when it adheres to the guidelines.
- Review: As with the initial vetting process, authors are recommended to continue auditing their draft proposal and document any foreseeable insights for future use cases. An author can mark the draft as open to community feedback by moving it to the review stage.
- Last Call: Once confident that no further changes are needed, an author can create another pull request to move the document to "last call," which is the final process in the review stage. If approved, the proposal will be assigned by editor as a last call. The editor will set a final date (within a minimum of two weeks) for the community to suggest any further changes. If any significant changes are needed, the document moves back to the review stage.
- Final: Following the last call period, the author may then create a pull request to move the proposal to a final status, which represents the final or implemented standard. A list of all final ERC proposals can be found on https://eips.ethereum.org/erc.
If the review period for drafts exceed six months or remain inactive, documents are labeled as "stagnant." An ERC, however, can be revived if an author or editor moves it back to the draft stage. Proposals can also be withdrawn by authors but can be pursued later on, when they will be considered to be new proposals.
EIPs can also be categorized as "living," which is a special status for EIPs that are continually updated and not meant to reach a final state, like the EIP-1
A list of EIP statuses and their definitions can be found here: https://eips.ethereum.org
The above diagram is the standard process for all EIPs in all tracks according to the EIP 1.
EIP editors are responsible for reviewing EIPs for technical soundness, spelling/grammar and code style. The original EIP editors from 2015-2016 were Martin Becze, Vitalik Buterin and Gavin Wood, along with several others.
According to the EIP-1, the current EIP editors are:
- Alex Beregszaszi (@axic)
- Matt Garnett (@lightclient)
- Micah Zoltu (@MicahZoltu)
- Greg Colvin (@gcolvin)
- Sam Wilson (@SamWilsn)
Emeritus EIP editors are:
- Casey Detrio (@cdetrio)
- Nick Johnson (@arachnid)
- Vitalik Buterin (@vbuterin)
- Hudson Jameson (@Souptacular)
- Nick Savers (@nicksavers)
- Martin Becze (@wanderer)
Once an ERC is ready for the repository, editors will also help to do the following:
- Assign an ERC number.
- Merge pull requests created by authors.
- Guide ERC authors to the next stages.
Generally, proposals are created and reviewed by developers with write access to the Ethereum codebase. The editors don't pass judgment on these proposals, but rather handle housekeeping aspects like monitoring ERC changes, correcting structure, highlighting mistakes, etc.
Links to the various Ethereum GitHub repositories, EIP discussion boards and a list of all core Ethereum developer meetings can be found here: https://ethereum.org/en/developers/docs/standards/.
Why do EIPs matter?
EIPs (which include ERCs) are the central unit around which governance (decisions) happen and are documented on Ethereum. As part of a decentralized ecosystem, they are the way for anyone to propose, debate and adopt changes. Whether integrated as a standard or included in a broader network upgrade, EIPs also help people understand how certain tokens and aspects of Ethereum function relative to the specific smart contract. Every network upgrade also consists of a set of specific EIPs that each Ethereum client needs to implement to maintain consensus with each other.
How do ERCs make different and new things possible?
A few examples of various ERC standards and their use cases include:
- ERC-20: Proposed by Fabian Vogelsteller and VButerin in November 2015, the ERC-20 (Ethereum Request for Comments 20) is the most popular interface for fungible (interchangeable) tokens that implement an API (application programming interface) within smart contracts. Some examples of what the ERC-20 token allows people to do include:
- Transfer tokens between accounts.
- View the current token balance of an account.
- View the total supply of a token available on the network.
- Confirm third-party spending.
- A standard interface that allows tokens on Ethereum to be reused by other applications, for example, from wallets to decentralized exchanges.
- ERC-721: Inspired by the ERC-20 token standard, the ERC-721 was proposed two years later by William Entriken, Dieter Shirley, Jacob Evans and Nastassia Sachs in January 2018. While the EIP-20 caters to fungible (replicable and interchangeable assets), it doesn't support the unique structure of non-fungible tokens (NFTs), because each asset is distinct (non-fungible). As a result, the ERC-721 was created as the standard interface for NFTs like artwork or songs. Because each ERC-721 token is unique, they are reflected on the blockchain by an ID. That ID can then be used by other people or applications to verify proof of ownership.
Several well-known NFT collections that use the ERC-721 token standard include:
- CryptoKitties: originally compatible with an earlier version of the ERC-721 standard, CryptoKitties is a play-to-earn game that pioneered the ability to let users breed and collect digital cats on the Ethereum blockchain.
The original issues and discussions for ERC-721 can be found on the following links:
- The original ERC-721 Issue. https://github.com/ethereum/eips/issues/721.
- Gitter #EIPs (announcement of first live discussion). https://gitter.im/ethereum/EIPs?at=5a5f823fb48e8c3566f0a5e7.
- ERC-721 (announcement of first live discussion). https://github.com/ethereum/eips/issues/721#issuecomment-358369377.
- ETHDenver 2018. https://ethdenver.com.
Further examples of ERC contract standards include:
Overall through concerted efforts between communities like Ethereum Cat Herders and Fellowship of Ethereum Magicians, the methods to integrate or make changes to Ethereum are increasingly streamlined as the network grows. Ethereum Cat Herders also encourage authors or potential implementers to speak on their PEEPanEIP series that provides an overview of EIPs considered for a network upgrade, ERC standards and other key concepts of the Ethereum blockchain. Further reading and information about the history of EIPs and the development of governance on Ethereum (including ERCs) can also be found on Hudson Jameson's blog.
Read More: What Is the ERC-20 Token Standard?
CORRECTION (May 4 , 14:14 UTC): Updated list of current and emeritus EIP editors per EIP-1.