An Ethereum ERC standard is a published specification that defines how applications, tokens, and smart contracts behave on Ethereum's application layer. ERC stands for Ethereum Request for Comment, the subset of Ethereum Improvement Proposals (EIPs) that governs interfaces rather than the protocol core. ERC-20, published in 2015 by Fabian Vogelsteller, set the interface all fungible tokens now follow, which unlocked the modern DeFi stack.
​

This article covers what ERCs are, how they move from idea to finalized standard, the most consequential ones in active use, and how the ERC system shapes stablecoin infrastructure and cross-chain protocols in 2026.
​

An Ethereum ERC standard is an application-layer specification that defines a common interface for smart contracts, tokens, or wallet behaviors on Ethereum. Unlike core protocol changes, ERCs do not modify how Ethereum nodes reach consensus. They define how onchain software communicates. Any developer can implement one without touching consensus rules, since a standard only governs function signatures and event names.
​

The ERC category sits inside the broader EIP framework at eips.ethereum.org. Every ERC has a unique number (ERC-20, ERC-721, ERC-4337) and a status that moves through Draft, Review, Last Call, and Final. The "Request for Comment" name is borrowed from the IETF's RFC process, the same model that standardized HTTP and TCP/IP, adapted for permissionless onchain contracts.
​

ERCs matter because Ethereum has no central authority that enforces contract interfaces. A wallet does not know how to display a USDC balance unless the contract implements the exact functions the wallet expects. ERC-20 defined those functions: balanceOf, transfer, approve, and transferFrom. Once a standard reaches Final status, any project can build against it with confidence that every compliant contract speaks the same interface.
​

An Ethereum Improvement Proposal starts as a plain-text document submitted to the EIPs GitHub repository. For application-layer ideas, the type is "Standards Track, ERC." The author proposes a problem, specifies an interface, provides a reference implementation, and opens a pull request. After the EIP editors accept the format, the proposal is assigned a number and enters Draft status.
​

From Draft, a proposal moves to Review when the author believes the spec is complete and invites broad feedback. Community discussion happens on the Ethereum Magicians forum, the primary venue where core developers, DeFi teams, and wallet builders debate proposed interfaces. A proposal enters Last Call when the editors judge that outstanding issues have been resolved. Last Call runs for 14 days. If no blocking objections arise during that window, the EIP moves to Final.
​

Two terminal statuses also exist. Stagnant means the proposal has had no activity for 6 months or more; authors can revive it by updating the document. Withdrawn means the author has voluntarily retracted the proposal. Neither terminal status prevents a developer from implementing the spec informally. Market adoption sometimes precedes Final status entirely: ERC-4337 (account abstraction) was deployed at scale by teams including Alchemy, Stackup, and Biconomy while still in Draft.
​

The EIP process is intentionally slow for core protocol changes and more flexible for ERCs. A new consensus-layer EIP requires broad client-team agreement; an ERC can reach Final through community consensus alone. This asymmetry keeps the Ethereum base layer conservative while allowing the application layer to experiment faster.
​

Anyone can submit an EIP. The barrier is quality of specification, not affiliation. Fabian Vogelsteller, who wrote ERC-20, was not a member of the Ethereum Foundation. William Entriken, the lead author of ERC-721, worked independently. The open authorship model has produced the most widely deployed token standards in the industry. The EIPs GitHub repository has accumulated thousands of proposals since 2015, with a small fraction reaching Final status. That ratio illustrates how much experimentation happens before community consensus forms.
​

An EIP (Ethereum Improvement Proposal) is the umbrella category for all proposed changes to Ethereum. An ERC is the specific track within EIPs covering application-layer interfaces. EIPs touching consensus or the EVM affect every node; ERCs only affect contracts and wallets that choose to implement them. ERC-20 is technically EIP-20, but not every EIP is an ERC.
​

The EIP framework divides proposals into three tracks. The Core track covers consensus and EVM changes, including EIP-1559 (the fee-burning mechanism introduced in August 2021) and EIP-4844 (proto-danksharding blobs, activated March 2024). The Networking track covers the p2p layer. The ERC track covers ABI specifications and application conventions shared across contracts and wallets.
​

When a developer says "it's an ERC," they mean an application-layer standard with no protocol dependency. ERC-20 does not require any Ethereum upgrade; it is a convention. EIP-4844, by contrast, required a hard fork coordinated across all mainnet clients (Geth, Nethermind, Besu, Erigon). The governance paths differ: ERCs are approved by the EIP editors and community forum; Core EIPs require signoff from client teams, per the process described at ethereum.org/governance.
​

Some EIPs span core and application layers. EIP-2981 (NFT royalties) is purely an ERC; EIP-3155 (execution tracing) modifies node behavior. When evaluating a new proposal, checking its "type" and "category" fields in the raw EIP text at eips.ethereum.org resolves the ambiguity immediately.
​

