They might not trend on Crypto Twitter—but without them, Ethereum wouldn't run this smooth. - Allan Robinson
🧭 What Are EIPs and ERCs?
EIPs (Ethereum Improvement Proposals) are Ethereum’s official feature requests or improvements, typically targeting protocol-level changes (e.g., transaction formats, gas fees).
ERCs (Ethereum Request for Comments) are a subset of EIPs focused on smart contract standards, used to ensure compatible interfaces across dApps.
They emerged as community-driven blueprints to evolve Ethereum in a consistent, transparent, and coordinate-driven way.
📜 History & Impact
The EIP process began with EIP-1 in 2015 to formalize how Ethereum should evolve.
Early successful proposals like EIP-20 (ERC-20) established core patterns for the ecosystem.
Over time, new needs arose: better transaction gas efficiency, clearer contract interoperability, and fairer developer incentives.
Thanks to EIPs and ERCs, Ethereum continues to grow backward-compatible while integrating new features without breaking older systems.
🛠️ Deep Dive into 4 Selected Standards
1. EIP‑2930: Access Lists (Core / Transaction Format)
🔍 Overview
Introduced in Berlin (2020) as part of a suite addressing storage cost spikes (alongside EIP-2929)
Lets you pre-declare which contract addresses/storage slots your tx will access.
Those slots are “pre-warmed” at lower cost, avoiding high “cold” access charges.
✅ Benefits
Saves ~200 gas per storage access
Reduces volatility and DoS attack risk from expensive cold storage.
❌ Drawbacks
Requires users/devs to predict exactly which slots will be used—mistakes can cost more gas than savings.
Adoption has been low: just ~1.5% of txs use it despite 42% potential benefit
⚙️ Analogy
Think of it like a grocery preorder: tell the store what you’ll need in advance and skip checkout lines—but if you order the wrong things, you wasted time and money.
2. EIP‑7547: Inclusion Lists (Core / Block Assembly)
🔍 Overview
A new proposal letting block proposers force inclusion of specific transactions in a block, reducing censorship
Especially useful for front-running, MEV-resistant applications.
✅ Benefits
Enhances fairness and censorship resistance in the mempool.
Empowers transaction originators to battle MEV-based exclusion.
⚠️ Considerations
Still under development.
Needs client & tooling support to become practical.
⚙️ Analogy
It’s like a VIP pass for users who want to ensure their ticket gets scanned even during rush hour.
3. ERC‑165: Interface Detection (Contract Interface Standard)
🔍 Overview
Standardizes how contracts announce which interfaces they implement—used widely since 2018
Contracts implement supportsInterface(bytes4 interfaceID) so others can detect capabilities.
✅ Benefits
Enables dynamic compatibility checks for wallets/dApps.
Avoids hard-coded assumptions, reducing risk of breakage.
❌ Drawbacks
Needs explicit implementation—some contracts skip it to save gas.
Only covers declared interfaces; doesn’t guarantee full compliance.
⚙️ Analogy
Like a software installer that checks if your system supports .NET 6 before installation—no surprises later.
4. EIP‑6969: Revenue-Sharing Contracts (ERC – Token & Wallet Standard)
🔍 Overview
-
A new proposal for sharing transaction fees (beyond ETH’s built-in burn/tip) with contract creators
- Users opt-in to send a developer fee to the dApp creator on each use.
✅ Benefits
Creates an incentive model for public dApps to be sustainable.
Offers an optional “tip” model for open-source contract authors.
⚠️ Controversies
May discourage usage if tips are high.
Needs to balance opt-in vs auto-fee structures.
⚙️ Analogy
Like paying 10% tip for offline delivery services you trust—optional but appreciated.
📊 Comparison Table
| EIP/ERC | Category | Purpose | Adoption Status |
|---|---|---|---|
| EIP‑2930 | Core / Tx | Improve gas for predefined access | Low adoption (~1.5%) |
| EIP‑7547 | Core / Blocks | Censorship resistance via inclusion lists | Early draft |
| ERC‑165 | Interface | Standard method to declare support | Widely adopted (NFTs, tokens) |
| EIP‑6969 | ERC / Payments | Revenue-sharing tips to contract authors | Emerging interest |
🔍 Final Takeaways
Access Lists (EIP‑2930) streamline gas costs—but you must think ahead.
Inclusion Lists (EIP‑7547) will help fairness in transaction ordering, ideal for censor-resistant apps.
ERC‑165 remains vital for automatic interface compatibility, powering wallet and dApp integrations.
Revenue-sharing (EIP‑6969) introduces an open tipping model, potentially sustaining free-to-use contracts.
🎯 Why These Matter for Beginners
-
Understanding why these standards were invented helps future developers reason about protocol design and usability, not just code.
- Seeing each EIP as a solution to a real problem—gas costs, censorship, interface detection, developer sustainability—makes you think like a protocol designer.
- Analogies keep concepts memorable and relatable.
Standards aren’t just code—they shape how Ethereum grows. - Allan Robinson
Top comments (0)