The EIP Process and the Upgrade Roadmap

The four pages before this one each proposed a change to the machine: programmable accounts, a lighter node, a new market for block-building, a reused bond. Every one of them raised the same nagging question, which the overview flagged and deferred: a chain governed by no one — no CEO, no board, no version-forcing app store — still has to ship changes to a live, multi-billion-dollar system without splitting it in half. How?

This page is the answer. It is not about a new feature of the world computer; it is about the process by which the world computer gets new features at all. That process — the EIP, the core-devs call, the testnet, the coordinated hard fork — is itself a decentralization mechanism, because it is how untrusting strangers renegotiate the rules of the shared machine without any one of them being able to impose a rule on the rest. Get this page right and every roadmap headline you ever read afterward stops being a prophecy and becomes what it actually is: a proposal, at some stage of a long pipeline, that may or may not survive.

Why a live chain needs a process at all

Ordinary software ships by authority: a vendor decides, builds, and pushes an update; you take it or leave the product. Ethereum has no such authority. The rules of the machine are whatever the network’s clients agree to enforce, block by block. So a “change” is not a deploy — it is a coordinated shift in what thousands of independently-run nodes will accept as valid.

That has a hard consequence. If some nodes adopt a new rule and others don’t, they stop agreeing on the state of the shared computer, and the chain splits — a fork into two chains with two histories. The whole point of the machine is that strangers converge on one state; an uncoordinated change breaks exactly that. So the process exists to make sure that when the rules change, everyone changes at the same block, or the change doesn’t happen.

   AUTHORITY MODEL (normal software)     CONSENSUS MODEL (Ethereum)
   ─────────────────────────────────     ──────────────────────────────
   vendor decides ─► pushes update       anyone proposes ─► spec is written
        │                                      │
        ▼                                      ▼
   you run their build or quit            clients IMPLEMENT it independently
                                               │
                                               ▼
                                          network AGREES on an activation block
                                               │
                                               ▼
                                          everyone switches at once, or it forks

The EIP process is the paperwork and the social machinery that makes that bottom-right box reliable. It has two halves: how an idea becomes a specification (the EIP lifecycle), and how a specification becomes an enforced rule (core-devs coordination and the hard fork).

What an EIP is

An EIP is an Ethereum Improvement Proposal: a numbered, standardized design document. It is a specification, not code — precise enough that several independent client teams can each implement the same behavior from it. The number is permanent and citable, which is why you already know the important ones by their digits: EIP-1559, EIP-4844, ERC-4337.

EIPs come in categories, and the category tells you who has to agree for the proposal to matter:

Category	What it changes	Who must adopt it	Example
Core	Consensus rules — the protocol itself	Every node, via a hard fork	EIP-1559 (fee market), EIP-4844 (blobs)
Networking	How nodes talk (the p2p / devp2p layer)	Node operators, but not consensus	devp2p message formats
Interface	Client APIs and RPC method shapes	Client and tooling authors	JSON-RPC method definitions
ERC	Application-layer standards (contracts)	Voluntary — whoever wants interop	ERC-4337 (account abstraction), ERC-20, ERC-721
Meta / Informational	Process and guidance, not on-chain behavior	The community, as convention	The EIP process itself; a named hard-fork’s contents

The line that matters most is Core versus ERC, because it is the line between changing the machine and building on the machine you already have.

• A Core EIP alters what counts as a valid block. It can only take effect through a hard fork — a flag day where every node upgrades. If you disagree, you can only leave.
• An ERC is a contract standard. ERC-4337 needed no hard fork at all: it is smart contracts deployed on the existing chain, and “adopting” it just means choosing to speak its interface. That is the overview’s point — the frontier sometimes lives in the space the rules already allow, not in a protocol change.

Keep that distinction in hand: when a headline says “Ethereum added X,” the first question is was X a Core EIP that forked the chain, or an ERC that anyone could have deployed on a Tuesday? The two are governed completely differently.

The EIP lifecycle: Idea → Draft → Review → Last Call → Final

