What Are EIPs? How Ethereum Improvement Proposals Work

An Ethereum Improvement Proposal (EIP) is a formal design document that describes a proposed change to the Ethereum protocol, its clients, or related standards, along with the technical rationale behind it. EIPs are the primary mechanism by which new features, fee mechanisms, token standards, and network upgrades get documented, discussed, and — if they reach consensus — implemented across Ethereum's client software.

Why a formal proposal process exists

Ethereum has no central company or authority that can unilaterally change the protocol. Any modification, from a small technical adjustment to a major upgrade like the one described in /blog/dencun-upgrade-explained, has to be understood, reviewed, and voluntarily adopted by many independent groups: client development teams, node operators, validators, exchanges, and application developers. A written proposal format gives everyone a shared, versioned reference point to discuss instead of relying on scattered conversations. This structure is part of the broader system covered in /blog/how-ethereum-governance-works.

The categories of EIPs

Not every EIP changes consensus rules. They're grouped by type:

• Core — changes to the consensus protocol itself, requiring all node software to upgrade in a coordinated hard fork, discussed further in /blog/how-ethereum-hard-forks-work.
• Networking — changes to how nodes communicate with each other over the peer-to-peer layer.
• Interface — changes to client API standards, affecting how wallets and applications talk to nodes.
• ERC (Ethereum Request for Comments) — application-level standards, such as token formats. These don't require a network upgrade at all since they're conventions that contracts can choose to follow.
• Meta and Informational — process proposals or non-binding guidance that don't change code directly.

A well-known example of an ERC is the token standard that most fungible tokens on Ethereum use, and another defines the standard behind /glossary/nft collections — both are EIPs even though they never require a hard fork.

The lifecycle of an EIP

Most EIPs pass through a defined sequence of statuses:

1. Idea — informal discussion, often starting on community forums.
2. Draft — the proposal is formally written up, assigned a number, and merged into the EIP repository once it meets basic formatting and completeness requirements.
3. Review — the author signals it's ready for peer review from editors and the broader community.
4. Last Call — a final window for objections before the specification is considered stable.
5. Final — the specification is frozen; only clarifications or corrections are allowed afterward.

Proposals can also be marked Stagnant, Withdrawn, or Living (for documents meant to be continuously updated rather than finalized).

Who decides which EIPs get included in an upgrade

Reaching "Final" status doesn't automatically mean an EIP ships. Core EIPs are discussed in recurring public calls attended by client teams and researchers, where proposals are considered for inclusion in a specific scheduled network upgrade. Client teams then need to implement, test, and coordinate the change across multiple independent codebases before it activates — a process explained more fully in /blog/how-ethereum-hard-forks-work. No single team can force an EIP into the network; broad rough consensus among client implementers is required, since a change that isn't adopted by the vast majority of nodes would simply split the chain.

Well-known EIPs and what they did

EIP	What it introduced
EIP-1559	Base fee and burn mechanism, covered in /blog/what-is-eip-1559-base-fee-burn
EIP-20	The standard interface most fungible tokens implement
EIP-721	The standard interface behind most /glossary/nft collections
EIP-4844	Blob-carrying transactions for cheaper L2 data, covered in /blog/what-is-a-blob-transaction

Why the process matters for users, not just developers

Understanding EIPs helps explain why Ethereum behaves the way it does at any given moment — fee structures, available token standards, and the timing of network upgrades all trace back to specific proposals. It's also a useful lens for evaluating claims: a change to how gas is priced, how validators are rewarded, or how /glossary/smart-contract code executes didn't happen by decree — it went through a documented, public proposal that anyone can read.

Limitations of the process

The EIP process is deliberately conservative. It can be slow, since achieving rough consensus across independent teams takes time, and contentious proposals can stall for years in Draft or Review status. This is a tradeoff: the same caution that makes it hard to rush through a bad change also makes it hard to move quickly on urgent ones, which is part of why some scaling work has shifted to the layer 2 ecosystem instead of layer 1, as discussed in /blog/rollup-centric-roadmap-explained.

Who can actually submit an EIP

One often-misunderstood point is that anyone can author an EIP — there's no gatekeeper who decides who is allowed to write one up. In practice, most Core EIPs that go on to be implemented come from researchers and engineers already deeply embedded in Ethereum's development community, simply because writing a technically sound, implementable specification requires real expertise. But ERC-type application standards are frequently proposed by outside developers who identify a common pattern worth standardizing, and the process explicitly welcomes this. Editors — volunteers who maintain the EIP repository — check submissions for basic formatting and completeness, not for whether the idea itself is good; that judgment is left to the broader review process.

How this compares to how other blockchains manage upgrades

Ethereum's EIP process is not unique in concept — most major blockchains have some equivalent structured proposal mechanism, though the details differ. Some networks bake formal on-chain voting into their upgrade process, where token holders directly approve or reject a proposal. Ethereum deliberately avoids this for protocol-level changes, relying instead on the informal rough-consensus process described in /blog/how-ethereum-governance-works. The EIP document itself is simply the technical specification that this consensus process discusses and eventually acts on — the document doesn't carry legal or voting weight on its own.

Bottom line

EIPs are the documented, versioned way Ethereum's community proposes and debates protocol and application-level changes without any central authority making unilateral decisions. Not every EIP requires a network upgrade — many are voluntary application standards — but the ones that do must pass through community review and be adopted by client teams and node operators before they take effect.