Request for Comments — Protocol Design Layer

RFCs define WHAT must exist before implementation begins.

Inspired by:

• Rust RFCs
• Ethereum EIPs
• Internet RFC Process

An RFC is a design specification, not implementation.

RFC answers:

• What are we building?
• What are the constraints?
• What are the interfaces?
• What is the expected behavior?

RFC does NOT answer:

• How do we implement it? (→ Missions)
• Who will implement it? (→ Agents/Humans)
• When will it be done? (→ Roadmap)

Draft → Review → Accepted → Final
       → Rejected → Archived
       → Superseded → Archived
       → Deprecated → Archived

For the complete template with all required sections, see RFC-0000-template.md.

Key sections include:

• Dependencies
• Design Goals
• Determinism Requirements
• Security Considerations
• Adversarial Review
• Economic Analysis
• Compatibility
• Test Vectors
• Version History

# RFC-XXXX (Category): [Title]

## Status

Draft | Review | Accepted | Final | Rejected | Superseded | Deprecated

## Summary

One-paragraph overview of the proposal.

## Motivation

Why is this RFC needed? What problem does it solve?

### Use Case Link

Link to the motivating use case in `docs/use-cases/`.

## Specification

Detailed technical specification:

- Data structures
- APIs/interfaces
- Protocols
- Constraints
- Error handling

## Rationale

Why this approach over alternatives?
What trade-offs were made?

## Implementation

Path from RFC to Missions:

- Mission 1: [description]
- Mission 2: [description]
- Mission 3: [description]

## Impact

What does this change?

- Breaking changes?
- Migration path?
- Dependencies?

## Related RFCs

- RFC-XXXX
- RFC-YYYY

## References

Links to external specs, prior art, discussions.

Create rfcs/0000-your-title.md using the template.

# Start with template
cp rfcs/0000-template.md rfcs/0000-my-proposal.md

Create PR: rfcs: RFC-XXXX: [Title]

Include in description:

• Link to use case (if applicable)
• Summary of change
• Request for reviewers

• Minimum 7 days for substantial RFCs
• 3 days for minor clarifications
• All feedback must be addressed

Acceptance Criteria:

• At least 2 maintainer approvals
• No blocking objections
• Technical soundness verified

Possible Outcomes:

Once accepted:

1. RFC is numbered (e.g., 0001)
2. Missions created in missions/open/
3. Agents/humans claim missions
4. PRs reference RFC

0000-0099: Process/Meta (governance, mission, architecture)
0100-0199: Numeric (DFP, DQA, DNT, crypto, linear algebra)
0200-0299: Storage (vector-SQL, persistence)
0300-0399: Retrieval (RAG, vector search, query routing)
0400-0499: Agents (runtime, memory, reasoning, orgs)
0500-0599: AI Execution (VM, transformers, MoE, training)
0600-0699: Proof Systems (verification, consensus, aggregation)
0700-0799: Consensus (sharding, DAG, DA)
0800-0899: Networking (P2P, hardware registry)
0900-0999: Economics (markets, tokenomics)

RFCs are organized by status and category per the BLUEPRINT:

rfcs/
├── draft/
│   ├── process/       (0000-0099)
│   ├── numeric/       (0100-0199)
│   ├── storage/      (0200-0299)
│   ├── retrieval/    (0300-0399)
│   ├── agents/       (0400-0499)
│   ├── ai-execution/ (0500-0599)
│   ├── proof-systems/(0600-0699)
│   ├── consensus/    (0700-0799)
│   ├── networking/   (0800-0899)
│   └── economics/    (0900-0999)
├── planned/
│   ├── process/
│   ├── numeric/
│   ├── proof-systems/
│   └── economics/
├── accepted/
├── final/
└── archived/

See docs/BLUEPRINT.md for the full specification.

Determinism Standard (RFC-0003 Process/Meta) ← Foundation
        ↓
Numeric Foundation (RFC-0104/0105 DFP/DQA)
        ↓
BIGINT & DECIMAL (RFC-0110/0111)
        ↓
Vectors & Matrices (RFC-0112/0113)
        ↓
Activation Functions (RFC-0114)
        ↓
Linear Algebra (RFC-0109 Numeric)
        ↓
Vector Index (RFC-0303 Retrieval) → Vector Storage (RFC-0200 Storage)
        ↓
Vector Query (RFC-0304 Retrieval)
        ↓
RAG Execution (RFC-0550 AI Execution)
        ↓
Agent Runtime (RFC-0450 Agents)
        ↓
Mission Marketplace (RFC-0950 Economics)
        ↓
Proof Verification (RFC-0651 Proof Systems)
        ↓
Model Execution (RFC-0555 AI Execution)
        ↓
Model Liquidity (RFC-0956 Economics)

Before writing an RFC:

1. Check docs/use-cases/ for motivation
2. Search existing RFCs for similar work
3. Discuss in issue/forums first (optional but recommended)

When to write an RFC:

• ✓ New protocol feature
• ✓ Breaking change
• ✓ New agent capability
• ✓ Architecture change
• ✓ Standard/specification

When NOT to write an RFC:

• ✗ Bug fixes (just fix them)
• ✗ Documentation improvements
• ✗ Internal refactoring
• ✗ Test additions

For Reviewers:

• Focus on technical merit
• Consider long-term implications
• Suggest alternatives if concerns
• Explain reasoning for objections

For Authors:

• Address all feedback
• Update spec based on discussion
• Withdraw if consensus impossible
• Be willing to compromise

A: Only for bug fixes, docs, tests. New features require RFC.

A: Plan for 2-4 weeks including discussion and revisions.

A: Minor clarifications: yes. Major changes: new RFC.

A: It's archived with reasoning. You can revise and resubmit.

A: Agents can provide input, but humans accept/reject.

See BLUEPRINT.md for how RFCs fit into the overall governance flow.