Before the First Line of Code Gets Written

You have an idea for Ethereum. A tweak to gas accounting, maybe, or a new opcode that would make smart contracts 15% cheaper to deploy. You picture it flowing cleanly upward: you propose, developers debate, the network upgrades, and somewhere a changelog bears your name.

That is not what happens.

The actual process is slower, messier, and more robust for it. Ethereum Improvement Proposals go through a layered filtration system that kills most ideas before they ever consume a single minute of a core developer's time. That's not a bug. It's the whole point.

What an EIP Actually Is (and What It Isn't)

An EIP is a design document. Specifically, a structured text file stored in the `ethereum/EIPs` GitHub repository that describes a proposed change to the protocol, a new standard, or a process improvement. The format is standardized: a header with metadata, an abstract, a motivation section, a specification written with enough precision that an independent team could implement it, and a rationale explaining why this approach beats the alternatives.

That last part matters more than people think. Motivation and rationale aren't bureaucratic box-ticking. They're where most weak proposals collapse under their own weight. If you can't explain clearly why the existing system falls short and why your specific solution outperforms the obvious alternatives, the document won't survive its first review.

EIPs split into three types. Core EIPs require a hard fork or consensus-layer change, which is where the real political weight sits. ERCs (Ethereum Request for Comments) define application-layer standards: ERC-20 for fungible tokens, ERC-721 for NFTs, none of it touching the protocol itself. Meta EIPs describe process changes. The filtration intensity scales accordingly, and a Core EIP touching the execution layer gets scrutiny that a new token interface standard simply never will.

The Gauntlet: From Draft to Last Call

Here's where it gets concrete. Say a developer named Priya wants to propose a change to how the EVM handles a specific edge case in CALL instructions. She writes a draft, formats it correctly, and opens a pull request. What happens next is not a vote. It's a sequence of human checkpoints.

First, an EIP editor reviews the submission. Editors are not gatekeepers of ideas; they're gatekeepers of quality. They check that the proposal is formatted correctly, that it isn't a duplicate, that the specification section is actually a specification and not a wish list. If Priya's draft says the behavior should be "more efficient" without defining what that means in deterministic, implementable terms, it comes back for revision. This alone stops a significant fraction of submissions.

Once an editor accepts the draft, it enters `Draft` status. Here is where the real work begins, and where most proposals quietly die. The draft is public, anyone can comment, and the Ethereum developer community has a high tolerance for blunt technical feedback. Priya's proposal will be read by people who have implemented the EVM, people who have found bugs in previous EIPs, people who will immediately spot if her suggested change breaks an invariant she hadn't considered. This phase has no fixed deadline. It can run for months.

If Priya responds to feedback, revises her spec, and builds rough consensus that the idea is sound, she can request a move to `Review`. Other implementers are expected to read it formally. If it's a Core EIP, it starts appearing on the radar of the AllCoreDevs calls, the biweekly meetings where Ethereum's client teams coordinate.

Still, it hasn't been scheduled for inclusion anywhere. It's just on the radar.

`Last Call` is a 14-day window. The EIP editors announce it, signaling that the community has two weeks to raise any remaining substantive objections. Minor editorial fixes can still happen. Fundamental redesigns cannot. If Last Call passes without a blocking objection, the proposal moves to `Final` status.

For a Core EIP, `Final` status still doesn't mean it's shipping. It means the specification is considered complete and technically sound. Whether it actually gets included in a network upgrade is a separate decision, one made by client teams and the broader community, with social consensus doing the heavy lifting.

What People Get Wrong About This Process

The most common misconception is that EIP acceptance equals deployment. It doesn't.

EIP-1559, the fee-market reform that introduced base fee burning, was discussed for over two years before it shipped in the London upgrade. It reached Final status and still required sustained advocacy, economic modeling, miner opposition, and eventually a clear signal from client teams that they'd implement it. The EIP process filtered the technical specification. The deployment decision involved a much broader and messier conversation, and anyone who conflates the two hasn't been paying attention.

The other thing people get wrong: rejection isn't permanent failure. EIP-3074, which proposed new opcodes for account abstraction, was discussed, revised, and eventually superseded by EIP-7702. The process is iterative, not judicial. A proposal that gets torn apart in Draft is often the seedbed for a better proposal six months later.

And here's the part most guides skip. The EIP number itself carries no authority. EIP-4844, which introduced blob transactions for Layer 2 scaling, went through years of development across multiple teams before the Dencun upgrade. The number was assigned early. The shipping happened much later. Confusing a proposal getting a number with a proposal getting traction is an easy mistake, and a costly one if you're trying to read where the protocol is actually headed.

Why the Filter Exists at All

Core developers' time is finite and genuinely scarce. The AllCoreDevs call includes representatives from multiple execution-layer and consensus-layer clients: Geth, Nethermind, Besu, Erigon, Lighthouse, Prysm, and others. Each team has to evaluate, implement, test, and maintain every change that makes it into a network upgrade. A broken specification doesn't just waste meeting time; it creates implementation bugs that can diverge across clients, which in the worst case threatens network consensus.

Think of the EIP process as the subfloor beneath the renovation. Nobody photographs it. Nobody praises it in launch announcements. But the whole structure rests on it, and you find out fast when it's been skipped.

That's also why the community-driven Draft and Review phases matter so much. By the time a Core EIP reaches AllCoreDevs for serious discussion, it should already have survived the scrutiny of the people most likely to find the fatal flaw. Not always. But often enough that the system earns its friction.

So when you're evaluating a proposed protocol change, what's it actually worth? Find its EIP, check its status, read the open issues on the pull request, and count how many client team members have commented. A proposal with three years of active discussion and implementations already prototyped in two clients is a fundamentally different thing from a draft opened last month with no responses. The process leaves a paper trail. The paper trail is the signal.