An Ethereum Improvement Proposal (EIP) is the formal design document Ethereum uses to propose changes to the protocol, the network's standards, or the process itself. Each EIP includes an abstract, motivation, specification, rationale, and security considerations, and lives in the open ethereum/EIPs GitHub repository. The format was introduced in October 2015 by core developers including Martin Becze, Hudson Jameson, and Vitalik Buterin, modeled after Bitcoin Improvement Proposals (BIPs) and Python Enhancement Proposals (PEPs).
EIPs are the channel through which Ethereum evolves. New token standards, fee-market changes, account abstraction, blob transactions, hard fork upgrades — every major change to how Ethereum works started as an EIP. As of late 2024 the repository contains over 7,500 numbered proposals, with roughly 400 in Final status according to the official EIP index.
What Is the Structure of an EIP?
Every EIP follows a fixed format defined by EIP-1, the meta-process document. The required sections are:
Header — preamble with EIP number, title, author, type, category, status, created date, and discussion link.
Abstract — a short summary of what the proposal does.
Motivation — why the change is needed.
Specification — the technical details of the proposed change, written precisely enough that an independent implementer could reproduce it.
Rationale — design choices and alternatives considered.
Backwards Compatibility — what existing behavior the change affects.
Test Cases — examples that implementations must satisfy.
Reference Implementation — code or pseudocode demonstrating the change.
Security Considerations — risks introduced or mitigated.
The format constraint matters because EIPs are read by client developers, security researchers, and downstream integrators. A vague specification cannot be implemented consistently across the five execution clients (Geth, Nethermind, Erigon, Besu, Reth) and five consensus clients (Prysm, Lighthouse, Teku, Lodestar, Nimbus) that run the network.
Types of EIPs
EIP-1 defines three top-level categories:
Standards Track — proposals that affect most or all Ethereum implementations. Subdivided into Core, Networking, Interface, and ERC.
Meta — proposals about the EIP process itself, such as EIP-1 (the process) and EIP-5069 (editor handbook).
Informational — proposals describing design issues or guidelines without specifying a new feature.
The Standards Track subdivisions cover different layers of the stack:
Core EIPs require consensus changes and ship via hard forks. Examples: EIP-1559 (fee market reform), EIP-4844 (blob transactions), EIP-7702 (EOA delegation).
Networking EIPs specify peer-to-peer protocol changes, like devp2p messages or discovery rules.
Interface EIPs cover client API and RPC standards, such as JSON-RPC method signatures.
ERC (Ethereum Request for Comments) EIPs define application-level standards: token interfaces, signing schemes, vault contracts. ERC-20, ERC-721, ERC-4337, and ERC-7683 are all in this subcategory.
The distinction between EIP and ERC is one of scope. Every ERC is an EIP, but not every EIP is an ERC. ERC-20 and EIP-20 refer to the same document; the prefix changes based on which lens — application-level or protocol-level — readers are emphasizing. For more detail see EIP vs ERC: What's the Difference?.
How Does the EIP Lifecycle Work?
Every EIP passes through a defined sequence of statuses. The official progression is:
Draft — the initial state when an editor accepts the proposal into the repository. Authors iterate freely.
Review — the author requests broader feedback. Optional but often used.
Last Call — a fixed-duration final review window of at least 14 days.
Final — implemented and accepted as a standard. For Core EIPs, this requires actual mainnet activation. For ERCs, the specification is settled.
Stagnant — a Draft or Review EIP untouched for six months. Stagnant EIPs can be revived.
Withdrawn — explicitly retracted by the author. Permanent.
For Core EIPs, the path from Draft to Final routes through the All Core Devs (ACD) calls — weekly Zoom calls where execution-layer and consensus-layer teams negotiate which proposals make it into the next hard fork. Calls are recorded on the Ethereum Protocol YouTube channel. There is no formal vote; consensus emerges through discussion until client teams agree the EIP is ready.
For ERCs, the path is shorter. Once Last Call closes without blocking issues, the ERC moves to Final. Adoption is a separate matter; an ERC reaching Final means the specification is settled, not that anyone has integrated it. ERC-777 reached Final but never achieved meaningful adoption. ERC-20 reached Final and dominated token issuance within two years. The full process is covered in How EIPs Get Approved: The Ethereum Governance Process.
Who Maintains the EIP Repository?
EIP editors are a small group of volunteers who manage the repository's mechanics. Their role is procedural, not approval-granting. Editors verify that proposals follow the EIP-1 format, include required sections, and have a clear technical specification. They do not decide whether an EIP is good. The current editor list includes contributors like Sam Wilson, Pandapip1, Gajinder Singh, and Alita, with the editor handbook documented as EIP-5069.
Most discussion happens on three platforms. The Ethereum Magicians forum hosts public threads for each EIP. The GitHub pull requests and issues capture review comments from editors and client teams. The Eth Research forum hosts higher-level rationale debates, especially for Core EIPs touching consensus or cryptography.
Notable EIPs and Their Impact
A handful of EIPs have reset the cost or capability floor for the entire Ethereum stack. The most consequential since 2021:
EIP-1559 (London, August 2021) — replaced first-price gas auctions with a base fee plus tip. Made next-block fees estimable and burned the base fee, removing it from validator revenue. Cumulative ETH burn exceeds 4.6 million according to ultrasound.money.
EIP-4844 (Dencun, March 2024) — introduced blob transactions, dropping Layer 2 data posting costs by roughly 90% within the first week.
ERC-4337 (March 2023) — brought account-abstraction features to Ethereum without a hard fork. Powered by smart-account contracts, UserOperations, bundlers, and paymasters.
EIP-7702 (Pectra, May 2025) — let externally owned accounts delegate to smart contracts temporarily, bringing smart-wallet features to existing EOAs without forced migration.
ERC-20 (November 2015) — defined the fungible token interface. Powers stablecoins, governance tokens, and most onchain assets.
ERC-7683 (July 2024) — defined a shared cross-chain intent format, letting solvers fill orders across multiple orchestrators with one integration.
For a developer-focused list see Top 10 EIPs Every Developer Should Know.
How EIPs Affect Stablecoin and Cross-Chain Infrastructure
For teams building stablecoin payments and cross-chain routing, EIP cadence determines what features become available and when. Core EIPs reset the cost or capability floor — EIP-4844 drove L2 stablecoin transaction fees down by an order of magnitude in March 2024, expanding the addressable market for retail-sized transfers. ERCs reset the interface floor — ERC-7683 cross-chain intents gives orchestrators a shared format that solvers across multiple platforms can fill, reducing per-platform integration cost.
Eco's stablecoin orchestration network spans 15 chains, most of which are EVM-equivalent and inherit Ethereum's EIP cadence. When a Core EIP activates, integrated chains absorb the change through their own client upgrades. When an ERC reaches Final — particularly proposals touching tokens, intents, or account abstraction — Eco evaluates whether to support it as a primitive in cross-chain intent protocols or in stablecoin swap aggregators.
For developers integrating stablecoin movement, the ERC layer matters most day to day. Token contracts (ERC-20), signing schemes (EIP-712), vault interfaces (ERC-4626), and intent formats (ERC-7683) all live there. Eco uses ERC-20 for asset transfers, EIP-712 typed-data signing for intents, and supports both ERC-4337 and EIP-7702 for account-abstracted flows.
How to Track and Read EIPs
The primary sources for tracking EIPs:
eips.ethereum.org — the official rendered version of every EIP, organized by status.
ethereum/EIPs GitHub — the repository hosting raw EIP markdown files and pull requests.
EIPs Insight — a dashboard tracking status counts and recent activity.
ethereum/pm — meeting notes and agendas for All Core Devs and other working groups.
Ethereum Magicians — discussion forum where most EIPs have an active thread.
For client teams, integrators, and security researchers, monitoring the EIP pipeline is part of standard operational hygiene. New Core EIPs scheduled into an upcoming hard fork need integration work weeks or months ahead of activation. New ERCs reaching Final may unlock features that warrant a contract upgrade or a UX update.
FAQ
What does EIP stand for?
Ethereum Improvement Proposal. The format was introduced in October 2015, modeled after Bitcoin Improvement Proposals and Python Enhancement Proposals. Every proposed change to Ethereum's protocol or standards is filed as an EIP.
What's the difference between an EIP and an ERC?
An ERC is one specific category of EIP — application-level standards like token interfaces and signing schemes. Every ERC is an EIP; not every EIP is an ERC. Core EIPs (consensus changes), Networking EIPs, and Interface EIPs are also EIP categories but not ERCs. ERC-20 and EIP-20 refer to the same document.
Who decides whether an EIP becomes a standard?
For Core EIPs, the All Core Devs calls produce rolling consensus among client teams. There is no formal vote. Once teams agree the EIP is ready, it gets implemented and scheduled into a hard fork; mainnet activation makes it Final. For ERCs, the author moves the proposal through Last Call to Final after the minimum 14-day window passes without blocking objections.
How do I propose an EIP?
Open a pull request to the ethereum/EIPs repository with your proposal in the format defined by EIP-1. Editors will review for format compliance and merge into Draft. Discussion happens on Ethereum Magicians and in the PR. The full process is documented in EIP-1.
How long does an EIP take to reach Final?
Highly variable. ERCs can reach Final in months if the design is straightforward. Core EIPs typically take a year or more, including drafting, discussion, client implementation, devnet testing, and hard fork scheduling. EIP-1559 took roughly two years; EIP-4844 took about three.