Six ERCs define how most Ethereum application value moves. ERC-20 standardized fungible tokens in 2015; ERC-721 created unique token identity in 2018; ERC-1155 handles both token types in one contract; ERC-4337 brought account abstraction to production without a consensus change; ERC-7715 defined granular wallet permissions; ERC-7683 specified a cross-chain intent format now used by multiple solver networks.
​

These standards layer on each other. An ERC-4337 smart account wallet can hold ERC-20 tokens, receive ERC-721 NFTs, and accept ERC-7715 session permissions from a dapp, all within a single user context. The full ERC catalog at eips.ethereum.org lists every standard by number and status. The table below summarizes the key dimensions across the six major ERCs.
​

ERC-20, authored by Fabian Vogelsteller and Vitalik Buterin and formalized in November 2015, defines six mandatory functions and two events. The transfer and transferFrom functions handle movement; approve and allowance handle delegation; totalSupply and balanceOf handle state queries. Any contract that exposes these six functions is ERC-20-compliant and works with every ERC-20-aware wallet and exchange automatically. USDC, USDT, DAI, and the vast majority of DeFi protocol tokens are ERC-20 contracts. How ERC-20 tokens work explains the full interface in detail.
​

ERC-721, authored by William Entriken, Dieter Shirley, Jacob Evans, and Nastassia Sachs and finalized in January 2018, adds a tokenId field to the token model. Each token has a unique ID, an owner address, and an ownerOf lookup. Uniqueness is enforced at the contract level: two calls to ownerOf(42) always return the same address until a transfer event changes it. CryptoPunks were retroactively wrapped to ERC-721 in 2021; Uniswap V3 uses ERC-721 to represent liquidity positions because each position carries unique fee-tier and range parameters.
​

ERC-1155, authored by Witek Radomski and finalized in June 2019, collapses what previously required two separate contracts (one ERC-20, one ERC-721) into a single deployment. A single ERC-1155 contract can define token ID 1 as a fungible game currency (10 million units) and token ID 2 as a unique item (1 unit). Batch transfer functions reduce gas cost significantly when moving multiple token types at once. The ERC-1155 multi-token design became the default standard for onchain gaming item systems and marketplace inventory contracts.
​

ERC-4337, authored by Vitalik Buterin, Yoav Weiss, Dror Tirosh, Shahaf Nacson, Alex Forshtat, Kristof Gazso, and Tjaden Hess, reached production on Ethereum mainnet in March 2023. The key mechanism is a new transaction type called a UserOperation, processed by a separate Bundler mempool rather than the standard Ethereum mempool. Smart contract wallets submit UserOperations; bundlers aggregate them and pay gas; a singleton EntryPoint contract verifies and executes the batch. This removes the requirement for users to hold ETH for gas, since paymasters can sponsor fees in any ERC-20 token. Safe, Alchemy's Account Kit, and ZeroDev each reached hundreds of thousands of deployed smart accounts within 12 months of the launch.
​

ERC-7715 defines a permissions model for smart contract wallets, allowing dapps to request scoped, time-limited, revocable access. A wallet implementing ERC-7715 can grant a DeFi protocol permission to execute trades up to $500 within a 24-hour window without asking for a fresh signature on every transaction. MetaMask's Delegation Toolkit and Coinbase Smart Wallet both reference ERC-7715 as a core primitive. The full ERC-7715 wallet permissions specification details the grant and revocation flow.
​

ERC-7683 defines a cross-chain intent order format. A user signing an ERC-7683 order specifies input tokens (what they are spending), output tokens (what they want on the destination chain), and a fill deadline. Any solver network that reads the format can attempt fulfillment. Across Protocol and UniswapX both implemented ERC-7683-compatible order formats in 2024, creating a shared solver market rather than isolated liquidity pools per bridge. The shared intent standard is directly relevant to cross-chain intent protocols competing on fill speed and price.
​

ERC-20 created the conditions for DeFi by giving every token a common interface. Before it, each token was a custom contract and exchanges wrote bespoke code per integration. After ERC-20, a single Uniswap pool could hold any two compliant tokens. USDC, USDT, and DAI are all ERC-20 contracts, making them interchangeable collateral across Aave, Compound, and Curve.
​

Circle's Cross-Chain Transfer Protocol (CCTP), which enables native USDC burns on one chain and mints on another, treats USDC as an ERC-20 contract on every supported chain. The burn-and-mint mechanic is standardized: a contract calls burnLockedUSDC on the source chain, an attestation service confirms the burn, and a mintUSDC call on the destination chain creates the output. CCTP's cross-chain mechanics depend entirely on USDC remaining ERC-20-compliant; non-standard token contracts cannot use CCTP without a wrapper.
​

ERC-4337 is reshaping how stablecoin payments work in practice. Smart contract wallets built on ERC-4337 can pay gas in USDC rather than ETH, execute recurring transfers without manual signing, and bundle multiple stablecoin moves into a single transaction. Platforms building stablecoin automation depend on ERC-4337's paymaster system to remove the ETH gas requirement for end users.
​