An EIP is not “true” the moment someone writes it. It walks through statuses, and its status is the honest measure of how real it is. Confusing a Draft with a Final is the single most common way people misread Ethereum’s direction.

   Idea            informal discussion (Ethereum Magicians forum, a Discord, an issue).
     │             No number yet. Anyone can have one.
     ▼
   Draft           assigned an EIP number, merged into the EIPs repo. This means
     │             "well-formed enough to discuss" — NOT "accepted." Most EIPs sit here.
     ▼
   Review          author signals it's ready for wider peer review; editors and the
     │             community pick it apart. Many die or stall here.
     ▼
   Last Call       a final ~14-day window to raise objections before it's frozen.
     │             The "speak now" step.
     ▼
   Final           the spec is fixed and considered the standard. For a Core EIP,
                   "Final" describes the SPEC — it still has to be scheduled into a
                   fork to actually run. (Other terminal statuses: Stagnant, Withdrawn.)

Two things about this ladder repay attention.

First, most EIPs never reach Final, and that is the system working, not failing. A cheap way to write down and number an idea, so it can be argued about in the open, is precisely what lets bad ideas die visibly instead of being decided behind closed doors. The graveyard of Stagnant and Withdrawn EIPs is a feature.

Second — and this is the load-bearing point for reading the roadmap — Final for a Core EIP is not “live.” EIP-4844 was a fully-specified, “Final”-track proposal long before blobs existed on mainnet. A spec being finished tells you the design is settled; it tells you nothing about when (or whether) it gets scheduled into a hard fork. The gap between “the spec is done” and “the network enforces it” is where roadmaps slip.

By the numbers — how far an idea travels before it’s a rule

A rough sense of the funnel, because the shape matters more than any exact count.

   thousands of ideas discussed in forums
        │  (only a fraction ever get an EIP number)
        ▼
   ~hundreds of numbered EIPs in the repo, most in Draft
        │  (Review / Last Call thin the field hard)
        ▼
   a handful of Core EIPs reach "ready to schedule" per year
        │  (All Core Devs picks which ones make the next fork)
        ▼
   ~1–2 named network upgrades ship to mainnet per year,
   each bundling only a few Core EIPs

   Worked read: if a Core EIP is still in *Draft* today, it is many
   independent gates — Review, Last Call, client implementation,
   testnet, a scheduling decision — away from ever mutating your
   account's state. Treat "there's an EIP for it" as the START of
   the pipeline, not the end.

Exact numbers drift year to year; the orders of magnitude — thousands in, one or two forks out — are the durable fact. (As of 2024.)

From spec to enforced rule: how a change actually ships

A Final Core EIP is a document. Turning it into a rule the network enforces takes a second machine, and this is the part outsiders rarely see.

All Core Devs (ACD) calls

The client teams — the people who maintain the independent implementations of the protocol — meet on a recurring public call, historically called All Core Devs, now split into ACD-Execution and ACD-Consensus since the Merge gave Ethereum two layers (an execution client and a consensus client) that must both be upgraded in lockstep. There is no vote with binding legal force. What happens instead is rough consensus: the teams argue, and a change advances only if the people who would have to implement and run it broadly agree to. The power is real but soft — it rests on the fact that a client team can simply decline to ship code they think is unsafe, and a fork with no clients is nothing.

This is where a fully-specified Core EIP gets the one thing a document can’t give itself: a slot. The teams decide which EIPs go into the next named upgrade. An EIP can be Final for years and still not be “in” the next fork because the room didn’t schedule it.

Testnets and the shadow forks

Client teams don’t apply a consensus change to mainnet to see if it works. They run it first on testnets (public networks like Sepolia and Holešky) and on devnets / shadow forks — throwaway networks, sometimes forked from real mainnet state, that let teams rehearse the exact upgrade under realistic conditions. Each network activates the change at a chosen block or timestamp, and the teams watch for the failure that matters most: a consensus bug, where two clients disagree about whether a block is valid and the network splits. A change reaches mainnet only after it has survived this rehearsal on the testnets, in order, without a split.

The coordinated hard fork

Finally, the several scheduled Core EIPs are bundled into a single named network upgrade — Berlin, London, Shanghai, Cancun, and so on — and given an activation trigger: after the Merge, a specific slot / timestamp at which every node simultaneously switches to the new rules.

   EIP-1559  ─┐
   EIP-3198  ─┤
   EIP-3529  ─┼──►  bundled into the "London" upgrade  ──►  activates at a fixed
   EIP-3541  ─┤                                             block/slot on mainnet
   EIP-3554  ─┘        (a NAMED hard fork)                  → new rules, network-wide

   Why bundle? Every hard fork is a synchronized flag day for the WHOLE
   network. Doing several changes per flag day amortizes that coordination
   cost — you don't ask the world to upgrade five separate times.

Two subtleties worth carrying:

