Request for Comments (RFC)

An RFC is the final, published stage in a formal standardization process managed by bodies like the Internet Engineering Task Force (IETF). It evolves from an Internet-Draft through community review, discussion, and consensus before being assigned a permanent RFC number. This process ensures rigorous technical vetting and stability for foundational protocols like TCP/IP and HTTP.

Once published, an RFC is a static, immutable document identified by a unique RFC number (e.g., RFC 791 for IPv4). It is never revised; updates or corrections require a new RFC that obsoletes or updates the previous one. This creates a permanent, citable historical record of protocol evolution, where the RFC Series serves as the canonical archive.

RFCs are not created by a single authority but through rough consensus and running code. The process emphasizes:

• Open participation from the technical community.
• Working group discussions and reviews.
• Resolution of objections and technical debates.
• The principle that operational experience and working implementations are the ultimate test. This open model is foundational to internet governance.

RFCs have standardized maturity levels that indicate their authority and purpose:

• Proposed Standard: Initial specification, stable but may change.
• Draft Standard: Well-reviewed, with multiple independent implementations.
• Internet Standard: The highest level, a fully ratified protocol (e.g., RFC 2616 for HTTP/1.1).
• Informational/Experimental: Provides context or documents research, not a standard.

RFCs follow a strict, text-based format defined by RFC 7322. Key elements include:

• A clear abstract and status section.
• Detailed technical specifications using precise language.
• Augmented Backus–Naur Form (ABNF) for formal syntax definitions.
• Security and implementation considerations sections.
• References to other RFCs. This uniformity ensures clarity and prevents ambiguity for implementers.

A Request for Comments (RFC) is a formal, structured proposal document used in decentralized governance to introduce changes to a blockchain protocol or ecosystem standard. It outlines the technical specifications, rationale, and potential impact of a proposed change, serving as the starting point for community review and consensus-building before any code is written or deployed.

The RFC process follows a structured lifecycle to ensure thorough vetting:

• Drafting & Submission: A proposer writes the RFC and submits it to the community forum or governance repository.
• Community Discussion: Stakeholders, developers, and users debate the proposal's merits, risks, and technical details.
• Formal Review & Revision: Based on feedback, the RFC is iteratively refined. A reference implementation may be developed.
• Governance Vote: Token holders or delegated validators cast on-chain votes to accept or reject the finalized proposal.
• Implementation & Deployment: If approved, core developers or the proposer's team implements the change in a scheduled network upgrade.

The RFC process is a critical line of defense against malicious or faulty upgrades. It enables peer review by security researchers and core developers to identify vulnerabilities like reentrancy bugs, economic attacks, or consensus failures before they reach the mainnet. A transparent, slow-moving RFC process helps prevent governance attacks where a malicious proposal is rushed to a vote, and ensures backward compatibility and system stability are rigorously considered.

Major blockchain ecosystems use RFC-style processes for core upgrades:

• Ethereum Improvement Proposals (EIPs): The standard for proposing changes to the Ethereum protocol (e.g., EIP-1559 for fee market reform).
• Bitcoin Improvement Proposals (BIPs): Used for changes to the Bitcoin protocol (e.g., BIP-141 for SegWit).
• Cosmos Governance Proposals: On-chain proposals for parameter changes, software upgrades, and community pool spending.
• Uniswap Governance Proposals: Off-chain temperature checks and on-chain votes for changes to the Uniswap Protocol.

Different participants have distinct roles in the RFC process:

• Proposers: Developers or community members who draft and champion the RFC.
• Core Developers: Review technical feasibility, security, and integration with the existing codebase.
• Validators/Node Operators: Assess the operational impact and costs of running the new software.
• Token Holders/Voters: Exercise governance rights by signaling support or opposition, often through delegated voting.
• Security Auditors: Provide independent analysis of the proposal's code and economic mechanics.

While essential, the RFC process faces several challenges:

• Voter Apathy: Low participation rates can lead to governance by a small, potentially unrepresentative group.
• Technical Complexity: Highly technical proposals can be difficult for non-developer stakeholders to evaluate meaningfully.
• Process Speed: The deliberate pace can be slow for addressing urgent security vulnerabilities, sometimes requiring emergency procedures.
• Proposal Spam: Managing a high volume of low-quality proposals can drain community attention and resources.

A classification for RFCs that propose changes affecting interoperability or core protocol rules. These are the most consequential proposals, requiring rigorous technical review and broad consensus. They are subdivided into:

• Core: Changes to the consensus layer (e.g., a new opcode, block size change).
• Networking: Updates to peer-to-peer communication protocols.
• Interface: Improvements to APIs, RPC methods, or contract standards (like ERC-20).
• Meta: Changes to the governance process itself.

The deployment event where accepted, consensus-changing RFCs are activated on a live blockchain network. This requires:

• Coordinated Activation: A specific block height or timestamp.
• Node Compliance: All validating nodes must upgrade their client software.
• Backward Incompatibility: Creates a permanent divergence from the old chain. Examples include Ethereum's London upgrade (EIP-1559) and Bitcoin's Taproot upgrade (BIPs 340, 341, 342). A failed upgrade can lead to a chain split.

An informal precursor to a formal RFC, often used in decentralized communities to gauge initial interest and gather feedback before extensive technical drafting. Key characteristics:

• Exploratory Phase: Focuses on problem definition and high-level solutions.
• Lower Barrier: Allows for broader, less technical community input.
• Forum-Based: Typically occurs on platforms like GitHub Discussions, forums, or Discord. If an RFD gains sufficient traction and clarity, it may evolve into a formal RFC with a specific number (e.g., EIP-XXXX).

A working software implementation that accompanies an RFC to prove its technical feasibility and specify its behavior. This is a critical component for standards-track proposals. Its roles include:

• Specification Clarification: Acts as the "source of truth" for ambiguous parts of the text.
• Interoperability Testing: Provides a baseline for other client developers.
• Security Audit Surface: Allows for practical review of potential vulnerabilities. For major upgrades, multiple independent client teams (e.g., Geth, Besu, Erigon for Ethereum) will produce their own implementations based on the RFC.