As stated in EIP-1, Ethereum Request for Comment a.k.a ERC is a popular category of Standard Track EIP. These are application-level standards and conventions, including contract standards such as token standards (ERC-20), name registries (ERC-137), URI schemes, library/package formats, and wallet formats.
With the recent explosion of applications being build on the Ethereum blockchain and a number of proposals waiting in DRAFT
staus, it becomes increasingly important to standardize the Ethereum Request for Comment (ERC) proposals and encourage authors to push it to attain the FINAL
status to build a library of standards for Ethereum developers.
DRAFT
at Ethereum Improvement Proposals website.FINAL
status for dApp developers to refer to.DRAFT
to Final
.FINAL
statusDRAFT
if it adheres to the guidelines.FINAL
status.FINAL
which is over 3 months old.REVIEW
.STAGNANT
and add the ERC to a list of proposals looking for a champion. Such proposals can be moved to WITHDRAWN
after 3 months of inactivity.Any ERC proposal in FINAL
status and is listed at https://eips.ethereum.org/erc is recognized as a standard for Ethereum community to refer to or implement in their projects.
While any Ethereum dApp developer is free to use any piece of codes in project development, it must NOT be called as an ERC standard untill
FINAL
status.DRAFT
.In order to motivate authors to push proposal to standardization, announce distribution of "ERC Author" POAP or Gitcoin Kudos to every author listed on the proposal reaching FINAL
status.
Moving an ERC proposal to a standard involves multiple parties including author(s), editor(s), a champion (if author is no more around or interested to pursue the proposal), on-chain project(s) and the Ethereum community.
The following is the standardization process for ERC of all types:
It is highly recommended to vet the idea before submitting a formal proposal to be considered as an Ethereum standard. A proposer must open a discussion thread on the Fellowship of Ethereum Magicians to do this in order to be assured that the idea is original and has not been a part of prior research.
Once the idea has been vetted, the next step is to document it as a proposal (EIP). Create a pull request here and invite editors, reviewers, and all interested parties to give feedback on the aforementioned channel. A proposal following standard guidline is then merged by the editor as DRAFT
.
It is important to socialize the proposal to gather community interest and document any forseeable use cases to create a standard for future users (dApp develoers) of the Etherum blockchain. Sharing proposal at different social media like Reddit, Twitter to invite participation to discuss it at Fellowship of Etheteum Magicians is highly recommended. This will ease moving a proposal past the REVIEW
status.
Once the author is convinced it is ready and no more spec changes are required, a pull request can be created by the author or the champion to request status change to LAST CALL
where it is rests for a minimum of two weeks inviting final comments from the community.
At the end of the Last Call period, the author or the champion can create a pull request to move the proposal to the FINAL
status.
Idea - An idea that is pre-draft. Ideally this is not tracked but can be found at discussion-to section of the proposal.
Draft - The first formally tracked stage of a standard in development. An ERC is merged with DRAFT
status by an editor to the EIP repository when properly formatted.
Review - An ERC Author marks an ERC proposal as ready for and requesting peer review.
Last Call - This is the final review window for a proposal before moving to FINAL
. An editor will assign Last Call status and set a review end date (review-period-end), typically 14 days later.
If this period results in necessary normative changes it will revert the ERC to REVIEW
.
Final - This ERC represents the final standard. A Final
ERC exists in a state of finality and should only be updated to correct errata and add non-normative clarifications.
Stagnant - Any proposal in DRAFT
or REVIEW
if inactive for a period of 6 months or greater is moved to STAGNANT
. An ERC may be resurrected from this state by author(s) or editor through moving it back to DRAFT
. Author(s) of the proposal is notified of any algorithmic change to the status of their ERC.
Withdrawn - Any proposal can be withdrawn by the author. This state has finality and can no longer be resurrected using the earlier assigned ERC number. If the idea is pursued at later date it is considered a new proposal.
It occasionally becomes necessary to transfer ownership of a proposal (ERC) to a new champion. In general, it is recomended to retain the original author as a co-author of the transferred ERC, but that’s really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the standardization process, or has fallen off the face of the ‘net (i.e. is unreachable or isn’t responding to email). A bad reason to transfer ownership is because you don’t agree with the direction of the ERC. We try to build consensus around an ERC, but if that’s not possible, you can always submit a competing proposal.
If you are interested in assuming ownership of an ERC, send a message asking to take over, addressed to both the original author and the editor. If the original author doesn’t respond to the email in a timely manner, the EIP editor will make a unilateral decision (it’s not like such decisions can’t be reversed :)).
For each new ERC that comes in, an editor does the following:
FINAL
status.Once the ERC is ready for the repository, the editor will:
Many proposals are written and maintained by developers with write access to the Ethereum codebase. The editors monitor ERC changes, and correct any structure, grammar, spelling, or markup mistakes they see.
The editors don’t pass judgment on proposals. They merely do the administrative & editorial part.