This directory contains Requests for Comments (RFCs) for the Stoolap Chain blockchain SQL database project.
An RFC is a design specification that defines:
- WHAT is being built
- Technical specifications and constraints
- Interfaces and expected behavior
- Implementation path
RFCs answer "What must exist before implementation?"
Create RFC from use case motivation:
cp rfcs/0000-template.md rfcs/0000-my-title.mdOpen pull request for discussion
Community discusses (7-day minimum)
Maintainers accept/reject based on consensus
- Accepted → Renumber, create missions
- Rejected → Move to
archived/with reasoning - Needs Work → Continue discussion
Draft → Discussion → Accepted → Implemented → Superseded
↓
Rejected → Archived
| Number | Title | Status | Date |
|---|---|---|---|
| RFC-0101 | Hexary Merkle Proofs | Accepted | Feb 2025 |
| RFC-0102 | Deterministic Value Types | Accepted | Feb 2025 |
| RFC-0103 | Blockchain Consensus | Accepted | Feb 2025 |
Draft RFCs are being discussed and are not yet accepted.
| Number | Title | Status | Date |
|---|---|---|---|
| RFC-0201 | STWO and Cairo Integration | Draft | Mar 2025 |
| RFC-0202 | Compressed Proof Format | Draft | Mar 2025 |
| RFC-0203 | Confidential Query Operations | Draft | Mar 2025 |
| RFC-0204 | L2 Rollup Protocol | Draft | Mar 2025 |
Rejected, superseded, or withdrawn RFCs are stored in archived/.
- Draft RFCs: Use 0000, 0001, 0002, etc.
- Accepted RFCs: Renumbered into ranges (0100-0199 for Phase 1, 0200-0299 for Phase 2, etc.)
See 0000-template.md for the RFC template.
- Use Cases - WHY we build things
- Missions - HOW we build them
- BLUEPRINT.md - Governance process