Status: Last Call · Date: 2026-07-17 · Editors: Untilum project — hello@untilum.com
Part of the TSP RFC series; see the series index for the Last Call window and how to comment. The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in BCP 14 [RFC 2119] [RFC 8174] when, and only when, they appear in all capitals.
This document fixes the governance of the Untilum Protocol: stewardship by the Open Untilum Foundation, the Editor/Maintainer/Contributor roles, the RFC change process (Draft → Last Call → Accepted → Final), the entrenched security invariants that ordinary process cannot amend, and licensing and succession rules chosen so that the protocol lawfully outlives its stewards.
A capsule sealed today must be openable in 2076 by people who have never heard of anyone currently involved. That requires answers — written down now, while the project is small — to: who owns the protocol, who may change the specification, who accepts contributions, and who declares a version final. An unanswered governance question is a single point of failure exactly like an unpinned key.
Stewardship of the protocol is vested in the Open Untilum Foundation (OUF) — today an aspiration-named working group of one, deliberately structured so that growing it changes membership, not rules. The OUF:
@untilum package scope;The OUF explicitly does not own capsules, gate implementations, or hold any key material — per the layering rule, the Foundation itself must be losable (RFC index; G2).
| Role | Authority | Currently |
|---|---|---|
| Editors | Change normative documents (spec, RFCs); ratify version releases | The founding maintainer |
| Maintainers | Accept PRs to the reference implementation (SDK, apps) | The founding maintainer |
| Contributors | Propose RFCs and PRs | Anyone |
One person may hold several roles; the roles exist so the authorities stay distinct as people are added. Editor and Maintainer appointments (and removals) are decided by the existing Editors.
Draft → Last Call (≥ 14 days, publicly announced) → Accepted → Final. An RFC may be Withdrawn at any pre-Final stage. Editors ratify each transition.The following may not be changed by ordinary process — amending this list or its members requires unanimous Editor consent, a Last Call of ≥ 90 days, and a new protocol major version:
A fork that abandons these MUST NOT call itself Untilum — the name is the compatibility promise.
Protocol documents: CC-BY-4.0. Reference implementation: MIT (confirmed by the Editors, 2026-07-17). Both are chosen so that if the OUF dissolves, anyone can lawfully continue the protocol from public artifacts — succession by forkability. Should the OUF be inactive for 24 consecutive months (no Editor action on a pending Last Call), any party may declare continuity stewardship by public fork, and implementations SHOULD follow whichever continuation preserves §5.
At a 50–100-year horizon, governance failure is a security failure: an undefined authority over the specification is a single point of failure exactly like an unpinned key (§1). The entrenched clause (§5) is this document’s core security mechanism — it places the protocol’s five load-bearing invariants beyond ordinary amendment, and the naming rule makes abandonment of them publicly detectable. The succession clause (§6) bounds the risk of steward abandonment: continuity is defined by preservation of §5, not by possession of trademarks or infrastructure.
Untilum project — Editors of the TSP RFC series Email: hello@untilum.com · Issues: https://github.com/untilum/protocol/issues
| Date | Status | Change |
|---|---|---|
| 2026-07-07 | Draft | Initial version. |
| 2026-07-17 | Last Call | Publication pass: BCP 14 boilerplate, Abstract, Security Considerations, References, Revision History added. §6: reference-implementation license MIT confirmed (was “proposed”). Entered Last Call per RFC-0008 §4. |