Ethereum Request for Comments (ERC)

An Ethereum Request for Comments (ERC) is a formal proposal document that defines a standard set of rules and interfaces for smart contracts on the Ethereum network. Similar to internet RFCs, ERCs are submitted by developers to the Ethereum community for discussion, refinement, and eventual adoption. Once finalized and widely accepted by the community, an ERC becomes an Ethereum Improvement Proposal (EIP) and is integrated into the official Ethereum standards repository. This process ensures interoperability, security, and consistency across the decentralized ecosystem.

The most pivotal ERC standard is ERC-20, which established the blueprint for fungible tokens—digital assets where each unit is identical and interchangeable. This standard specifies mandatory functions like transfer() and approve(), enabling seamless interaction between wallets, exchanges, and decentralized applications (dApps). Other foundational standards include ERC-721 for unique, non-fungible tokens (NFTs) and ERC-1155 for managing both fungible and non-fungible assets within a single contract. These standards form the backbone of the token economy on Ethereum and other EVM-compatible chains.

The lifecycle of an ERC begins with an author drafting a proposal, which is then discussed on forums like the Ethereum Magicians. Key stages include Draft, Review, Last Call, and Final. Community consensus is critical; a proposal must demonstrate clear utility, security, and backward compatibility. Notable examples beyond tokens include ERC-4337 for account abstraction (smart contract wallets) and ERC-4626 for tokenized vaults. This rigorous, open process is fundamental to Ethereum's decentralized governance and its ability to evolve through collective innovation.

The Ethereum Request for Comments (ERC) is a formal proposal process for introducing new standards to the Ethereum ecosystem, directly modeled after the Internet Engineering Task Force's (IETF) Request for Comments (RFC) system. The RFC framework, established in 1969, is the primary mechanism for developing and publishing the technical specifications that define the internet's core protocols, such as TCP/IP and HTTP. By adopting this naming convention and procedural philosophy, Ethereum's founders signaled their commitment to a transparent, collaborative, and community-driven approach to protocol evolution, treating smart contract interfaces and token formats with the same rigor as foundational internet standards.

The 'Ethereum' prefix distinguishes these proposals as specific to the Ethereum blockchain and its virtual machine. The term 'Request for Comments' is intentionally humble and open-ended; it denotes that the document is a draft proposal submitted to the community for review, critique, and consensus-building, not an edict from a central authority. This process ensures that standards like the ubiquitous ERC-20 (for fungible tokens) and ERC-721 (for non-fungible tokens) undergo extensive technical scrutiny and debate before being finalized and assigned a permanent number, mirroring how internet standards like RFC 791 (IP) were developed.

The lineage from RFC to ERC is more than nominal. It embeds a specific cultural and technical methodology: proposals are text documents, they have authors, they are assigned sequential numbers, and their status evolves through stages (Draft, Review, Final). This structure provides a clear historical record and a predictable pathway for innovation. While the Ethereum Improvement Proposal (EIP) process governs changes to the core Ethereum protocol itself, the ERC sub-category specifically standardizes application-layer conventions, creating the interoperable building blocks upon which the decentralized application (dApp) economy is constructed.

An ERC begins as an Ethereum Improvement Proposal (EIP) focused on application-level standards. The process follows a structured lifecycle: Draft, Review, Last Call, Final, and Stagnant. A proposer, or author, drafts the specification using a standard template, detailing the motivation, technical specification, rationale, and backward compatibility. This draft is submitted to the EIPs repository on GitHub, where it is assigned a number and enters the public review phase.

During the Review phase, the proposal is scrutinized by the broader Ethereum community, including core developers, client teams, and application builders. Key discussions happen on the Ethereum Magicians forum and GitHub pull requests. For an ERC to advance, it must demonstrate clear utility, technical soundness, and broad community consensus. Editors, who are trusted community members, shepherd proposals, ensuring they meet formatting and technical requirements. A critical milestone is the request for peer review from relevant experts, such as wallet or smart contract security auditors.

If consensus is reached, the proposal enters Last Call for a final review period, typically lasting 14 days. After addressing any remaining objections, ERC editors may move the proposal to Final status. A Final ERC is a fully accepted standard, such as ERC-20 for fungible tokens or ERC-721 for non-fungible tokens (NFTs). These standards are then implemented by developers across wallets, exchanges, and decentralized applications (dApps), creating the interoperable foundation of Ethereum's application layer. Proposals that are abandoned or inactive are marked Stagnant.

The ERC process is deliberately decentralized and community-driven, distinct from the core Ethereum protocol upgrade process managed by core developers. This separation allows application-layer innovation to progress independently of consensus-layer changes. Successful ERCs solve specific, widespread problems—like token interfaces, metadata formats, or wallet interaction patterns—and their adoption is purely voluntary, enforced by network effects and the utility they provide to developers and users.

An Ethereum Request for Comments (ERC) is a formal proposal document that describes a new standard for the Ethereum blockchain, such as a token format, a library, or a protocol improvement. Modeled after the internet's RFC (Request for Comments) process, it serves as the primary mechanism for community-driven innovation and consensus. Once an ERC is drafted, it undergoes public review, discussion, and refinement on platforms like the Ethereum Magicians forum and GitHub before potentially being finalized as an Ethereum Improvement Proposal (EIP) and adopted as a standard.

The most famous ERC standards govern token interfaces. ERC-20 defines a fungible token standard, enabling the creation of interchangeable assets like utility tokens. ERC-721 established the non-fungible token (NFT) standard for unique digital items. ERC-1155 introduced a multi-token standard that can manage fungible, non-fungible, and semi-fungible tokens within a single smart contract. These standards ensure interoperability, meaning tokens following the same rules can be seamlessly integrated into wallets, decentralized exchanges (DEXs), and other applications.

Beyond tokens, ERCs specify a wide range of functionalities. ERC-165 creates a standard interface for detecting what interfaces a smart contract supports. ERC-2981 defines a royalty standard for NFTs. ERC-4337 introduced account abstraction, allowing for smart contract wallets. The process begins when a developer authors an ERC draft, assigns it a number, and submits it for peer review. This open process allows for rigorous technical scrutiny and ensures that widely adopted standards are robust, secure, and well-understood by the developer community.

The lifecycle of an ERC is managed through the Ethereum Improvement Proposal (EIP) repository, with EIP-1 serving as the governing meta-process. An ERC is a specific category of EIP focused on application-level standards. The path from draft to final status involves stages like Draft, Review, Last Call, and finally Final. This governance model is critical for Ethereum's evolution without centralized control, allowing the network to adapt through transparent, collaborative technical proposals that shape its infrastructure and capabilities.