ERC Standard Taxonomy [living document]
by LexDAO Clinic, House Bestape => students: Dan Berger (lead), Oatmilk and Kyler56; supervisor: bestape.
Taxonomy graph
Click here to explore the taxonomy in full interactive detail.
Introduction
ERC (Ethereum Request for Comment) standards form the building blocks of the Ethereum user ecosystem and govern everything from NFTs to wallet formats and name registries. But what are ERCs and where do they come from? How did a post on GitHub evolve into a monkey jpeg selling for 3 million dollars?
In order to gain a better understanding of the ERC landscape, we’ve created a taxonomy map in the LexDAO Clinic which offers a bird’s eye view of the evolution and interrelation of ERC standards.
A brief history of ERC/EIP
There are three fundamental types of Ethereum Improvement Proposals, or EIPs: Informational, Meta, and Standards Track. Informational EIPs convey general guidelines or information to the Ethereum community, similar to recommendations. Meta EIPs are more than recommendations and describe changes to processes that surround Ethereum, but not to the Ethereum protocol itself. Finally, Standards Track EIPs describe changes related to the core Ethereum protocol, such as network upgrades or changes to block rules. ERCs are one of the four subtypes of Standards Track EIPs, and contain standards and conventions that govern the application layer of the Ethereum protocol.
ERCs were inspired by and emulate the Request for Comments (RFCs) originally used by the Internet Engineering Task Force, one of the primary standards-setting bodies of the internet. ERCs, like RFCs, are canonical technical specifications that provide uniform frameworks for developers to build on.
Ideally these standards make smart contracts more reliable and interoperable. For example, if a smart contract follows the ERC-20 token standard (commonly utilized to design fungible/exchangeable tokens), it should contain certain functions like balanceOf or totalSupply, allowing developers to seamlessly plug it into other smart contracts that support that standard.
The availability of plug-and-play standards makes applications more composable by allowing people to build complex smart contracts using the same simple building blocks as everyone else.
Insights from creating the taxonomy
The process of designing and maintaining these standards is not always a clean and orderly one, especially in the context of a decentralized community spread across the globe. As an open-source protocol, anyone can propose a standard - usually on the Ethereum Magician’s Forum or Github - and if it proves useful (after lots of debate) the Ethereum Cat Herders will finalize it and the community will adopt it.
Standards compete with and improve upon other standards, and social consensus determines which ones are used. For example, ERC-1155 builds upon the ideas of ERC-20 and ERC-721 by allowing multiple fungible and non-fungible tokens to be represented by a single contract. Although some may consider ERC-1155 a more useful or efficient standard, an entire ecosystem has already grown around ERC-721 with four additional ERCs finalized on top of it. This may make it more difficult for ERC-1155 to gain traction.
Some standards, like ERC-712 and ERC-2612, haven’t even been finalized but have proven so useful they have already gained widespread adoption. Although groups like the Ethereum Cat Herders and the Ethereum Magicians do an excellent job of stewarding the orderly development of standards, ultimately developers and their end users decide which proposals become canonical and which fade into oblivion.
As the ecosystem continues to evolve, many standards will be replaced and improved. Some will surely stagnate, and others, like ERC-721, will explode in popularity and form their own branches on the evolutionary tree.
Conclusion
We hope that this taxonomy map proves a useful way to visualize the ERC standards and how they have changed over time.
The chart is meant to be a living document, one that we at LexDAO hope to update and improve upon as the landscape shifts and rearranges.
Some things in the taxonomy might be wrong, or we might be missing a connection here or there.
If you have any comments or suggestions, or if you’re interested in helping us continue the project, stop by the LexDAO Discord and let us know!
Moreover, feel free to submit a pull request with your changes to https://github.com/lexdao/LexDAO-Articles . Documentation about how to make a pull requests here.
"...by allowing multiple fungible and non-fungible tokens to be represented by a single contract." Interesting, does this mean that the additional tokens are 'written' into the original contract, or that the the contract somehow amends itself to include additional items?