An RFC (Request for Comments) is a numbered, peer-reviewed technical document that serves as the primary mechanism for proposing, discussing, and establishing standards for the Internet and other networked systems. Managed historically by the Internet Engineering Task Force (IETF), an RFC can define everything from fundamental protocols like TCP/IP and HTTP to best practices and informational memos. Once published, an RFC is never revised; updates or replacements are issued as new RFCs, creating a permanent, versioned record of the Internet's architectural evolution.
LABS
Glossary
Request for Comment (RFC)
A Request for Comment (RFC) is a formal document or forum post that outlines a proposed change to a protocol's code, parameters, or governance, published to solicit community feedback before an on-chain vote.
Chainscore © 2026
definition
PROTOCOL DEVELOPMENT
What is a Request for Comment (RFC)?
A Request for Comments (RFC) is a formal document that proposes, describes, and standardizes the technical specifications and protocols for computer networks and distributed systems, most famously the Internet.
The lifecycle of an RFC begins as an Internet-Draft (I-D), a working document open for community review and iteration. This draft undergoes rigorous scrutiny within the relevant IETF working group. If it achieves consensus, it is passed to the Internet Engineering Steering Group (IESG) for final approval and publication by the RFC Editor. This process ensures that protocols are robust, interoperable, and developed through open collaboration, embodying the foundational ethos of the Internet.
In the blockchain and cryptocurrency ecosystem, the RFC model has been widely adopted for protocol upgrades and improvements. Prominent examples include Ethereum Improvement Proposals (EIPs), which follow an RFC-like process to introduce changes like EIP-1559 for fee market reform, and Bitcoin Improvement Proposals (BIPs), such as BIP-141 which defined the Segregated Witness (SegWit) upgrade. This formalized process provides a transparent and structured path for evolving decentralized networks, ensuring changes are thoroughly vetted by developers, miners, and the broader community.
etymology
REQUEST FOR COMMENT
Etymology and Origin
The term **Request for Comments (RFC)** is a foundational concept in the development of technical standards and protocols, with a history that predates the modern internet and has been adopted by the blockchain industry.
The Request for Comments (RFC) process originated in 1969 within the ARPANET project, the precursor to the internet. The first document, RFC 1, titled "Host Software," was authored by Steve Crocker. Contrary to its name, the series was not designed as a formal request but as a method for sharing ideas and building consensus among the small, collaborative research community. This informal, document-centric approach to standardization proved remarkably effective and became the de facto engine for internet protocol development, governing standards like TCP/IP and HTTP.
In the context of blockchain and cryptocurrency, the RFC model was adopted to propose and standardize technical improvements. The most prominent example is Ethereum, where an Ethereum Improvement Proposal (EIP) follows the RFC format. An EIP begins as a draft document detailing a new feature, process, or environment, which is then submitted for community review and discussion. This process ensures transparency, rigorous peer review, and broad consensus before any change is implemented on the network, mirroring the open ethos of the original internet RFCs.
The structure of a blockchain RFC is highly formalized. It typically includes sections for a Preamble (with a unique identifier like EIP-20), a Simple Summary, an Abstract, a Motivation section explaining the problem, a Technical Specification, a Rationale, and a section on Backwards Compatibility. This rigorous template ensures proposals are technically sound, clearly justified, and evaluable by developers. The lifecycle moves from Draft to Review, then Last Call, and finally Final status upon acceptance.
The philosophical legacy of the RFC is perhaps its most significant contribution to blockchain. It institutionalizes a meritocratic and open-source governance model. Authority derives from the technical quality of the proposal and the consensus it achieves, not from a central corporate entity. This makes the RFC process a critical tool for decentralized protocol evolution, used by networks like Bitcoin (BIPs), Polkadot, and Cosmos to manage upgrades in a transparent and collaborative manner, directly inheriting the internet's foundational ethos of rough consensus and running code.
key-features
REQUEST FOR COMMENT
Key Features of an RFC
An RFC (Request for Comments) is a formal document proposing a new standard, protocol, or feature for a blockchain network. It is the primary mechanism for decentralized governance and technical specification.
01
Formal Specification
An RFC provides a technical specification that details the proposed change. This includes the motivation, proposed code, implementation details, and potential edge cases. It serves as the single source of truth for developers to build and review the proposal.
02
Community-Driven Process
The core of an RFC is open collaboration. It is published for community review, where developers, researchers, and users can submit feedback, ask questions, and suggest improvements. This process ensures broad scrutiny and consensus-building before implementation.
03
Versioning and Tracking
RFCs are assigned unique identifiers (e.g., EIP-1559, BIP-39) and go through distinct versioning stages (Draft, Review, Final, Withdrawn). This creates a permanent, auditable record of the proposal's evolution and final status within the project's governance framework.
04
Implementation Pathway
A successful RFC outlines a clear path to network adoption. This includes specifying the required consensus mechanism changes (e.g., hard fork, soft fork), integration points for clients (like Geth or Lighthouse), and any necessary backward compatibility measures.
05
Examples: Ethereum & Bitcoin
- EIP-1559: An Ethereum Improvement Proposal that introduced a new transaction fee market and the burning of base fees.
- BIP-341: A Bitcoin Improvement Proposal that defined the Taproot upgrade, improving privacy and scalability through Schnorr signatures and Merkleized Abstract Syntax Trees (MAST).
06
Related Concepts
- Governance Proposal: A broader term often used by DAOs to vote on RFCs or treasury allocations.
- Hard Fork: A backward-incompatible upgrade that may be enacted by an RFC.
- Testnet Deployment: A mandatory phase where an RFC's code is tested on a simulated network before mainnet launch.
how-it-works
STANDARDIZATION
How the RFC Process Works
The Request for Comments (RFC) process is the formal, consensus-driven mechanism for proposing, reviewing, and establishing technical standards and protocols, most famously for the Internet and now widely adopted in software development.
An RFC (Request for Comments) is a formal document that proposes a new standard, protocol, or significant change to an existing system. Originating with the early ARPANET, the process was pioneered by Steve Crocker in 1969 to openly document networking ideas. Contrary to its name, an RFC is not merely a request for feedback; it is the canonical publication vehicle for Internet Standards like TCP/IP (RFC 791, RFC 793) and HTTP (RFC 2616). The process is managed by the Internet Engineering Task Force (IETF), where documents progress through stages: Internet-Draft, Proposed Standard, Draft Standard, and finally Internet Standard.
The lifecycle begins when an author or working group submits an Internet-Draft. This is a temporary, mutable document open for community review and discussion on relevant mailing lists. Key to the process is rough consensus and running code—agreement is determined not by vote, but by the sense of the working group, ideally backed by functional implementations. The IETF Area Directors and the Internet Engineering Steering Group (IESG) provide oversight, ensuring the draft addresses feedback and meets technical quality bars before advancing.
For a draft to become a Proposed Standard RFC, it must demonstrate stability, community review, and at least two independent, interoperable implementations. The final step is publication by the RFC Editor, which assigns a sequential number and archives the document permanently. Once published, RFCs are never altered; errata are published separately, and new RFCs can obsolete previous ones. This immutability ensures a stable reference, while the open process allows protocols to evolve through new proposals.
Beyond the IETF, the RFC model has been adopted in software engineering, particularly in open-source projects and blockchain development. For example, Ethereum Improvement Proposals (EIPs) and Bitcoin Improvement Proposals (BIPs) follow a similar structured workflow for network upgrades. Companies like Microsoft and Google also use internal RFC processes to design large-scale systems. This adaptation underscores the model's effectiveness for coordinating distributed technical work and achieving interoperability through transparent, documented consensus.
examples
IMPLEMENTATION PATTERNS
Examples of Oracle Network RFCs
Request for Comment (RFC) documents standardize how data is requested and delivered on-chain. These examples illustrate key design patterns for oracle data feeds.
COMPARISON
RFC vs. Other Governance Artifacts
How a formal Request for Comment differs from other common governance and planning documents in blockchain ecosystems.
| Feature | Request for Comment (RFC) | Improvement Proposal (EIP/BIP) | Forum Post / Social Media | On-Chain Proposal |
|---|---|---|---|---|
Primary Purpose | To solicit structured feedback and build consensus on a proposed standard or major change. | To formally document a finalized standard or protocol improvement. | To gauge initial sentiment, spark discussion, or announce developments. | To execute a specific, executable change via a governance vote. |
Formality & Structure | ||||
Requires Pre-Voting Consensus | ||||
Immutable Record | ||||
Directly Executable Action | ||||
Typical Lifecycle Stage | Pre-standardization, design phase | Post-consensus, specification phase | Ideation, announcement, or informal discussion | Final approval and execution phase |
Author Reputation Impact | High (shapes major proposals) | High (defines standards) | Variable | High (submits executable code) |
Common Venue | Governance repository (GitHub) | Standards repository (GitHub) | Discourse, Twitter, Discord | Governance dashboard (e.g., Snapshot, Tally) |
ecosystem-usage
REQUEST FOR COMMENT (RFC)
Ecosystem Usage
A Request for Comment (RFC) is a formal process for proposing, discussing, and standardizing technical specifications and protocols, originating from the IETF and widely adopted in blockchain development.
01
Core Purpose & Process
An RFC is a numbered document that details a proposed technical standard or protocol change. The process involves:
- Draft Submission: A working group or individual authors publish an Internet-Draft.
- Community Review: The draft undergoes extensive peer review and public commentary.
- Standardization: After revisions and consensus, it may be ratified as a formal standard (e.g., an IETF RFC). In blockchain, this model ensures rigorous, transparent vetting of upgrades like new transaction formats or consensus changes.
04
Cross-Chain & API Standards
RFC processes are critical for interoperability and infrastructure standards beyond core protocols. Key examples include:
- Token Standards: ERC-20, ERC-1155 (Ethereum), SPL (Solana).
- Cross-Chain Protocols: Specifications for bridges and messaging layers.
- JSON-RPC APIs: Standardized client communication methods used by wallets and dApps. These standards enable developer tooling and composability across the ecosystem.
05
Governance & Consensus Building
The RFC process is a foundational governance mechanism for decentralized networks. It facilitates:
- Transparent Decision-Making: All proposals and discussions are publicly archived.
- Stakeholder Alignment: Engineers, node operators, and users can review impacts.
- Conflict Resolution: Formal process to debate technical merits and reach rough consensus. This replaces top-down decision-making with a collaborative, engineering-driven approach.
06
Related Concepts
Understanding RFCs involves familiarity with adjacent processes and artifacts:
- Internet-Draft (I-D): The preliminary, mutable version of an RFC.
- Standards Track: The classification for proposals intended to become official standards.
- Working Group: A dedicated team that shepherds related proposals.
- Last Call: A final review period before a decision is made.
- Fork: The execution mechanism (soft/hard fork) for implementing a ratified change on a live network.
REQUEST FOR COMMENT (RFC)
Technical Details
A Request for Comment (RFC) is a formal document that proposes, describes, and standardizes technical specifications and protocols for the internet and, by extension, blockchain networks. This section details its role in decentralized governance and protocol evolution.
In blockchain, a Request for Comment (RFC) is a formal proposal document that details a new feature, standard, or improvement for a protocol, serving as the primary mechanism for decentralized technical governance and consensus-building. Modeled after the internet's IETF process, it allows developers and community members to submit, review, and debate changes before implementation. For example, Ethereum Improvement Proposals (EIPs) and Bitcoin Improvement Proposals (BIPs) are specific types of RFCs. The process typically involves drafting a specification, initiating community discussion, undergoing peer review, and finally, upon reaching rough consensus, moving toward activation via a network upgrade or hard fork.
REQUEST FOR COMMENT (RFC)
Common Misconceptions
Clarifying widespread misunderstandings about the Request for Comment (RFC) process in blockchain development, separating the formal protocol from informal community discussions.
No, an RFC is a proposal for a standard, not the standard itself. It is a formal document submitted to initiate community review and debate. The core purpose is to solicit feedback, identify flaws, and build consensus before any code is written or a change is implemented. Final approval typically requires a separate governance process, such as an on-chain vote for a Decentralized Autonomous Organization (DAO) or a core developer team's decision after extensive peer review. Treating an RFC as a final specification is a critical error in protocol development.
REQUEST FOR COMMENT (RFC)
Frequently Asked Questions (FAQ)
A Request for Comment (RFC) is a formal document that proposes, describes, or standardizes a new protocol, process, or feature for a blockchain ecosystem. These FAQs cover its purpose, process, and impact.
A Request for Comment (RFC) is a formal design document that proposes a new standard, protocol, or major change to a blockchain network's core software or ecosystem. It is the primary mechanism for open, collaborative development and governance in projects like Ethereum (Ethereum Improvement Proposals, or EIPs) and Bitcoin (Bitcoin Improvement Proposals, or BIPs). An RFC details the technical specification, rationale, and potential impact of the change, inviting community review and feedback before implementation. This process ensures transparency, security, and broad consensus, preventing unilateral changes by core developers.
further-reading
RFC RESOURCES
Further Reading
Explore the foundational documents and processes that define the Request for Comment (RFC) system, from its internet origins to its critical role in blockchain governance.
06
From Proposal to Network Upgrade
The final stage of an RFC is its activation on the live network. This involves complex coordination:
- Client Implementation: Protocol clients (e.g., Geth, Lighthouse, Bitcoin Core) must implement the change.
- Activation Mechanism: Often uses a block height or timestamp for synchronized activation.
- Hard Forks & Soft Forks: Consensus changes typically require a hard fork (backward-incompatible). Soft forks (backward-compatible) are more common in Bitcoin.
- Governance Voting: Some chains use on-chain voting (e.g., Compound, Uniswap) to signal support before code deployment.
> 99%
Typical Miner/Validator Threshold for Activation
ENQUIRY
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.
NDA Protected
Confidentiality24h Response
Time to ValueDirectly to Engineering Team
No Sales Fluff10+
Protocols Shipped
$20M+
TVL Overall