ERC-7683's cross-chain intent standard is building toward a unified liquidity layer across chains. Rather than each bridge operating a proprietary order format, any solver watching the ERC-7683 order book can fill an intent regardless of which bridge they use to settle. Eco Routes selects among available settlement rails (including CCTP and Hyperlane) based on cost and finality, and the ERC-7683 intent format is a natural complement to how Eco's solver network evaluates and fulfills cross-chain stablecoin transfers. Eco supports 15 chains including Ethereum, Base, Optimism, Arbitrum, and Solana, the same chains where most ERC-7683 solver activity is concentrated.
​

The compounding effect is significant. ERC-20 set the token interface; ERC-4337 enables smart wallets that hold those tokens without requiring ETH for gas; ERC-7683 gives those wallets a standardized way to express what they want across chains; and ERC-7715 lets dapps request time-limited permission to act on a user's behalf within those wallets. Each successive standard extended the system rather than replaced it. A protocol built today can support all four simultaneously using publicly available open-source implementations from projects like OpenZeppelin (ERC-20, ERC-721, ERC-1155) and Alchemy (ERC-4337). Standardization at each layer is what makes composability across the entire ecosystem possible.
​

The canonical source for every Ethereum ERC standard is eips.ethereum.org, which renders the EIPs GitHub repository. Each page shows the current status, authors, discussion link, and full specification text. The raw GitHub files at github.com/ethereum/EIPs include motivation, specification, and rationale sections that explain why competing approaches were rejected, context the final spec text rarely repeats.
​

For tracking new proposals and following live debates, ethereum-magicians.org is the primary forum. Threads are indexed by EIP number. The multi-year debate around ERC-4337 versus alternative account-abstraction proposals (EIP-2938, EIP-3074) is archived there and provides context for why the final spec takes the shape it does. Reading the Magicians thread alongside the EIP text is the fastest way to understand a standard's design decisions.
​

Filtering the eips.ethereum.org list by type "Standards Track" and category "ERC" returns the full ERC list. The Last Call filter is useful for tracking standards nearing finalization. As of early 2026, several ERC-7xxx proposals covering account abstraction extensions, token metadata, and cross-chain order types are in various stages of Last Call review.
​

Developers integrating ERCs into production systems should monitor the Ethereum Magicians forum for breaking changes during Last Call periods. The spec can change materially between Draft and Last Call. ERC-4337's EntryPoint contract was redeployed at version 0.7 in April 2024 with breaking interface changes from v0.6, requiring migration for projects built against the earlier version. Tracking proposal status actively prevents that kind of surprise. The trustless architecture that ERCs enable depends on interface stability after a standard reaches Final.
​

ERC stands for Ethereum Request for Comment. It is the application-layer track within the Ethereum Improvement Proposal system. ERCs define shared interfaces for tokens, wallets, and smart contracts without modifying the Ethereum protocol itself. The name comes from the IETF's RFC process, which standardized TCP/IP and HTTP using the same open-comment model.
​

ERC-20 is technically EIP-20. Every ERC shares its number with the broader EIP record, but belongs to the "Standards Track, ERC" category covering application-layer interfaces. Core EIPs (EIP-1559, EIP-4844) modify the Ethereum protocol and require client-team consensus across Geth, Nethermind, Besu, and Erigon. ERC-20 needed none of that; it required only community adoption.
​

ERC-20 defines fungible tokens, where every unit is interchangeable: one USDC is identical to any other. ERC-721 defines non-fungible tokens, where each token has a unique ID and distinct ownership. A Uniswap V3 liquidity position uses ERC-721 because its fee tier and price range make it unique. The ERC-20 token guide covers the full interface breakdown.
​

There is no fixed timeline. ERC-20 moved from draft to Final in roughly 2 years (2015 to 2017). ERC-4337 took over 2 years from initial proposal (2021) to Final (2023). Many proposals stall at Draft indefinitely. A proposal advances only when the authors resolve outstanding technical objections and the community reaches rough consensus on the Ethereum Magicians forum.
​

Yes. ERC Final status is a community signal, not an enforcement mechanism. ERC-4337 smart account infrastructure was deployed on Ethereum mainnet in March 2023 and accumulated millions of user operations before the standard was finalized. Teams building on Draft ERCs accept interface-change risk: if the spec evolves before Final, deployed contracts may fall out of compliance with the finalized version.
​

Sources and methodology. ERC status and author information verified against eips.ethereum.org in April 2026. Deployment dates for ERC-4337 infrastructure (March 2023 mainnet launch) sourced from the ERC-4337 project and Alchemy documentation. Protocol adoption examples cross-referenced with official project documentation. ERC-7683 adoption by Across Protocol and UniswapX verified against project changelogs. Statuses reflect the EIP repository at time of writing and change as proposals advance.
​