Inside the Ethereum Improvement Proposal Process

The EIP process is adversarial by design. Every major change, from EIP-1559 to the Dencun upgrade, faces public scrutiny from core developers, client teams like Nethermind and Geth, and the community. This friction prevents unilateral control and forces consensus through technical debate, not corporate decree.

Messy politics produce robust solutions. The multi-client model, requiring independent implementations from Geth, Erigon, and Besu, is a direct result of this governance. It creates a natural security check against bugs and ensures no single entity dictates the chain's evolution.

Compare this to competitor chains. Solana and Avalanche prioritize speed of execution with more centralized development. Ethereum's slower, contentious path yields upgrades that are more secure and widely adopted because they survive the gauntlet of public criticism.

Evidence: The Merge. The transition to Proof-of-Stake succeeded because years of public EIP debates, multiple testnets, and client diversity (Prysm, Lighthouse) eliminated single points of failure. The chaos was the validation mechanism.

The EIP Repository is the source. All protocol changes start as a GitHub pull request to the Ethereum/EIPs repository, following templates for Core, ERC, or Meta EIPs. This creates a permanent, public record and initial technical specification.

Core Devs are the gatekeepers. An EIP author must champion their proposal through Ethereum Magicians forums and, critically, the All Core Devs (ACD) calls. Without developer consensus for inclusion, an EIP stalls. The ACD calls are the real battleground where trade-offs between clients like Geth, Nethermind, and Besu are debated.

Testnets are the proving ground. Once accepted for a hard fork, EIPs undergo deployment on sequential testnets (Sepolia, Holesky, Goerli). Client teams use this phase to identify consensus bugs and performance regressions before mainnet risk. The Dencun fork's rollout on testnets revealed critical blob propagation issues.

Mainnet activation is a hard fork. A coordinated block height triggers the fork. Post-activation, EIP success is measured by adoption and security. EIP-1559's fee market reform succeeded; EIP-2537's BLS precompiles saw limited use, demonstrating the market's role as final arbiter.

The EIP process is a formalized anarchy. It provides a structured forum for conflict, not a top-down command chain. Anyone can propose changes, but adoption requires rough consensus from core developers, client teams like Nethermind and Geth, and the broader ecosystem.

Governance power is diffused, not absent. Final authority rests with client teams who must implement changes. This creates a veto power dynamic where a single team's refusal can stall an EIP, as seen with past EIP-3074 debates.

The real bottleneck is social consensus. Technical merit is necessary but insufficient. Proposals must navigate All Core Devs calls, gather feedback from major protocols like Uniswap and Lido, and survive community scrutiny on forums like Ethereum Magicians.

Evidence: The multi-year journey of EIP-4844 (Proto-Danksharding) demonstrates the system's rigor. It evolved through countless iterations, testnets like Holesky, and client implementations before its 2024 mainnet activation, proving the process filters for network-critical upgrades.

EIPs are a filtering mechanism that separates viable protocol upgrades from community noise. The process begins with an idea draft, moves to a formal specification, and requires rigorous peer review before finalization. This ensures only proposals with clear technical merit and broad consensus advance.

Core Devs hold implementation power, but the community drives consensus. While teams like the Ethereum Foundation's R&D or client teams (Geth, Nethermind) build the code, acceptance depends on rough consensus from developers, miners (pre-Merge), and stakers. This creates a balance between central coordination and decentralized approval.

The 'Meta-EIP' process itself evolves. EIP-1, the original process document, is regularly updated. Recent changes formalize the role of Ethereum Magicians forums for early discussion and introduced the Ethereum Cat Herders to shepherd proposals, reducing core developer overhead.

Evidence: Of over 10,000 EIPs submitted to the GitHub repository, fewer than 200 have reached 'Final' status. This sub-2% acceptance rate demonstrates the process's extreme selectivity, prioritizing stability over rapid, untested change.