---
tags:EIP
---

# Ethereum Request for Comments (ERCs) Process

As stated in [EIP-1](https://eips.ethereum.org/EIPS/eip-1#eip-types), 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](https://eips.ethereum.org/EIPS/eip-20)), name registries ([ERC-137](https://eips.ethereum.org/EIPS/eip-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](https://youtu.be/eo90AIGv3jw), 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](https://github.com/ethereum/EIPs/pull/3719) & [PR-3721](https://github.com/ethereum/EIPs/pull/3721) are created respectively.
* Unsolicited naming of a proposal as ERC even if it is not available in `DRAFT` at [Ethereum Improvement Proposals website](https://eips.ethereum.org/erc).
* 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 `FINAL`status
* 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](https://ethereum-magicians.org/).
* Encourage author(s) to stay around till the proposal reaches `FINAL` status.

#### Existing ERC proposals
* List [ERCs](https://eips.ethereum.org/erc) 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](https://eips.ethereum.org/erc) 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 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](https://ethereum-magicians.org/) 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](https://github.com/ethereum/EIPs/pulls) 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](https://eips.ethereum.org/erc) 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 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.