• “Hard fork” here is planned and unanimous by design. The scary kind of fork is an accidental split from a consensus bug, or a contentious split where a faction refuses to upgrade (2016’s Ethereum Classic split is the canonical example). A coordinated upgrade is the opposite: its entire job is to change the rules without splitting, by getting everyone to the same slot at once.
• The name is just a label for a bundle. “Cancun” is not a feature; it is a container that happened to hold EIP-4844 (blobs) among others. When people say “the blobs upgrade,” they mean the fork that scheduled that EIP.

It actually happened — the fork that split into two chains

In July 2016, following the theft of ~3.6M ETH from The DAO, the community shipped a hard fork that effectively reversed the theft by moving the funds. A minority rejected the change on “code is law” grounds and kept running the un-forked rules. The result was a permanent split: the forked chain became today’s Ethereum, and the unforked chain survived as Ethereum Classic (ETC) — two chains, two histories, from one disagreement about the rules.

The lesson is exactly why the modern process is so heavy. A rule change is only clean if everyone moves together; the moment a faction won’t, you don’t get an upgrade, you get two world computers. Rough consensus, public ACD calls, and long testnet rehearsals are the machinery for reaching a change the whole network will actually adopt — so the fork stays a scheduled flag day and not a schism.

Reading the roadmap: the Merge, Surge, Verge, Purge, Splurge

Ethereum’s long-term plan is popularly organized into five themed tracks. They are a useful map of intent, and this Part’s earlier pages each live on one of them. Here is the whole Part placed on the map:

   TRACK      PILLAR (what dial it turns)          THIS PART'S PAGES ON IT
   ────────   ──────────────────────────────────   ──────────────────────────────────
   MERGE      switch consensus PoW → PoS           done: /consensus/the-merge/
   SURGE      scale throughput via rollups+blobs    done (EIP-4844): /scaling/overview/;
                                                     restaking rides this economy →
                                                     /advanced/restaking-and-eigenlayer/
   VERGE      make verification cheap; statelessness /advanced/verkle-trees-and-statelessness/
   PURGE      remove old state/complexity; slimmer   /advanced/verkle-trees-and-statelessness/
              nodes, less history to store           (statelessness serves this too)
   SPLURGE    everything else: EVM upgrades, PBS,    /advanced/proposer-builder-separation/;
              account-abstraction niceties, MEV      /advanced/account-abstraction/

Read this way, the roadmap is not a to-do list handed down from an authority — it is five directions the same throughline can push, each turning a dial on what the world computer does, what it costs, or who can still verify it. The status labels below are a snapshot as of 2024 — they drift, so treat them as intent, not fact:

• The Merge was the consensus change: the cost of agreement moved from a power bill to a slashable bond. Shipped, 2022.
• The Surge is scale: more transactions per unit of on-chain cost, via rollups and the blob data they post (EIP-4844 is its first big installment). Partly shipped.
• The Verge is cheap verification: Verkle trees and statelessness so a node can verify without storing the whole state — protecting the “a normal user can still check the chain” property. Research / proposed.
• The Purge is subtraction: removing old state and historical data nodes must carry, so running one keeps getting lighter instead of heavier. Partly shipped, partly proposed.
• The Splurge is the catch-all for everything that doesn’t fit the other four — EVM improvements, proposer–builder separation, account-abstraction ergonomics, MEV management. Mixed.

How to read a roadmap claim critically

The roadmap is a communication device, not a commitment, and treating it as a promise is how people get burned. Three things move independently, and any of them can invalidate a headline:

1. Scope drifts. What a track “contains” is renamed and reshuffled constantly. A feature can migrate from one pillar to another, or split into pieces that ship years apart. “It’s in the Verge” tells you a theme, not a deliverable.
2. Ordering drifts. The tracks are not strictly sequential and rarely ship in the drawn order. Work on several proceeds in parallel; a “later” item can land before an “earlier” one if it’s readier.
3. Dates drift — hardest of all. Ethereum’s schedule has been redrawn many times; features described as “next year” have slipped by years, and some have been dropped entirely. A date attached to an unscheduled feature is an aspiration.

So the reading discipline is a single move: map every claim back to the process. Ask what status is this EIP, and is it scheduled into a named upgrade? If the answer is “it’s a Draft, discussed on ACD, not in the next fork,” then the honest statement is intent, not fact — no matter how confident the headline. The only claims you can state flatly are the ones already past their activation slot: the Merge happened; blobs are live; everything downstream of a not-yet-scheduled EIP is a plan that the process can still reshape or kill.

   HOW SURE CAN I BE?           WHAT TO SAY
   ──────────────────────────   ────────────────────────────────────────
   past its activation slot     "X is live." (state it flatly)
   Final + scheduled in a fork   "X is expected in <upgrade>." (near-certain, still hedge the date)
   Final, not yet scheduled      "X is specified but unscheduled." (intent)
   Draft / Review                "X is proposed." (research; may change or die)
   forum idea, no EIP number     "some people want X." (not a plan yet)

The process as a decentralization mechanism

Step back and notice what the whole apparatus is for. It would be far faster to let a foundation dictate upgrades. Ethereum deliberately doesn’t — because the point of the machine is that no one can impose a rule on the network, and that has to be true of rule changes too, or the property is a fiction.

So the slowness is the feature. Open, numbered EIPs mean anyone can propose and everyone can read. Rough consensus on public ACD calls means a change ships only if the people who must run it agree — and any client team can veto by declining to implement. Long testnet rehearsals mean the network doesn’t gamble its shared state on an untested rule. And the coordinated hard fork means the change binds everyone at once or no one — you cannot be upgraded against your will; at worst you can leave and run the old rules (as Ethereum Classic did in 2016).

That is the throughline closing on itself. How do untrusting strangers agree on the state of a shared world computer? Not only on each block — but on the rules that decide what a valid block even is. The EIP process is how the strangers renegotiate those rules without any of them holding a lever over the others. The cost is real: it is slow, contentious, and easy to misread as a promise when it is only intent. But it buys the one thing a world computer cannot do without — a way to change the rules that is itself as trust-minimized as the machine those rules govern.

Check your understanding

1. Why can’t Ethereum ship a protocol change the way ordinary software ships an update, and what is the specific failure a coordinated hard fork exists to prevent?
2. Walk the EIP lifecycle from Idea to Final. For a Core EIP, why does reaching “Final” not mean the change is live on mainnet — and where does the remaining gap get closed?
3. Distinguish a Core EIP from an ERC using EIP-1559 and ERC-4337 as examples. Which one required a hard fork, which one didn’t, and what does that reveal about where the frontier can live?
4. Name the two stages between “a Final Core EIP” and “a rule enforced on mainnet,” and say what each one is guarding against.
5. Someone shows you a headline: “Ethereum’s Verge will make nodes stateless next year.” Using the roadmap-reading discipline, list the three things that could make this claim wrong, and rewrite it into an honest sentence.

Show answers

1. Ethereum has no authority that can push an update; its rules are whatever the network’s independently-run clients agree to enforce. If some nodes adopt a new rule and others don’t, they stop agreeing on the state and the chain splits into two histories. A coordinated hard fork exists to make every node switch to the new rules at the same activation slot, so the rules change without the network forking.
2. Idea (informal, no number) → Draft (numbered, “well-formed enough to discuss,” not accepted — where most EIPs sit) → Review (wider peer review) → Last Call (final ~14-day objection window) → Final (spec frozen as the standard). For a Core EIP, “Final” describes only the specification; the change still has to be scheduled by All Core Devs into a named upgrade, implemented by client teams, rehearsed on testnets/shadow forks, and activated at a slot. The gap between “spec done” and “network enforces it” is closed by that ACD scheduling + testnet + hard-fork machinery.
3. EIP-1559 is a Core EIP — it changed the fee-market consensus rules, so it could only take effect via a hard fork (London), and every node had to upgrade. ERC-4337 is an ERC — an application-layer contract standard for account abstraction that runs entirely in smart contracts on the existing chain, needing no hard fork; “adopting” it just means choosing to speak its interface. This reveals the frontier can live in application-layer code that uses the rules the protocol already allows, not only in protocol changes.
4. (a) All Core Devs scheduling + client implementation — guarding against shipping a change the people who must run it don’t agree on, and against having a spec with no working code; and (b) testnets / devnets / shadow forks — guarding against a consensus bug where clients disagree on block validity and the network splits, by rehearsing the exact upgrade on throwaway/public test networks before mainnet.
5. It could be wrong because scope drifts (statelessness may be reshuffled between the Verge/Purge or split into pieces), ordering drifts (it need not ship in the drawn order relative to other work), and dates drift hardest of all (Ethereum’s schedule has slipped by years repeatedly). Honest rewrite: “Statelessness (via Verkle trees) is a proposed/research item associated with the Verge track; as of 2024 it is not yet scheduled into a hard fork, so any timeline is intent, not a commitment.”