- We should fork the EIP repo to create an ERC-only one, with ERCs displayed at
- Editors would be granfathered in both repos, free to resign on either side
- The processes can evolve independently, to suit the need of EIP vs. ERC authors, and welcome CL contributors to EIPs
- To avoid name collisions, EIPs get even numbers, and ERCs get odd ones.
ERCs are distinct from EIPs in that they concern themselves with the application layer, rather than consensus or client-related changes.
Over the years, this has led to friction and awkwardness in determining how EIP statuses should be interpreted for each type of EIP, what standards should EIP editors apply when reviewing ERCs vs. EIPs, and even how we should render their names
In addition, with The Merge behind us, there is now a desire to harmonize the EL & CL specifications processes. EL & CL teams currently have very different approaches to specifications, and it is to be expected that how EIPs are used in the context of network upgrades may change to accomodate CL practices, leading to further divergence between EIPs (especially Core EIPs) and ERCs.
Finally, the concept of “ERC editors” has come up frequently, and been stated as a “blocker” to separting out EIPs from ERCs. That said, ERCs do get reviewed today. By forking the repository, EIP editors would automatically be ERC editors as well (and free to resign from this). If this leads to no ERC editors, then it will be a strong signal to the community to step up and invest in this.
ethereum/eips to create
Start from the same repository, and do not handle any major changes before the separation.
ercs.ethereum.org to render ERCs
Re-use all templates and styling from eips.ethereum.org - the website should look “the same”, minus the content.
3. Update EIPs repo to remove mentions of ERCs
Add a link to
ercs.ethereum.org as part of the landing page, and do the same thing for ERCs repo.
Note that the ERCs repo will probably require a larger overhaul, but that can happen gradually.
4. Avoid Number Collisions by using Odd/Even Numbers for ERCs/EIPs
We don’t want ERC6000 and EIP6000 - going forward, EIPs would use the even number closest to the PR number by default, and ERCs would use the closest odd number. Historical EIPs/ERCs would be not be changed, e.g. ERC20 & EIP-1559 both break that rule.
5. Allow Both Processes to Evolve Independently
Once the split is done, both EIPs and ERCs can evolve in independent directions to best suit the needs of their users.
It’s important to remember that while there are constraints EIP editors can impose, the goal of the EIP and ERC processees should be to serve authors. If EIP and ERC authors have different goals with their specifications, the processes should accomodate them differently.