The EIP Change Pipeline
Move a protocol change through staged consent instead of a single decision
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 7
- Confidence
- 60%
Ethereum's protocol decisions run through a pipeline with distinct stages and distinct gatekeepers at each. Stage one is idea-making; stage two is refining; then comes convincing progressively more people; then a test implementation; then formalisation into a written Ethereum Improvement Proposal; then the All Core Devs call, a fixed forum held once every two weeks where the core developers discuss the proposed protocol changes; and finally inclusion in a hard fork, the named upgrade everyone must download to stay on the network. The gating rule at the call is consent rather than majority — everything people agree on gets accepted, and if people disagree it does not. The gatekeepers change along the way: near the beginning the research team has to agree, and in later stages the people actually writing the code have to agree as well. Buterin describes the output as increasing bureaucratic legitimacy at the direct cost of his own influence, which keeps decreasing every six months, with some of the EIPs he personally promotes failing to make it in at all.
Origin
Extracted from Naval — Vitalik Buterin describing how Ethereum protocol changes are actually decided, contrasted with six years earlier when a change could be accepted and included very quickly.
Core principles
- 01Legitimacy comes from the pipeline, not from whoever proposed the change.
- 02Different constituencies gate different stages — researchers early, implementers late.
- 03A recurring fixed-cadence forum forces decisions that open debate never reaches.
- 04Consent is the default requirement: if people disagree, it does not get accepted.
- 05As the pipeline matures, the founder's ability to force anything through should fall.
- 06A working pipeline will reject changes its own founder wants, and that is the point.
How to run it
- 1
Idea-making
Generate the raw proposal openly, with no expectation of rigour yet. Keeping this stage separate protects half-formed ideas from being judged against the standards applied to finished ones.
Pro tip A public, low-status venue for raw ideas keeps them out of the formal channel until they are ready.
- 2
Refining
Sharpen the proposal into something technically defensible, resolving the obvious objections before exposing it to a wider audience. This is where scope gets narrowed to what can plausibly pass.
Pro tip Narrow, short-term changes travel further than sweeping ones — the cheap wins are usually parameter changes with clear downstream benefit.
Watch out Refining in private with allies produces a proposal that only survives contact with people who already agreed.
- 3
Convince progressively more people
Work outward from the research constituency, satisfying each group's concerns in turn. The number of people who must be convinced to push in a particular direction is significant, and it grows as the project matures.
Pro tip Log every concern raised and who raised it; unaddressed concerns resurface at the final gate.
Watch out Skipping a constituency early does not save time, it moves the rejection to a more expensive stage.
- 4
Build a test implementation
Produce working code that demonstrates the change is implementable. This converts an argument about intentions into an argument about an artefact implementers can inspect.
Pro tip A reference implementation from someone outside the proposing team is far more persuasive.
- 5
Formalise it as a written proposal
Turn the work into a fully formalised document — in Ethereum's case an EIP. The written artefact is what a distributed group can actually converge on, and what the record shows later.
Pro tip A fixed template makes competing proposals comparable and shortens the decision meeting.
Watch out An informal agreement that never becomes a document cannot be gated, tracked or appealed.
- 6
Take it to the fixed-cadence implementers call
Bring the formal proposal to a recurring forum of the people who actually write the code — Ethereum's All Core Devs call, once every two weeks. Everything people agree on gets accepted; if people disagree, it does not.
Pro tip The fixed cadence is the mechanism — a standing slot forces proposals to reach a decision state rather than drifting.
Watch out Treating the call as a majority vote rather than a consent check destroys implementers' willingness to attend.
- 7
Bundle into a scheduled upgrade
Accepted changes go into a hard fork, the named protocol upgrade that everyone on the network has to download. Bundling gives the ecosystem one coordination event rather than a stream of them.
Pro tip Publish the bundle contents early enough that dependent projects can test against it before the date.
Watch out Adding a change to the bundle late imposes the coordination cost on everyone downstream.
In the wild
Buterin names EIP-4488 — a short-term decrease in the gas cost of call data, a fairly technical change that makes rollups cheaper in the short term — as the biggest thing he pushes that is not getting adopted. His assessment is blunt: if he had more control it would have been in Ethereum already. Some of the EIPs he personally promotes do not make it in at all, and for many of them he has to try hard to satisfy everyone's concerns. He reports his influence decreasing every six months on a rolling basis.
→ A pipeline demonstrably strong enough to reject the founder's own priority change, which is the evidence that legitimacy has moved from the person to the process.
Four companies maintain independent implementations of a shared data format and keep shipping incompatible extensions. They adopt the pipeline: an open ideas forum, a refinement stage, a written proposal template, a requirement that one implementation ship the change behind a flag before it is discussed formally, and a fortnightly implementers call where anything all four object-free becomes part of the next numbered release. Contentious proposals stall at the call instead of shipping unilaterally.
→ Incompatible unilateral extensions stop, and the numbered releases become something downstream users can actually plan against.
Common mistakes
Collapsing the stages into one meeting
Bringing a raw idea straight to the implementers' call gets it rejected on grounds that the refining and convincing stages exist to handle, and burns credibility for the next attempt.
Reserving a founder override
A pipeline that the founder can bypass is not a pipeline. Its legitimacy comes precisely from the fact that changes the founder wants can and do fail.
Ignoring the closing window
As consent requirements grow, the window for substantial changes narrows. Projects that do not sequence their big architectural changes early find that it gets harder to do big things even when everyone agrees they are needed.
Is it for you?
Best for
Protocols, standards bodies and large open-source projects where no single party can impose a change on independent implementers.
Not ideal for
Early-stage projects that need to move fast with a small team, where staged consent adds cost with no legitimacy benefit yet.
From the transcript
“step one is the idea making stage then step two is the refining stage then there's the stage of convincing more and more people making…”
“this is a call that happens once every two weeks as the name implies all of the core developers come online and talk about all…”
“there's many points along the way where different people have to agree”
From the episode
Vitalik: Ethereum, Part 2