​
Request for Comments (RFC) Process

​
Overview

The Request for Comments (RFC) process was used by the Cosmos SDK team as an asynchronous collaboration mechanism to facilitate distributed decision-making. While this formal RFC process is no longer actively used, understanding it provides context for how major SDK features were discussed and designed. RFCs served as “async whiteboarding sessions,” enabling the globally distributed Cosmos SDK team and contributors to collaborate on design decisions without requiring synchronous meetings. This was particularly important given the team’s distribution across multiple time zones.

​
What Were RFCs?

RFCs were documents designed to:
  • Facilitate Discussion: Replace the need for synchronous meetings with structured asynchronous discussion
  • Circulate Information: Share potential changes or features with the wider community
  • Build Consensus: Allow stakeholders to reach agreement before implementation
  • Document Discussions: Capture design discussions for future reference
The key distinction between RFCs and ADRs was:
  • RFCs: Used to discuss and reach consensus on proposed features or changes
  • ADRs: Used to document decisions after consensus had already been reached

​
The RFC Lifecycle

The RFC process followed these steps:
  1. Creation: Copy the RFC template with filename pattern rfc-next_number-title.md
  2. Draft PR: Create a draft pull request for early feedback
  3. Documentation: Clearly document context and proposed solution
  4. Discussion: Community and team members provide feedback
  5. Iteration: Author refines proposal based on feedback
  6. Consensus: Stakeholders reach agreement on the approach
  7. Transition: Once consensus is reached, create an ADR to document the decision

​
Historical RFC Examples

Several important SDK features were discussed through the RFC process:
  • Transaction Validation: Established patterns for transaction validation
  • Module Communication: Defined inter-module communication standards
  • API Design: Shaped the SDK’s API architecture
The RFC discussions often led to significant architectural improvements and helped ensure that changes were well-considered before implementation.

​
Why the Process Changed

The formal RFC/ADR process was retired in favor of more agile approaches because:
  1. Velocity: The formal process added overhead that slowed development
  2. Flexibility: Direct implementation with iteration proved more efficient
  3. Tooling: GitHub’s improved discussion and review features reduced the need for separate RFC documents
  4. Community Evolution: The mature community could engage effectively through lighter-weight processes

​
Current Collaboration Methods

The Cosmos SDK team now uses:
  • GitHub Discussions: For community proposals and discussions
  • Pull Request Reviews: For implementation feedback
  • Working Groups: For focused synchronous collaboration
  • Discord/Forum: For informal technical discussions
  • Direct Implementation: With iterative refinement based on feedback

​
Legacy Value

While no longer active, the historical RFCs demonstrated important principles:
  • Transparency: All major decisions were discussed openly
  • Inclusivity: Global contributors could participate asynchronously
  • Documentation: Discussions were preserved for future reference
  • Thoughtfulness: Changes underwent thorough consideration
These principles continue to guide SDK development, even though the formal RFC process has been retired.

​
Resources

For those interested in SDK development history: