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.

Purpose

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.

Problems identified

At user's level

~~Inconsistency in ERC title.~~ In the EIPIP meeting 39, it was decided that repetation of EIP number should be avoided in title. To document this decision in EIP-1 & GitHub Readme file, PR-3719 & PR-3721 are created respectively.
Unsolicited naming of a proposal as ERC even if it is not available in DRAFT at Ethereum Improvement Proposals website.
Less availability of ERC standards in FINAL status for dApp developers to refer to.

At author's level

Lack of awareness of ERC proposal standardization process.
Lack of enthusisam for championing the proposal from DRAFT to Final.
Lack of review comments or community discussion on the proposal.
Requirement of ERC process documentation to refer to.

At proposal management level

Over 100 ERC in Draft status. Less than 20% of proposals have made it to FINALstatus
Less availability of ERC editor(s) to review the proposal.

Proposed solution

1. ERC process documenting

Add more texts to existing EIP-1 to state ERC standardization process.
Alternatively, create a separate Meta EIP for ERCs.

2. Manage new & existing proposals

New ERC proposals

Editor will guide the author to follow the standardization process.
Merge the proposal to DRAFT if it adheres to the guidelines.
Encourage author(s) to create a discussion-to thread at Fellowship of Ethereum Magicians.
Encourage author(s) to stay around till the proposal reaches FINAL status.

Existing ERC proposals

List ERCs available in any status except FINAL which is over 3 months old.
Reach author(s) to see if there is any interest to pursue the proposal.
- If Yes, ask them to create a pull request to change status to REVIEW.
- If No,
  - try to get a reason - (a) not valid or a better standadrd available (b) still holds good but lack of time or interest.
  - If reason is (b), then create a pull request to change the status of the proposal to 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.

3. Pronounce an ERC proposal as an ERC standard

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

it has reached to FINAL status.
It is unavailable in the ethereum GitHub repository.
It is listed to Ethereum repository as DRAFT.

4. Introduce ERC Author POAP or Gitcoin Kudos

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.

ERC standardization process - the work flow

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:

Screenshot-2022-04-21-112854

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.

ERC statuses

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.

Transferring ERC Ownership

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 :)).

ERC Editors

Matt Garnett

ERC Editor Responsibilities

For each new ERC that comes in, an editor does the following:

Read the proposal to check if it is ready: sound and complete. The ideas must make technical sense, even if they don’t seem likely to get to FINAL status.
The title should accurately describe the content.
Check the proposal for language (spelling, grammar, sentence structure, etc.), markup (GitHub flavored Markdown), code style.
If the proposal isn’t ready, the editor will send it back to the author for revision, with specific instructions.

Once the ERC is ready for the repository, the editor will:

Assign an ERC number (generally the PR number)
Merge the corresponding pull request
Send a message back to the ERC author with the next step.

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.

Resources:

______________________________________________________________________

Disclaimer: Content provided on this webpage is for information purposes only. Readers are suggested to conduct their own research, review, analyze and verify the content before relying on them.

To publish press releases, project updates and guest posts with us, please email at contact@etherworld.co.

Subscribe EtherWorld YouTube channel for easy digestable content.

You've something to share with the blockchain community, join us on Discord!

Ethereum Request for Comments (ERCs) Process