EIPs and ERCs are often used interchangeably, but they describe two distinct things. An Ethereum Improvement Proposal (EIP) is the broad governance format used to propose any change to Ethereum, ranging from consensus rules to wallet RPC behavior. An Ethereum Request for Comments (ERC) is one specific category of EIP that defines application-level standards, such as the token interfaces that wallets and dapps rely on. Every ERC is an EIP; not every EIP is an ERC.
​

The distinction matters because the two operate at different layers. A change to how blocks are validated requires every Ethereum client to update. A new token standard only requires the contracts and apps that opt into it. Both routes start in the ethereum/EIPs GitHub repository, where authors open pull requests and editors assign numbers.
​

An EIP is a design document that describes a proposed change to Ethereum. The format was introduced in October 2015 by Martin Becze, Hudson Jameson, and others, modeled after Bitcoin Improvement Proposals (BIPs) and Python Enhancement Proposals (PEPs). Each EIP includes a header, abstract, motivation, technical specification, rationale, and security considerations.
​

EIPs are tracked in three top-level categories defined by EIP-1, the meta-process document:

As of late 2024 the repository contains over 7,500 numbered EIPs, with roughly 400 in Final status according to the official EIPs index. The vast majority are still Draft, Stagnant, or Withdrawn, which reflects how the process filters ideas before they become standards.
​

An ERC is the application-layer subset of Standards Track EIPs. The category covers smart contract interfaces, wallet behaviors, and metadata schemas — anything that lives above the protocol but needs interoperability between independent implementations. The ERC index lists every proposal in this category, from token contracts to message-signing formats.
​

The most widely deployed ERCs include:

Both EIPs and ERCs share a single numerical sequence. EIP-20 and ERC-20 refer to the same document; the prefix changes based on which category readers are emphasizing. The number is assigned by an EIP editor when a pull request is merged into draft status.
​

The numbering scheme has produced some confusion. Early proposals were filed only as ERCs because the Standards Track distinction came later, which is why the foundational token standards live at low numbers. Newer ERCs sit in the four- and five-digit range. The repository now uses separate folders — EIPS/ and ERCS/ — but the underlying number space is unified.
​

Status flows through six stages: Draft, Review, Last Call, Final, Stagnant, and Withdrawn. Only Final EIPs and ERCs are considered settled. Stagnant EIPs are those untouched for six months in Draft status; they remain in the repository but signal that authors moved on. The EIPs Insight dashboard tracks status counts in real time.
​

Builders working on stablecoin payments, treasury automation, or cross-chain transfers encounter both layers in practice. A new ERC like ERC-7683 cross-chain intents changes how applications coordinate orders, but it does not require an Ethereum hard fork. Adoption depends on solvers, wallets, and protocols choosing to integrate it. Cross-chain orchestration platforms like LI.FI, Across, and Eco have begun adding ERC-7683 support since the standard's mid-2024 publication.
​

A core EIP like EIP-4844 (blob transactions) is the opposite. It activated on March 13, 2024 with the Dencun hard fork, which required every Ethereum client — Geth, Nethermind, Erigon, Besu, Reth — to ship updated software within the same window. Layer 2s like Arbitrum, Optimism, and Base saw posting costs drop by roughly 90% within days of activation, according to Dune dashboards tracking blob fees.
​

Knowing whether a proposal is an ERC or a Core EIP tells builders what their integration timeline looks like. ERCs are usually a contract change. Core EIPs require waiting for a hard fork and confirming client compatibility across the chains a team supports.
​

Every EIP follows the format defined by EIP-1. The standard sections are abstract, motivation, specification, rationale, backwards compatibility, test cases, reference implementation, and security considerations. Skipping straight to the specification is tempting but usually wrong; the motivation and rationale sections explain why the design is shaped the way it is.
​

For developers integrating a standard, the order of priority is usually:

For Core EIPs, the specification is also where activation parameters live. EIP-1559 specified the 30M gas limit and 12.5% adjustment cap; EIP-4844 specified the 6-blob cap and 18-day pruning window; EIP-7702 specified the Type 4 transaction format and authorization signature scheme.
​

Three concrete examples show how the EIP/ERC distinction plays out in real integrations:

The pattern is consistent. ERCs are integration points for application developers. Core EIPs are infrastructure shifts that integrators absorb but rarely have to reason about directly, beyond knowing the activation date and any parameter changes.
​

Three patterns of confusion show up regularly in developer forums and grant applications:

Eco's stablecoin orchestration network spans 15 chains, most of which are EVM-equivalent and inherit Ethereum's EIP cadence. When a Core EIP activates, the integrated chains absorb the change through their own client upgrades. When a new ERC reaches Final — particularly ones touching tokens, intents, or account abstraction — Eco's routing layer evaluates whether to support it as a primitive in intent-based routing or stablecoin swap aggregation.
​

For teams building on stablecoins, the ERC layer matters more day-to-day. Token contracts, signing schemes, vault interfaces, and intent formats all live there. Eco's developer-facing surfaces use ERC-20 for stablecoin movement, EIP-712 typed-data signing for intents, and is evaluating ERC-7683 for cross-orchestrator interoperability.
​

Yes. ERC is one of four subcategories under Standards Track EIPs, alongside Core, Networking, and Interface. Every ERC went through the EIP submission process and shares the same numerical sequence. The terms refer to the same document; "ERC" emphasizes the application-standards lens.
​

Rarely, but it has happened during early review. Editors may reclassify a proposal if it touches application interfaces rather than client behavior. Once a proposal reaches Final, the category is fixed. Most reclassifications happen in Draft status before community review begins.
​

Both live in the same ethereum/EIPs repository on GitHub, maintained by a rotating group of EIP editors. The editor list is public and includes contributors like Sam Wilson, Pandapip1, and Gajinder. Editors do not approve content — they enforce format rules and assign numbers.
​

Adoption varies widely. ERC-20 took roughly two years to dominate token issuance after its 2015 publication. ERC-4626 reached majority share among new yield vaults within 18 months of finalization. Some ERCs, like ERC-777, never achieved meaningful adoption despite reaching Final status because contract authors preferred the original ERC-20 interface.
​

None. They refer to the same document — Fabian Vogelsteller's November 2015 fungible token standard. The proposal predates the formal split between Core and ERC categories, which is why both names are valid. Most documentation today uses ERC-20.
​