In Ethereum, ERC standards serve as templates for the creation and trade of tokens, and are also used to denote application-level standards and conventions. An ERC, which stands for Ethereum Request for Comment, essentially dictates the rules a smart contract or application in the Ethereum network must follow.

For instance, ERC-20 is a token standard which allows for the implementation of a standard API for tokens within smart contracts. Used by ETH, DAI, and numerous other crypto tokens, ERC-20 is a standard interface which allows any compliant tokens on Ethereum to be used by wallets, dApps, DEXs and other applications within the ecosystem.

It does this by providing basic functionalities like the ability to transfer tokens, approve third-party transactions, fetch wallet balances and more. Ethereum has also implemented ERC-721 and ERC-1155 to standardize interfaces for non-fungible tokens, or NFTs.

But how do these standards come into existence? Are they proposed and implemented unilaterally by the Ethereum core devs or are they subject to a public vote of the network’s users? Before we get into the process, let’s break down how a new standard is proposed.

By the people, for the people

In a true democracy, the populace should be heavily involved in the proposition and implementation of laws. This doesn’t work out exactly like planned because we elect people to represent large sections of the citizenry, and these representatives are then responsible for the business of creating and passing laws.

But Ethereum doesn’t function like any old democracy and as such eschews the traditional way of doing things. Instead of drawing inspiration from the sluggish machinations of parliaments around the world, Ethereum turned to the good old internet for inspiration on how to source and implement network-wide standards.

Way back in 1969, Steve Crocker invented the Request For Comments (RFC) system to record the development of ARPANET, the progenitor of the modern-day internet. In the following decades, engineers and computer scientists authored RFCs to describe methods, research, or innovations pertaining to the working of the internet. If a standards-setting entity like the Internet Engineering Task Force (IETF) found merit in an RFC, they adopted it as a network-wide internet standard.

This model has been adopted by other applications and networks. Python, the programming language, implemented Python Enhancement Proposals (PEPs) to source new features and improvements from their community. The guidelines for all PEPs were laid out in PEP-1, which inspired the Bitcoin Improvement Proposal BIP-0001.

In place of RFCs, Ethereum has Ethereum Improvement Proposals or EIPs. The guidelines for writing an EIP are laid out in EIP-1, which draws inspiration from BIP-0001. By the way, these EIPs aren’t restricted only to ERC token standards, but encapsulate a whole bunch of potential new features or processes for Ethereum. And they have to go through a specific process before being finalized and implemented across the network.

EIPs, ERCs and everything in between

In true democratic spirit, anyone on Ethereum can submit a proposal to suggest new features, collect input on an issue, or simply provide general information to the community. It is these documents that are known as EIPs.

All ERCs begin as EIPs before they are implemented as network-wide token standards. It should be noted that ERCs are only 1 type, or rather 1 sub-type of 3 main types of EIPs.

ERC is a sub-type of Standard Track EIPs, which deal with application-level standards and conventions. They include contract standards such as token standards (EIP-20), name registries like ENS (EIP-137), library/package formats, and wallet formats. For information on the other types of EIPs, read this.

As I mentioned earlier, anyone on Ethereum can write an EIP, which needs to follow a set of guidelines. Ethereum mandates EIP authors to solicit community feedback on the Fellowship of Ethereum Magicians forum before they formally submit the EIP for consideration.

This is what the the EIP process looks like:

As you can see, the process is fairly straightforward. Once an author submits an EIP, a committee of editors reviews it for technical soundness, grammatical accuracy, formatting issues, and code style. If an EIP doesn’t meet the guidelines, the editors send it back to the author for editing. If instead they deem the EIP to be ready, it is merged with the EIP repository and moved to the Draft stage of the process. One thing you should note is that:

Editors do not get to approve or reject an EIP. They just do the administrative and editorial work.

To aid EIP editors in the review process, Ethereum Cat Herders organize meetings (EIPIP) between them and the community. Once an EIP has been formally drafted, the author can mark the EIP as ready for review. In the review stage, the onus falls on the EIP author to source additional feedback from reviewers and all interested parties (editors, core/client devs and the community at large). Things get a bit murky after this.

Emiritus EIP Editor Hudson Jameson says:

The process of how an EIP comes to consensus and is declared ‘Final’ status is purposefully left vague to encourage community collaboration around the specifications built and implemented.

To be finalized, Core EIPs have to be agreed upon by the core devs and require a greater scope of community consensus since they entail protocol-level changes. The devs decide to implement the EIP in a hard fork set at a particular block height, and it’s up to the validators (earlier miners) to update their client software.

For other EIPs like ERCs, the review process is not as meticulous and the method of implementation is unclear. It is understood that once a non-core EIP has met all security considerations and technical requirements, it has to spend a minimum of 2 weeks in ‘Last Call’ before it is finalized. And once this happens, it is accepted as a network-wide standard.

With ERCs, there is no need to implement anything because there are no changes being made to how Ethereum functions. It does not require any code to be pushed because an ERC is not code, it’s a standardized framework for a smart contract with specific functionality. [Check out ERC-1155 on Github to understand exactly what this entails]

An ERC signals to platforms, services and dApps on Ethereum that a new asset or new functions on old assets have been introduced to the ecosystem. And it falls on them to edit their code to support these functions, the core devs have nothing to do with it!

You might have noticed that I didn’t cover a few stages in the EIP process. Here’s what they signify:

• Living: A special status for EIPs that are designed to be updated continually and never finalized. This includes EIP-1.

• Stagnant: Any EIP in the Draft, Review or Last Call stages which has been inactive for 6 months or more is moved to Stagnant. The author or the editors can move an EIP from Stagnant to Draft.

• Withdrawn: An EIP withdrawn by its author is placed in this final state, from where it cannot be resurrected.

So that’s the breakdown of how EIPs turn to ERCs and how EIPs are implemented on Ethereum.