EIP (Ethereum Improvement Proposal)
A formal design document that proposes changes to the Ethereum protocol, standards, or processes — the primary mechanism through which developers submit, debate, and implement network upgrades.
The EIP process has evolved: EIP-4337 (account abstraction) notably achieved wide adoption without a hard fork by defining a UserOperation mempool and bundler architecture as a standards-track EIP that operates entirely at the application layer.
graph LR
Center["EIP (Ethereum Improvement Proposal)"]:::main
Rel_eips["eips"]:::related -.-> Center
click Rel_eips "/terms/eips"
Rel_ethereum["ethereum"]:::related -.-> Center
click Rel_ethereum "/terms/ethereum"
Rel_eip_4844["eip-4844"]:::related -.-> Center
click Rel_eip_4844 "/terms/eip-4844"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧠 Knowledge Check
🧒 Explain Like I'm 5
[Ethereum](/en/terms/ethereum) is like a global computer run by thousands of people. Nobody owns it, so nobody can just change the rules alone. An EIP is like a formal written suggestion box: any developer can write up a detailed proposal saying 'I think we should change rule X to Y, here is exactly how it works and why.' The community then debates it. If enough people agree and the core engineers implement it, the change becomes part of Ethereum's rules at the next network upgrade.
🤓 Expert Deep Dive
EIP Categories and Sub-types
- Core EIPs require a consensus hard fork (e.g., EIP-1559, EIP-4844). All Ethereum client implementations (Geth, Nethermind, Besu) must implement the change simultaneously at the scheduled block or epoch.
- ERC (Ethereum Request for Comments) are Interface-level standards. They don't require a hard fork — they define APIs that any smart contract can optionally implement. ERC-20 defines transfer(), balanceOf(), approve(), allowance(). ERC-721 adds ownerOf() and tokenURI() for non-fungible tokens.
EIP-1559 — Fee Market Reform
Pre-1559, gas pricing was a first-price auction: users bid gas prices blindly. This caused extreme fee volatility. EIP-1559 introduced a protocol-computed baseFee that is burned (removed from supply) and adjusts per block to target 50% block utilization. Users set a maxFeePerGas and a priorityFee (tip to the validator). Crucially, the burn mechanism made ETH slightly deflationary during high-activity periods.
EIP-4844 — Proto-Danksharding (Blobs)
Introduced a new transaction type (Type 3) carrying ephemeral data 'blobs' (~128 KB each). Blobs are available to nodes for ~18 days then pruned. L2 rollups post their compressed transaction batches as blob data instead of calldata, reducing their L1 data costs by 10–100x. This was the first step toward full danksharding.
Governance Reality
EIPs do not automatically become law. The actual governance is 'rough consensus' among: the EIP authors, AllCoreDevs call participants (Ethereum Foundation researchers + client team leads), and ultimately validators/node operators who decide to run the updated client software.
❓ Frequently Asked Questions
What is the difference between an EIP and an ERC?
An ERC (Ethereum Request for Comments) is a sub-category of EIP. EIPs can change the core Ethereum protocol (requiring a hard fork). ERCs define application-level standards (like ERC-20 or ERC-721) that any smart contract can implement voluntarily, without changing the underlying protocol.
Does an EIP automatically become part of Ethereum when finalized?
No. A 'Final' status means the EIP is technically complete and well-specified, not that it has been deployed. For Core EIPs, deployment requires client teams to implement the change and validators to upgrade their nodes at a scheduled hard fork.
Why did EIP-1559 make ETH deflationary?
EIP-1559 burns the base fee — it is permanently removed from the ETH supply. During periods of high network activity, the burn rate can exceed the rate of new ETH issuance to validators, making the net supply of ETH decrease (deflationary).