The ERC repository is a standards process, not a code library

A standardisation process rather than a library of contracts

ethereum/ERCs is the Ethereum Request for Comment repository, and the first thing to understand about it is what it is not. It contains no buildable code, no package to install and no test suite. It holds application layer standards for Ethereum, in the form of Markdown documents, and its stated goal is to standardize and provide high-quality documentation for the Ethereum application layer while tracking past and ongoing improvements to application standards. The audience is twofold. The first group is implementers who need to know what a token, a wallet interface or a payment standard is supposed to mean, and who want the answer in a document that was argued over in public rather than in a blog post. The second group is authors who want to propose something new and need a process to follow. The repository recently separated from the EIPs repository, so ERCs now have their own home, and the governance document for the whole system, EIP-1, remains the reference that describes how both EIPs and ERCs are published. The primary language recorded for the repository is Solidity, which reflects what the standards describe rather than what the repository contains.

EIP-1 governs how a proposal becomes a standard

The process is the substance here. The documentation is blunt about the order of operations. Ideas must be thoroughly discussed on Ethereum Magicians or Ethereum Research before an ERC is written, and once consensus is reached the author is expected to read EIP-1 thoroughly and review it, because that is the document describing the EIP and ERC process. In practice this means the expensive part of a standard, the argument about the design, happens in public forums long before a numbered document exists. The value of that arrangement is that the record of the discussion is public and searchable, and a reader who disagrees with the final wording can go back and see which objections were considered. The cost is time, and it is a real cost: a standard that looks finished in the repository was already argued over for a while, and the process is not skippable. The repository also has an editorial layer. People who want to become an EIP Editor are pointed to EIP-5069, which is the document that describes that role, so the repository is maintained by a defined group rather than whoever happens to open a pull request.

One status page, six categories, one place to check maturity

Both EIPs and ERCs are listed on a single status page, and the categories divide along the layers of the protocol. Core EIPs are improvements to the consensus protocol. Networking EIPs specify the peer-to-peer networking layer. Interface EIPs standardize the interfaces that determine how users and applications interact with the blockchain. ERCs specify application layer standards, which determine how applications running on Ethereum interact with each other. Meta EIPs are miscellaneous improvements that nonetheless require some sort of consensus, and Informational EIPs are non-standard improvements that require no form of consensus at all. This taxonomy is what a reader should internalise before searching. An ERC is an application layer standard, so an ERC will not tell you anything about consensus changes, and a proposal that ends up in the informational category is by definition not something anyone is obliged to implement. The categories also explain the separate HTML pages in the repository tree, with core.html, networking.html, interface.html, erc.html, meta.html, informational.html and an all.html view, one per category.

The repository is really a static site with a documents folder

The repository layout gives away how the publishing works. There is an ERCS directory that holds the documents themselves, and next to it a erc-template.md file that is the starting point for a new proposal. Around those sit the files of a Jekyll site: a Gemfile and Gemfile.lock for the Ruby build, _config.yml for the site configuration, and the usual _layouts, _includes, _data and assets directories that a static site generator needs. The category pages and index pages are HTML files, 404.html handles missing links, CNAME holds the custom domain for the published site, and an rss directory provides feeds. So the repository has two jobs at once. It is the versioned source of truth for the specifications, edited through pull requests, and it is the input to the website that renders them at eips.ethereum.org. The practical consequence for a reader is that the canonical, citable location of a document is the site, and the GitHub repository is where the text is changed.

The canonical URL rule decides what counts as citable

The documentation sets out a citation policy, and it is stricter than it first appears. The canonical URL for an ERC that has achieved draft status at any point is the one on the published site, for example the eip-1 page. Anything not published there should be considered a working paper. And even published documents with a status of draft, review or last call should be treated as incomplete drafts, with the note that their specification is likely to change. That last clause is the one teams get bitten by. Citing an ERC as the source of truth in a specification, a test suite or an audit report is defensible only if you are willing to say which status you read, and to expect the text to move. The licence is CC0-1.0, so the text of the specifications themselves carries no reuse conditions, which is the practical reason a public domain dedication is the right choice for a document set meant to be quoted and implemented by anyone.

Implementation questions belong on the Stack Exchange

The repository draws a boundary that newcomers trip over. It is for documenting standards and not for help implementing them, and such inquiries should go to the Ethereum Stack Exchange instead. For questions about a specific ERC, the documentation advises commenting on the relevant discussion thread of that ERC, the one denoted by the discussions-to tag in the ERC's preamble. That tag is a small piece of metadata with a large practical effect: it points a reader back to the forum where the design was debated, which is where the reasoning behind a clause lives, since an ERC document states what the standard is rather than why each choice was made. Combining the two channels gives a workable division of labour for an implementer. Use the repository to find out what a standard requires, use the discussion thread to understand why, and use the Stack Exchange for the mechanics of your own integration. The last push to the repository was on 2026-10-22, and there are no GitHub releases, because the documents are versioned by pull request and the site carries the published versions rather than the repository carrying artefacts.

Editorial conclusion

Adopt the ERC repository as your reference for what Ethereum application standards say and how a standard is meant to be written, and use it as the place to start a proposal of your own once the design has been argued out in public. Do not treat it as a source of implementation guidance, because the documentation states that it is for documenting standards and points implementation questions to the Ethereum Stack Exchange, and do not cite a document that is not published on the site as anything other than a working paper. Before you reference an ERC in your own code, check its status on the status page, since documents marked draft, review or last call are still incomplete drafts that can change.

Frequently asked questions

Official sources

1. ethereum/ERCs on GitHub
2. Issues
3. License: CC0-1.0
4. README