Title: Post_EIP_ERC_split___Create_ERC_1__an_ERC_specific
Category: Magicians

Author: Joachim-Lebrun
Date: 2023-10-27T10:36:15.670Z

With the recent decision to separate EIPs and ERCs into two distinct repositories, it’s become apparent that the preamble section, as defined in EIP-1, requires some adjustments to better suit ERCs. Here are my thoughts on the necessary changes:


Change of Identifier: The eip field should be updated to erc to reflect the specific nature of the document. This change is straightforward but crucial for clarity and proper categorization.


Removal of Category: Given that all documents in the ERC repository will inherently fall under the ERC category, the category field becomes redundant. Removing it would streamline the preamble and avoid unnecessary repetition.


Reevaluation of Type: The type field, which currently seems to default to Standards Track for ERCs, might be redundant if all ERCs indeed fall under this type. However, I would advise caution here. If there’s even a small subset of ERCs that might require a different type classification in the future, retaining this field could be beneficial for flexibility and future-proofing. It’s worth a deeper analysis to confirm the uniformity of the type field across all ERCs.


Potential Additional Changes: While the above points address the most immediate concerns, we should also be open to other adjustments that might better tailor the preamble to the specific needs and nuances of ERCs. This could include additional fields or modifications to existing ones that reflect the unique aspects of ERCs.


I believe these changes will make the preamble more relevant and efficient for ERCs.

Author: Joachim-Lebrun
Date: 2023-10-27T11:14:38.957Z

In addition to the adjustments in the preamble section, It could make sense to consider developing an ERC-1 document. This would parallel EIP-1 but with specific considerations for ERCs. For instance, ERC-1 could include:

Streamlined Process: Tailoring the proposal process specifically for ERCs, potentially simplifying or modifying steps that are more relevant to EIPs.
Dedicated Sections: Including sections that address common ERC-specific concerns, such as token standards, interoperability, and security considerations.
Updated Terminology: Ensuring that all terminology and references are directly relevant to ERCs, avoiding any EIP-specific language that might cause confusion.

This initiative would not only bring clarity but also establish a solid foundation for all future ERC proposals.

Author: matt
Date: 2023-10-27T14:46:25.518Z

These changes sound great! We have a bi-weekly meeting to discuss these types of things called EIPIP. I can add this to the agenda and if you can present it on wednesday next week we can try and make this happen. EIPIP Meeting 93 · Issue #285 · ethereum-cat-herders/EIPIP · GitHub

Author: joeysantoro
Date: 2023-10-27T16:06:26.326Z

I’d like to include EIP-7539: ERC Extensions in these discussions for ERC-1, which has some new headers and dedicated sections and defines an “ERC Extension”

Author: 0xMawuko
Date: 2023-10-30T06:11:27.430Z

Great initiative, and I 100% agree with the general direction of these modifications. I also believe we can fine tune some of the specifics to lay a clear and structured path for how a diverse set of app standards can be introduced via ERCs, in the future. Like so:
Redefinition of Category for ERCs
Wallet = For standardisation across wallets (hardware or software, full-node or light-node, program-managed or key-managed, etc.)
Token = For token design concepts and token contract development practises(NFTs, FTs, SFTs, SBTs, RWAs, etc.)
Metadata = For proposals around on-chain/off-chain metadata standards used in apps, tokens, etc. (Eg: Digital Art, collectibles, RWAs, Identity, Voting, etc.)
DAO = For proposals regarding DAO standards and practises.
Reevaluation of Type
It would be very beneficial to retain this indeed.
Potential Additional Changes
A great placeholder example to better ensure this flexibility and future adjustment is a Subcategory to allow for precision in the various categories, if ever need be.
Add top-level Identifier (Optional)
A top-level identifier with only two options to identify EIP from ERC might just be the cleaner path to take. Like so:
Camp = [EIP | ERC]  (Class might also be a good alternative  to Camp)
Example Header:
Camp: ERC
Number: 9027
Type: Standards
Category: Wallets
*Sub-category: Hardware wallet
insert the other fields that usually follow here
In conclusion, this suggestion can serve as the foundation for a detailed and robust taxonomy that all app-level developers and contributors, both technical and non-technical, can use when proposing app standards to the community.

Author: Joachim-Lebrun
Date: 2023-10-30T06:27:38.486Z

I just opened a PR with basic changes to the EIP-1 to create the ERC-1, please have a look at it and help improve it if you can  Website: Ethereum Request for Comments Process by Joachim-Lebrun · Pull Request #61 · ethereum/ERCs · GitHub

Author: Joachim-Lebrun
Date: 2023-10-30T06:29:34.797Z

As requested, i opened this PR it is very incomplete atm of course, but given the short deadline (wednesday) i couldn’t do better for now, please take a look and tell me what you think about it

Author: Joachim-Lebrun
Date: 2023-10-30T06:41:57.061Z

