An Ethereum Improvement Proposal moves from Draft to Final through a sequence of discussion, peer review, client implementation, and — for Core EIPs — scheduling into a hard fork. There is no vote. Approval is observed: an EIP becomes Final when client teams have implemented it, validators have upgraded, and the network has activated the change at a planned block.
​

The process is loosely structured by design. EIP-1, the meta-process document, defines the format and the lifecycle states but deliberately leaves social coordination to forums, calls, and informal consensus. This makes Ethereum governance harder to summarize than systems with explicit voting, but the actual flow is well-defined in practice.
​

Every EIP passes through a defined sequence of statuses. The official statuses, in order, are Draft, Review, Last Call, Final, Stagnant, and Withdrawn. Each transition has rules in EIP-1.

The repository tracks every transition in commit history. Tools like EIPs Insight aggregate the status counts for a quick view of the proposal pipeline.
​

EIP editors are a small group of volunteers who manage the repository's mechanics. Their role is procedural, not approval-granting. Editors check that:

Editors do not decide whether an EIP is good. They do not block proposals on merit. They ensure proposals enter the repository in a reviewable state and assign EIP numbers when they merge a draft. The current editor list is published in EIP-1 and includes contributors like Sam Wilson, Pandapip1, Gajinder Singh, and Alita.
​

The editor handbook is maintained as EIP-5069, which documents the day-to-day procedural conventions.
​

Most EIP discussion happens in three places. Authors are expected to link to a public discussion thread in the EIP header.

For Core EIPs, the most consequential discussion happens on the All Core Devs (ACD) calls. These weekly Zoom calls — alternating between execution-layer and consensus-layer focus — are where client teams negotiate which EIPs make it into the next hard fork. Recordings are public on the Ethereum Protocol YouTube channel.
​

Core EIPs require coordinated client implementation. The process for a typical proposal:

The "scheduling" step is the most opaque to outsiders. It is essentially a rolling-consensus negotiation among client teams, researchers, and the Ethereum Foundation's protocol team. There is no formal vote. Instead, the EIP either makes the fork or doesn't, based on whether teams agree it is ready.
​

ERCs do not require client coordination because they are application-level standards. The path to Final is shorter:

"Final" for an ERC means the specification is settled. Adoption is separate. ERC-20 reached Final quickly but took years to dominate token issuance. ERC-777 reached Final and never achieved meaningful adoption. The Final status is a green light for builders, not a guarantee of network effect.
​

The absence of formal voting is a deliberate choice rooted in two concerns. The first is captured in the principle of "rough consensus and running code," borrowed from IETF protocol governance. Voting privileges majority preference; rough consensus privileges resolved objections. The latter produces more durable standards.
​

The second concern is plutocracy. Any voting scheme based on stake or token holdings would let well-capitalized actors override technical considerations. Ethereum has explicitly rejected this approach for protocol governance, although it remains the norm for individual application governance (Uniswap, MakerDAO, Aave).
​

The trade-off is that observers cannot point to a vote tally to confirm an EIP's status. They have to read the discussion threads, watch ACD calls, and track client implementations. Galaxy's research on Ethereum governance is one of the cleaner outside-perspective overviews.
​

Hard forks are named in pairs: the execution-layer fork takes a city name (Frontier, Homestead, Byzantium, Constantinople, Istanbul, Berlin, London, Shanghai, Cancun, Prague), and the consensus-layer fork takes a star name (Phase 0, Altair, Bellatrix, Capella, Deneb, Electra). Forks are released together; the combined name is a portmanteau (Shanghai + Capella = Shapella, Cancun + Deneb = Dencun, Prague + Electra = Pectra).
​

The schedule is set by working backward from a target activation block. Once ACD agrees on an EIP set, client teams ship release candidates, devnets activate, then testnets, then mainnet. The pattern produces typical fork cadences of 6-12 months between major forks.

For teams building stablecoin payments, EIP cadence determines what features become available and when. Core EIPs reset the cost and capability floor — EIP-4844 drove L2 stablecoin transaction fees down by an order of magnitude in March 2024. ERCs reset the interface floor — ERC-7683 cross-chain intents gives orchestrators a shared format that solvers across multiple platforms can fill.
​

Eco's stablecoin orchestration network spans 15 chains, most of which inherit Ethereum's EIP cadence. When the next Core EIP activates, integrated chains absorb the change through their own client upgrades. When an ERC reaches Final, Eco evaluates whether to support it as a routing primitive in cross-chain intent protocols or in intent-based routing. Tracking the EIP pipeline — which proposals are scheduled, which are stuck — is part of how cross-chain platforms anticipate cost and capability changes.
​

For Core EIPs, the All Core Devs calls produce rolling consensus. There is no formal vote. Client teams agree on which proposals make a hard fork, the EIP gets implemented, and mainnet activation makes it Final. For ERCs, the author moves the proposal through Last Call to Final after the minimum 14-day review window passes without blocking objections.
​

Yes. The EIP repository is open to any contributor. Editors require that the proposal follow the EIP-1 format and include the required sections (abstract, motivation, specification, rationale, security considerations). Quality of proposal does not determine acceptance into Draft — completeness and format do.
​

Highly variable. ERCs can reach Final in months if the design is straightforward and Last Call passes cleanly. 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 from initial draft to mainnet activation; EIP-4844 took about three years.
​

Final means implemented and active (for Core EIPs) or specification-complete (for ERCs). Stagnant means a Draft or Review EIP that has not been updated in six months. Stagnant EIPs are not rejected — they can be revived. The status flags abandonment, not failure.
​

Live and recorded calls are on the Ethereum Protocol YouTube channel. The schedule rotates between ACD-Execution and ACD-Consensus, typically alternating weeks. Notes and agendas are posted to the Ethereum Magicians forum and the ethereum/pm GitHub repository ahead of each call.
​