Currently, the Ethereum Improvement Proposals website (eips.ethereum.org) is the most definitive source of information about EIPs/ERCs (although the ercs.ethereum.org is already catering to ERCs). The eips.ethereum.org website is great—proposals are defined into categories like “Core”, “Meta”, “ERC”, and “Informational” and are cleanly separated into timelines, so website visitors understand the pace of work on a proposal.

But the organization of EIPs and ERCs could arguably be better. To start with, labels like “Core” and “ERCs” are awfully undescriptive—especially to the average person learning about the EIP process. I like to think of core EIPs as “EIPs that touch the core Ethereum protocol”, but even that’s a broad category. EIP-1559 (fee markets), EIP-3675 (consensus), EIP-3074 (transaction types), and EIP-4788 (precompiles) are touching (very) different parts of the Ethereum protocol—but are lumped up in the same “Standards Track: Core” category.

The problem (it’s a good problem!) is more pronounced in the ERC category, given the sheer amount of R&D happening at Ethereum’s infrastructure/application layer. Token standards dominate most of the ERC category, but there are clearly some proposals that aren’t targeting token applications—for example, ERCs related to smart contract upgrades.

Look long enough, and you start to notice relationships (and sub-relationships) between different prooposals; particularly, we see that even within the same standards track, there are “sub-tracks” that comprise EIPs targeting a niche. An example: token standards explicitly designed for tokenizing real-world assets (RWAs) will be relevant to a small set of players compared to, say, NFT standards.

I only noticed the problem while going through the EIPs website to find EIPs to cover as part of the EIPs For Nerds series. After noticing connections between several proposals, I thought “wouldn't it be a great idea to have a learning plan that involves researching proposals in one area?” It’s easier to be an autodidact if learning happens in fairly related areas—that way, the network of neurons grows and strengthens.

That led to another insight: What if someone out there wanted something similar—an organized approach to studying EIPs that offered more granularity and could be tailored to individual needed? It doesn’t sound terribly groundbreaking, but imagine you’re a developer or researcher and see hundreds of EIPs, with only a few broad categories to help you predict which ones are relevant to your situation or information needs, how do you know where to start?

Some ideal user journeys/stories:

• I’m a researcher and want to learn about a very specific part of Ethereum’s protocol—say, consensus or fee markets. I’m able to select EIPs that focus on (or at least have some relevance to) these topic areas without “guessing” or asking for recommendations.
• I’m a developer and want to find EIPS/ERCs relevant to an application I plan to build. I’m able to find a list of standards that are useful to my work without sifting through dozens of unrelated EIPs or dealing with information overload.
• I’m a startup founder/entrepreneur building critical infrastructure for the Ethereum ecosystem (e.g., wallets and RPC services). I’m able to discover standards I should support to be interoperable with other platforms and provide a similar experience for users migrating from other projects.

In all three cases, the current approach to presenting EIPs doesn’t work well. To illustrate, the “Core” proposals section has no way to filter for proposals related to implementing Proof of Stake on Ethereum; while a developer may have some luck with identifying popular proposals (e.g., ERC-721 and ERC-20), there are also other, less known standards that would equally be useful.

A good example I discovered while researching was EIP-2612 (gasless, off-chain approvals for transferring ERC-20 tokens) and ERC-5750 (token minting and burning)—which are useful tools a developer can use to improve their applications (but are likely to miss out). The argument is that many articles already talk about Permit2 and mintable/burnable tokens, so why explicitly point it out here.

Which is where the idea of building a Wiki(pedia) for EIPs comes into the picture. Wikipedia isn’t always the most authoritative or comprehensive learning resource on specific fields—but the magic of Wikipedia comes from the structured approach to presenting information. I may be clueless about what “philosophical reductionism” or “artificial neural networks” mean, but one or two hours of reading through Wikipedia and visiting the various sections of the website related to these topics will give me a proper overview.

I could gain more knowledge by reading a paper on ARNs on arXiv or searching for “philosophical reductionism” on Google, but I must deal with information overload and dedicate a non-trivial amount of effort to create a “personal learning plan” that aligns with my brain’s need for related learnings to stitch together and condense into a whole before moving on to other areas.

So, even if there are more rigorous/accurate/high-quality papers on philosophical reductionism and artificial neural networks than a wiki created by pseudonymous contributors (who may or may not be experts on the topic), I’m going with the wiki—at least until I have a decent mental map of the territory and can start exploring without the help of a guide. For beginners and new entrants to a field, information architecture > information depth.

I recently published my Notion website as part of creating the type of resource described in preceding sections. The EIPs wiki is a minimal re-implementation of the official eips.ethereum.org website with an important difference: EIPs are assigned to categories with labels that attempt to be as descriptive as possible. Some examples:

• The wiki uses “core Ethereum protocol”, “applications”, and “blockchain infrastructure” as the top-level classification for EIPs. - Low-level EIPs proposing upgrades to the core protocol are classified into “Consensus Layer Upgrades”, “Execution Layer Upgrades”, and “Network Layer Upgrades”. CL upgrades are classified into “Proof of Stake”, “Proof of Work”, and “Proof of Authority” to identify which consensus protocol EIP affects.
• “EL upgrades” are divided into “Ethereum Virtual Machine”, “Fee markets”, “state management”, and “data availability”. “EVM upgrades” is a broad category, which is broken down into subcategories: EVM architecture, EVM opcodes, precompiles, and transaction types.
• “EVM architecture” is also broad and thus delineated into subcategories: “general EVM architecture upgrades” like EIP-170 (contract code size limit), EIP-6780 (SELFDESTRUCT only in the same transaction) and more specific EIPs like proposals under the EOF (EVM Object Format) and SSZ (Simple Serialize) upgrades.
• Where it is impossible to define a concrete category label for a set of EIPs, such proposals are placed in a “Miscellaneous/General” category that is still close to the next most relevant top-level category. For example, the “general EVM architecture upgrades” list could be (theoretically) broken down into subcategories, but I haven’t found a good reason to do so—hence the classification of those EIPs as “general upgrades to the EVM”.