please create a PR on my ERC-1 file with the modifications you would like to see. I already created some specific categories for ERCs but didn’t include all the ones you mention here. I like the idea of optional sub category, can you formalize it also to add in the current PR?

Author: 0xMawuko
Date: 2023-11-01T06:22:46.130Z

Done 


github.com/Joachim-Lebrun/ERCs








Update erc-1.md


master ← NetWalker108:patch-2



          opened 06:21AM - 01 Nov 23 UTC




            NetWalker108
          



+145
-89






Polished and expanded on this document as suggested by author: [](https://ethere…um-magicians.org/t/post-eip-erc-split-create-erc-1-an-erc-specific-version-of-eip-1/16301/8?u=0xmawuko)

Added more context and info regarding the creation of ERCs, post EIP/ERC Split.

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

 - The PR edits only existing draft PRs.
 - The build passes.
 - Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside <triangular brackets>.
 - If matching on email address, the email address is the one publicly listed on your GitHub profile.

Author: Joachim-Lebrun
Date: 2023-11-01T09:12:24.766Z

Looks great, i just merged it. Still a lot of sub categories that should be added i believe, but it is a great start

Author: 0xMawuko
Date: 2023-11-01T18:52:07.434Z

We discussed the proposal today at the EIPIP call and it had good support, check the discord server.

Author: sbacha
Date: 2023-11-01T21:30:30.540Z

Classification of ERCs is a premature decision that precludes new use cases that are atypical. Classification is a forced choice.
Keywords, or Tags seem more appropriate.

Author: 0xMawuko
Date: 2023-11-06T04:48:47.069Z

Classification is an iterative process.


Tags are essentially what Subcategories provide.


Recommend joining the future EIPIP calls as this is where the Editors clarify quite a lot of this.

Author: joeysantoro
Date: 2023-11-06T22:34:18.762Z

sbacha:

Keywords, or Tags seem more appropriate.


Strongly agree with a preference for Tags. ERCs are not a hierarchical taxonomy in nature and treating them as having cleanly divisible categories and subcategories is a mistake.
The category section is useful for creating broad strokes classes, and using tags to provide granularity is a more desirable option than subcategories. Tags accounts for the combination of concepts within and across categories which are common in ERCs.

Author: joeysantoro
Date: 2023-11-06T22:34:48.707Z

Added a PR to ERC-1 with a minimum viable framework for Extensions: Add Extensions to ERC-1 by Joeysantoro · Pull Request #2 · Joachim-Lebrun/ERCs · GitHub

Author: Aboudjem
Date: 2023-11-12T23:41:05.111Z

Splitting ERCs and EIPs was a smart move !
Great initiative on ERC-1 draftt by the way. It’s a solid start and a much-needed step for the community. I’ve submitted a PR to build on this foundation to enhance clarity and utility. Here’s a quick overview:

ERC Dependency Classification: Introduced to distinguish between standalone and dependent ERCs, aiding in understanding their interrelations.
Code Quality and Documentation: Emphasized adherence to standard coding practices and comprehensive documentation for clarity and consistency.
Refined Content Guidelines: Updated to ensure content is direct, relevant, and accessible.
Separate ERC for Subcategory Management: Proposed for streamlined updates and uniform categorization.
Auxiliary File Optimization: Ensures efficient repo management.
Simplified ERC Ownership Transfer Process: Outlined straightforward guidelines for transferring ERC ownership.

Looking forward to your thoughts on these enhancements. Keep up the great work

Author: Aboudjem
Date: 2023-11-13T15:58:04.667Z

Since the ERC and EIP repositories have split, the numbering based on PRs is no longer practical, leading to confusion. A new process for number attribution is needed also addressing the anti-sniping concern with ERC number allocation can be quite straightforward. Here’s a streamlined proposal:

Sequential Automation: ERCs automatically get the next number in line after approval only approval, meaning that your number will be attributed only after the review. This ensures a tight sequence without gaps, starting from the last one, say, ERC-9001.
Random Blocks: Numbers within specific ranges are randomly assigned to new ERCs. This means that any plate number falling within a block, like ERC-9001 to ERC-9049, is assigned randomly to prevent predictability.
Interval Assignments: Allocate numbers at set intervals within reserved ranges for different categories. Each standard type, like wallets or tokens, would have its block (xx10, xx20, xx30).
Editor Queue: Editors assign numbers, but there’s a transparent queue for all to see which ERCs are up next. This balances fairness with editorial discretion and prioritizes readiness and quality over submission timing.

your input on these suggestions is needed . Any other ideas or feedback? Let’s maybe take this detailed discussion to a separate thread to keep our main ERC-1 talk straightforward.

Author: Joachim-Lebrun
Date: 2023-11-20T11:59:26.817Z

Thanks @Aboudjem i merged your proposed changes to the PR.
It starts to look good imo, but it is obviously still very incomplete

Author: Aboudjem
Date: 2023-11-27T08:09:54.014Z

Just wondering @Joachim-Lebrun what are there specific areas you think are still incomplete or need more attention here?