Skip to main content
Alethea Protocol

Process

How the protocol evolves.

The specification is published under CC-BY 4.0 and changes through a public RFC process. No single actor decides what goes in.

01

Open an RFC

Anyone may propose a change. RFCs are opened as GitHub issues on the spec repository, then promoted to a markdown file under rfcs/ once they pass initial triage. File naming follows RFC-NNNN-short-title.md, where NNNN is assigned at triage. Every RFC uses the same template.

  • Summary — one-paragraph description of the proposed change
  • Motivation — what problem it solves, who needs it
  • Detailed design — normative text, data model changes, examples
  • Backwards compatibility — what breaks, what migrates
  • Security considerations — threat model, new attack surfaces
  • Alternatives considered — what else was tried, why rejected

02

Comment period

Once an RFC is filed, it enters a minimum 4-week public comment period. The period is open to anyone: developers, journalists, citizens, identity providers, blockchain operators, civil society. All comments are archived on GitHub and remain readable as part of the historical record, whether the RFC is accepted or not.

03

Technical review

Core contributors read each RFC end-to-end, ask for clarifications, and propose amendments. Decisions are made on technical grounds, not by majority vote.

  • Alignment with the protocol vision — verified identity, content, tamper-proof registry
  • Backwards compatibility — does it break existing signatures or verifiers
  • Security — does it introduce new attack surfaces or weaken existing guarantees
  • Simplicity — can the same problem be solved with less mechanism

04

Decision and merge

Each RFC ends in one of three outcomes, with written rationale published in the same thread.

  • Accepted — merged into the spec, included in version v0.x+1
  • Rejected — with explicit rationale, archived for future reference
  • Deferred — kept open for revisit when context changes (new chain, new standard, new use case)

05

Implementation

Once an RFC is merged, it becomes part of the canonical specification. Reference implementations (signcheck and others) are updated to match. Verifiers MAY adopt the change immediately or wait for the next minor version. The spec changelog records every RFC merged into each version.

See current spec Read governance