Not All EIPs Are Asking for the Same Thing

You're scrolling through Ethereum's improvement proposal repository at some unreasonable hour, and two documents sit side by side in the index. One describes best practices for how wallets should display token amounts. The other proposes rewriting how the network charges for computation. Both carry the EIP label. Both went through formal review, got numbers, got authors, got structure.

So why does one of them require every node operator on the planet to upgrade their software, and the other one doesn't?

Type classification. That's the load-bearing distinction the EIP process uses to separate conversation from consensus, and most people gloss right over it.

The Taxonomy That Actually Matters

Ethereum's EIP framework, codified in EIP-1 (the meta-document that governs all other EIPs, essentially the rulebook for the rulebook), divides proposals into three types: Standards Track, Informational, and Meta. Standards Track itself splits into Core, Networking, Interface, and ERC. Five practical buckets. Knowing which one a proposal lands in tells you almost everything about what happens next.

Core EIPs are the ones that keep infrastructure engineers up at night. A Core EIP proposes a change to Ethereum's consensus rules, meaning the logic every node must agree on to stay part of the same chain. If one is adopted, any node running old software forks off. Gone. EIP-1559, which redesigned the fee market and introduced the base-fee burn mechanism (the part that permanently removes some ETH from supply with every transaction), is the textbook example. Nodes that didn't upgrade at the London hard fork found themselves on a minority chain the network simply ignored. Core EIPs require coordination across client teams, Geth, Nethermind, Besu, Erigon and others, a hard fork schedule, and what amounts to a distributed social referendum across validators, exchanges, and application developers. There is no shortcut.

Informational EIPs, by contrast, describe a design issue, a guideline, or general information for the community. No new feature. No consensus change. Nobody upgrades anything. EIP-2678, which standardized the ethpm package manifest format, is Informational. Ignore it entirely and your node behaves identically. A developer building a package registry might care deeply; a staker running a validator almost certainly doesn't.

This structural difference isn't just social convention. It's enforced by the review pathway itself.

Two Proposals, Two Completely Different Journeys

Walk through the concrete case. It helps.

Proposal A wants to change how the EVM (the Ethereum Virtual Machine, the runtime that executes smart contract code) calculates gas costs for the SLOAD opcode, which reads data from contract storage. Core EIP. The author drafts the spec, submits to the repository, enters Draft status. From there it needs an Ethereum core developer to champion it on the bi-weekly AllCoreDevs calls, a public technical forum where client implementers and researchers argue out objections in real time. Clear that gauntlet and it gets slotted into a specific hard fork. Every major client team implements it independently. Testnets run the change first. Then mainnet. Start to finish, serious draft to live network: eighteen months on a good day, three years if it's contentious. EIP-2929, which did exactly this for SLOAD and other state-access opcodes, followed roughly that arc.

Proposal B wants to document a recommended convention for how smart contracts should signal their supported interface methods. Interface or Informational EIP. The author drafts it, submits it, and application developers and tooling maintainers review it. No AllCoreDevs vote. No hard fork. No testnet. If the community finds it useful, developers adopt it voluntarily, and adoption pressure does the rest. EIP-165, the standard interface detection method, became ubiquitous exactly that way. The EVM never changed a single byte to accommodate it.

Same repository. Completely different physics.

The Honest Complication

Here's where classification gets genuinely messy, and it's worth being straight about it rather than papering over the friction.

Informational EIPs carry no consensus weight, but they can carry enormous practical weight. EIP-55, which specifies mixed-case checksum encoding for Ethereum addresses (a way of embedding error-detection directly into address strings), is Informational. No protocol rule requires wallets to use it. And yet every serious wallet and block explorer implements it, because the cost of not doing so is obvious to anyone who has watched a user fat-finger an address. Informational means no hard fork required. It does not mean no one cares.

The reverse holds too. A Core EIP can clear every technical hurdle and still fail in practice if large stakeholders drag their feet on upgrades. The social layer and the technical layer run in parallel always, and the type classification only governs the technical pathway. One of them.

There's also the standing confusion around ERCs (Ethereum Request for Comments), which live inside Standards Track but get conflated with Informational EIPs constantly. EIP-20 (ERC-20, the fungible token standard) and EIP-721 (NFTs) are application-layer standards. They don't touch the protocol, so they share the low-friction adoption model of Informational EIPs. But they're formally Standards Track documents, and that distinction matters if you're building something and need to know whether your implementation is advisory or genuinely load-bearing infrastructure.

Most coverage treats ERCs and Informational EIPs as interchangeable. They're not, and collapsing that distinction is a real error, not just a technicality.

What the Type Label Is Really Telling You

A Core EIP is a proposal that must achieve rough consensus among a distributed set of client teams with no single authority over any of them. Ethereum has no CTO. The AllCoreDevs process is a coordination mechanism, not a command structure. Vitalik Buterin can author a Core EIP (he has, many times) and it can still stall or get rejected if client implementers raise unresolved objections. That's not a bug. It's the entire point.

An Informational EIP is closer to a well-reasoned memo. The author is saying: here is a problem, here is how I think it should be approached, I am not asking you to change your node. The value is the shared vocabulary it creates. Developers working independently on separate projects can cite the same EIP number and know they're talking about the same convention, which is a surprisingly powerful coordination tool once you watch it work at scale.

Can you see why this split reflects something true about how Ethereum actually governs itself? Protocol changes are existential, requiring the whole network to move together or not at all, like passengers on a crowded ferry deciding whether to shift ballast mid-crossing. Informational proposals are more like publishing a style guide: useful, possibly influential, quietly ignored by anyone who disagrees.

Check the type field at the top of the document before you read the abstract. It will save you from treating a memo as a mandate, or worse, dismissing a mandate as optional reading.