Ethereum's history is written in numbers. EIP-1559 changed how fees work. EIP-4844 gave rollups cheap data. ERC-20 defined what a token even is. If you spend any time around Ethereum, these numbers function as shorthand for entire eras of the network — and yet the thing they refer to is surprisingly mundane. An Ethereum Improvement Proposal is a design document: a text file, in a public GitHub repository, describing a proposed change and the reasoning behind it.
The confusion around EIPs usually comes from the word "proposal." It suggests something gets voted on. Nothing does. There's no token vote, no on-chain referendum, no foundation sign-off that turns a proposal into law. Understanding what actually moves an EIP from a document to running code is understanding how Ethereum governs itself — which is worth having clear, because it's one of the most misdescribed mechanisms in crypto.
The Document Itself
The format is borrowed, openly, from older engineering cultures. Python has PEPs, Bitcoin has BIPs, and Ethereum copied the pattern early: EIP-1, the first proposal, does nothing except define what an EIP is and how the process works. Every proposal since follows its template — an abstract, a motivation, a technical specification precise enough to implement from, and a rationale that records why the design landed where it did.
That last part matters more than it sounds. EIPs double as Ethereum's institutional memory. When someone asks "why does the protocol do this weird thing?", the answer is usually findable in a rationale section written years ago. The numbers themselves carry no meaning — an EIP gets the number of its pull request, which is why they're non-sequential and why nobody could have planned for "1559" becoming a household name.
Proposals come in types, and the type determines everything about what happens next:
Core EIPs change the protocol itself — consensus rules, gas costs, new opcodes or precompiles. These require a hard fork, because every node must apply the change simultaneously or the chain splits.
ERCs (Ethereum Request for Comments) are application-level standards — token interfaces, wallet conventions, naming schemes. ERC-20 is the famous one. These need no fork at all; they're conventions that contract developers adopt voluntarily. Since late 2023 they've lived in their own repository, a formal acknowledgment that they follow a different track with different stakes.
There are also Meta and Informational EIPs — process documents and guidance. The interesting Meta ones are the fork definitions: each network upgrade gets a Meta EIP that lists which Core EIPs it contains, which makes the fork's contents an auditable document rather than an announcement.
The Lifecycle — and Where It Deceives You
An EIP moves through defined statuses: Idea → Draft → Review → Last Call → Final, with sidings for Stagnant (abandoned) and Withdrawn. Editors shepherd this movement, and here's the first thing people get wrong: EIP editors check format and completeness, not merit. They're not approving the idea. They're confirming the document is well-formed enough for the community to evaluate.
The second and larger misreading is what "Final" means. Final means the document is done — the specification is stable and won't change. It does not mean Ethereum will adopt it. For a Core EIP, the real decision happens somewhere else entirely: the All Core Devs calls, the recurring meetings where client teams — the groups maintaining Geth, Nethermind, Prysm, Lighthouse, and the rest — negotiate which EIPs get scheduled into the next fork. Proposals get marked "Considered for Inclusion," then "Scheduled for Inclusion," and plenty of technically sound, fully Final EIPs simply never make the cut. The BLS precompiles from the previous post in this series waited roughly five years with no one disputing their quality.
So the honest model is this: the EIP process produces legitimacy and precision — a canonical, argued-over specification. The client teams produce adoption. An EIP becomes part of Ethereum when the people who write the software agree to implement it and ship it in a coordinated fork. That's the whole mechanism. It's rough consensus among implementers, the same way the early internet standards worked, and it means client developers are the de facto gatekeepers of protocol change — not because anyone appointed them, but because implementation is the only act that counts.
ERCs invert this. No fork, no core-dev approval — an ERC "wins" by network effect. ERC-20 is authoritative because millions of contracts implement it, not because anyone scheduled it. Which means a Final ERC that nobody adopts is just a well-formatted document, and a competing convention can displace a standard without any process at all.
Where the Constraints Live
The hard constraint is coordination. A Core EIP must be implemented identically by every client team in two separate layers (execution and consensus), tested against shared test suites, and activated at the same block on every node in the world. Each addition to a fork multiplies testing surface, which is why forks ship roughly yearly and carry a handful of EIPs rather than dozens — block space in a fork is scarce the way block space in a block is.
The soft constraint is the absence of formal authority, and it cuts both ways. Nobody can force a change through — a proposal with concentrated opposition from client teams is dead regardless of community enthusiasm. But nobody can formally kill one either, so proposals persist for years, waiting for the environment to change. The process runs on persuasion, championing, and patience. Admittedly, this makes Ethereum governance illegible from the outside; that illegibility is the price of having no privileged decision-maker to capture.
What's Changing
The process is fragmenting deliberately at the edges. The RIP track — Rollup Improvement Proposals — now exists as a parallel process where Layer 2s standardize changes without waiting for L1, and it's explicitly designed as a staging ground: prove a feature on rollups, then bring the evidence back to the EIP process. RIP-7212 is the test case to watch.
Fork planning itself has also become more explicit — recent upgrades have been organized around a debated "headliner" feature with smaller EIPs negotiated around it, which makes the trade-offs more public than they used to be. The pipeline of proposals keeps outgrowing fork capacity, so the selection pressure — and the arguments about it — will only intensify.
What Would Confirm This Direction
Continued roughly-yearly forks shipping through the same Meta-EIP structure. RIPs graduating into L1 EIPs with rollup deployment cited as evidence. Fork-selection debates staying public and legible in the ACD process rather than moving somewhere closed.
What Would Invalidate or Change It
A change forced into or blocked from a fork against clear client-team consensus would mean the real decision-making had moved — to the Foundation, to stakers, or to some coalition able to override implementers. Formal on-chain governance replacing rough consensus would be a structural break, not an iteration. And if L2 governance diverges enough that RIPs stop feeding back into L1, the EIP process becomes one process among several rather than the canonical one.
Timing Perspective
Now: The process works as described — repository, statuses, ACD scheduling. If you're evaluating any claim about "Ethereum is adding X," the checkable facts are the EIP's status and whether it's been scheduled into a fork's Meta EIP. Those are different facts, and the gap between them is where most misreporting lives.
Next: Watch the RIP-to-EIP pathway and the next fork's headliner negotiation. Both will show whether the staging-ground model actually functions.
Later: Formalization pressure — as the stakes rise, so do calls for more explicit governance. Nothing concrete is scheduled, and the current process has survived every previous version of that argument.
Boundary Statement
This post explains what EIPs are and how one becomes part of Ethereum. It doesn't catalogue notable EIPs (EIP-1559 and ERC-4337 get their own posts), evaluate any pending proposal, or take a position on whether Ethereum's governance is good — only on how it mechanically works. As always: mechanism explanation, not a recommendation to build on, use, or invest in anything described here.
