Ethereum Improvement Proposal (EIP)

An Ethereum Improvement Proposal follows a formal lifecycle set out in EIP-1, the document that defines the process itself. Once submitted, a proposal is merged as a Draft by a volunteer EIP editor, whose job is purely procedural: checking formatting and structure, not judging the idea. From there it can move to Review, then Last Call (a minimum 14-day public comment window), and finally Final. Proposals that stall for six months or more are marked Stagnant, and authors can withdraw them entirely.

EIPs fall into a few categories. Core EIPs change consensus rules and need coordinated client upgrades activated through a network-wide hard fork. Networking and Interface EIPs cover peer-to-peer protocols and language-level conventions. ERC EIPs define application-level standards that developers voluntarily adopt, such as ERC-20 for fungible tokens or ERC-721 for NFTs. A separate Meta category governs process changes rather than the protocol itself.

There is no formal vote. Core EIPs advance through rolling consensus among client teams on the All Core Devs calls; an EIP only becomes Final once it has actually activated on mainnet. Landmark examples include EIP-1559, which restructured transaction fees, and EIP-4844, which introduced blob storage for rollups. The system, modeled on Bitcoin's BIP process, lets anyone in the Ethereum community propose and debate changes transparently.