EIP (Ethereum Improvement Proposal)

What an EIP looks like

Every EIP follows a defined structure:

• Abstract — short summary.
• Motivation — why the change is needed.
• Specification — technical details of the proposed change.
• Rationale — design choices and alternatives considered.
• Backwards Compatibility — how existing systems are affected.
• Reference Implementation — code (often required before final acceptance).
• Security Considerations — risks and mitigations.

EIPs progress through statuses: Draft → Review → Last Call → Final (or Stagnant/Withdrawn).

EIP categories

EIPs are organized by category:

• Core — protocol-level changes affecting consensus, requiring hard forks.
• Networking — peer-to-peer protocol changes.
• Interface — client API, RPC standards.
• ERC — Ethereum Request for Comment. Application-layer standards (token standards, wallet conventions). The most user-visible category.

The ERC subcategory has become so important that ERC standards are often cited without "EIP" — ERC-20, ERC-721, ERC-4337, etc. They're technically all EIPs in the ERC category.

Notable EIPs

A few that have shaped Ethereum:

• EIP-20 (ERC-20) — fungible token standard. The reason any wallet can hold any token; the foundation of stablecoins, governance tokens, and most of crypto.
• EIP-721 (ERC-721) — non-fungible token standard. The basis for NFTs.
• EIP-1559 (August 2021) — replaced first-price auction gas with a base-fee + tip model. Made gas pricing more predictable; introduced fee burn that has burned millions of ETH since.
• EIP-4337 (March 2023) — account abstraction without protocol-level changes. Enables smart-contract wallets, social recovery, gasless transactions.
• EIP-4844 (March 2024, "Proto-Danksharding") — added blob-carrying transactions, dramatically reducing data costs for Layer 2 rollups.
• EIP-7702 (Pectra upgrade, 2025) — extends some account-abstraction features to existing externally owned accounts.

How EIPs become reality

Implementation follows acceptance:

1. EIP author drafts and proposes; community discusses.
2. Core developers debate inclusion in upcoming hard forks during All Core Developers calls (twice-monthly).
3. Once accepted, client teams (Geth, Nethermind, Besu, Erigon, Reth) implement the change.
4. Testnet activation gives time to find bugs.
5. Mainnet hard fork activates the change at a defined block.

The bar for inclusion is high — Core EIPs must convince a rough consensus of core developers, who weigh technical merit, security implications, and whether the change is worth the disruption of a hard fork.

How this differs from BIPs

BIPs (Bitcoin Improvement Proposals) inspired EIPs and follow similar structure. Cultural differences:

• Bitcoin is conservative — major upgrades are rare (SegWit 2017, Taproot 2021).
• Ethereum upgrades regularly — typical hard forks every 12-18 months bringing meaningful changes.

The trade-off mirrors broader philosophical differences. Bitcoin's conservatism preserves its monetary properties; Ethereum's evolution enables new capabilities at the cost of more frequent disruption.

Where the process strains

A few recurring tensions:

• Coordination cost. All Core Devs calls and informal coordination work for early-stage Ethereum but scale poorly. Larger ecosystems require more formal processes.
• Conservative vs. progressive factions. Some EIPs face years of debate over whether to ship at all. EIP-1559 took several years; some account-abstraction proposals took longer.
• Layer 2 needs. Rollups need protocol features (blobs, precompiles) that benefit them but may not benefit non-rollup users. Allocating EIP attention is increasingly contested.
• Application-level standards. ERCs are widely adopted but sometimes bypassed entirely (some major NFT collections use modified or proprietary standards).

The EIP process remains the canonical way Ethereum evolves, though the volume of activity has stretched the original loose model considerably.