Ethereum Improvement Proposal (EIP)

An Ethereum Improvement Proposal (EIP) is the primary mechanism for proposing, discussing, and standardizing changes to the Ethereum protocol and its application layer. Modeled after Bitcoin's BIPs (Bitcoin Improvement Proposals), EIPs provide a transparent, collaborative framework for the community to introduce enhancements. Each proposal is assigned a unique number and follows a specific template, detailing the technical specification, rationale, and potential backwards compatibility implications. This process ensures that all changes are thoroughly vetted before potential inclusion in a network upgrade.

EIPs are categorized into three main types: Core EIPs require a consensus-layer fork (e.g., EIP-1559 for fee market changes), Networking EIPs affect the peer-to-peer communication protocol, and ERC (Ethereum Request for Comment) EIPs define application-level standards, such as token interfaces (ERC-20) or non-fungible tokens (ERC-721). The lifecycle of an EIP progresses through stages: Draft, Review, Last Call, Final, and ultimately Active or Withdrawn, with core EIPs requiring broad community and client developer consensus for activation.

The governance process is open and decentralized. Anyone can author and submit an EIP via the Ethereum GitHub repository. Key decisions, especially for core changes, are made through rough consensus among Ethereum client developers, miners/validators (historically), and the broader community, rather than by a central authority. This process has been instrumental in implementing major upgrades like the London hard fork, which included the fee-burning mechanism from EIP-1559, and the foundational standards that underpin the entire DeFi and NFT ecosystem.

An Ethereum Improvement Proposal (EIP) is a formal, standardized design document for proposing new features, processes, or standards to the Ethereum ecosystem. The term and process were directly inspired by Bitcoin Improvement Proposals (BIPs) and, more distantly, by the Request for Comments (RFC) process used to develop internet protocols. This lineage establishes EIPs as the primary mechanism for collaborative, transparent, and peer-reviewed technical governance in Ethereum, moving development from informal discussions to structured, trackable specifications.

The EIP system was formally introduced in 2015 by Ethereum co-founder Vitalik Buterin with EIP-1, which itself defines the EIP process. This meta-proposal codified the rules for authorship, discussion, and acceptance, creating a canonical repository for all protocol changes. The creation of EIP-1 was a pivotal step in Ethereum's maturation, transitioning the project from a startup-like environment with ad-hoc decision-making to a decentralized, open-source project with a clear governance pathway for core developers and community contributors alike.

EIPs are categorized into three primary tracks: Core EIPs for consensus-critical protocol upgrades (like the London hard fork's EIP-1559), ERC (Ethereum Request for Comments) for application-level standards (like ERC-20 for tokens), and Meta EIPs for process changes. This taxonomy organizes proposals by their scope and impact, ensuring that changes to the base layer undergo the most rigorous scrutiny while application standards can evolve more fluidly within the developer community.

The lifecycle of an EIP—from Draft to Review, Last Call, Final, and Active—is meticulously defined. Key stages involve peer review on the Ethereum Magicians forum, implementation in client software, and, for Core EIPs, activation via a network hard fork. This structured progression ensures that only thoroughly vetted and widely supported changes are integrated into the live network, balancing innovation with the stability required for a global settlement layer.

The historical success of the EIP process is evident in landmark upgrades. For instance, EIP-1559 (2021) revolutionized the fee market, while EIP-4844 (2024) introduced proto-danksharding for scaling. The system's endurance proves that a decentralized, document-driven process can effectively coordinate the evolution of a multi-billion dollar protocol, setting a benchmark for blockchain governance.

An Ethereum Improvement Proposal (EIP) is a formal design document that provides information to the Ethereum community, describing a new feature, process, or standard. The process begins with an Idea discussed on forums like Ethereum Magicians. A champion then drafts the proposal as an EIP, following a strict template, and submits it as a Draft to the official EIPs repository on GitHub. This initiates a period of public review and technical discussion.

The proposal then enters the Review phase, where it is scrutinized by relevant subject-matter experts and the broader community. For core protocol changes (Core EIPs), this involves deep technical analysis by Ethereum client developers and researchers. The Ethereum Cat Herders and EIP Editors play crucial roles in facilitating this process, ensuring proposals are well-specified and ready for consideration. A proposal may be revised multiple times based on feedback before moving forward or being withdrawn.

For an EIP to be accepted, it must reach Consensus among key stakeholders, particularly for changes affecting the core protocol's consensus rules. This consensus is not a formal vote but a general agreement from client teams, miners/validators (historically), and the community that the change is safe and beneficial. Once consensus is achieved, a Core EIP is scheduled for inclusion in a specific network upgrade, or hard fork, such as London or Shanghai.

The final stage is Implementation & Deployment. Client teams (like Geth, Nethermind, Besu) independently code the change into their software. After rigorous testing on testnets, the upgrade is activated on the Ethereum Mainnet at a predetermined block height. For non-core EIPs, such as ERC standards (e.g., ERC-20, ERC-721), the process concludes when the standard is Finalized and adopted by application developers, becoming a canonical reference for the ecosystem.

The EIP process was formally established in 2015 with EIP-1, authored by Martin Becze and Vitalik Buterin, which defined the process itself. Modeled after Python's PEP system, it created a standard template and workflow for submitting technical specifications. This early structure established core concepts like the Ethereum Request for Comments (ERC) subcategory for application-level standards, the role of EIP Editors, and the lifecycle states from Draft to Final. The process was initially managed through a single GitHub repository, fostering open collaboration but requiring significant self-coordination from authors.

A major evolution occurred with the introduction of the Ethereum Magicians forum and the All Core Devs (ACD) calls. The forum provided a dedicated space for broader community discussion and consensus-building before formal submission, while the ACD calls became the primary venue for core protocol developers to discuss, prioritize, and schedule Ethereum Virtual Machine (EVM) and consensus-layer EIPs for network upgrades. This bifurcation separated high-level ideation from technical implementation planning, creating a more structured pipeline for proposals affecting the protocol's base layer.

Further formalization came with the creation of specialized working groups and the EIP-IP (Improvement Proposal) process. Groups like the ERC-4337 team for account abstraction or the EIP-1559 team for fee market reform allowed for focused, long-term development of complex proposals. The EIP-IP process, outlined in documents like EIP-5069, introduced more rigorous stages—including Idea, Draft, Review, Last Call, and Final—with clear entry and exit criteria, making the progression of an EIP more transparent and predictable for all participants.

The process continues to adapt, with recent discussions focusing on streamlining editor workflows, improving accessibility for non-technical contributors, and managing the lifecycle of deprecated EIPs. The evolution reflects Ethereum's maturation from a startup project to a global, decentralized infrastructure, requiring a governance process that balances open participation, technical rigor, and operational efficiency to steward the network's ongoing development.