Governance

Project structure, the RFC lifecycle, and how decisions are made.

Overview

KuberCoin is governed by its contributors. There is no foundation, no board of directors, and no privileged maintainer with veto power over protocol changes. Decisions are made in the open through a documented Request-for-Comments (RFC) process and a small number of standing working groups whose membership rotates annually.

Project structure

Day-to-day development is organised into working groups, each responsible for one slice of the project:

• Consensus. Block validation, transaction validation, difficulty retargeting, monetary policy.
• Networking. Peer-to-peer protocol, peer discovery, mempool synchronisation.
• Tooling. Wallet, RPC server, explorer, SDKs, observability.
• Documentation. The portal you are reading, the whitepaper and the SDK guide.
• Security. Vulnerability triage, CVE coordination, the acknowledgments roster.
• Conduct. Enforcement of the community code of conduct.

A working group has between three and seven active members. Membership is recorded in /governance/working-groups.toml in the source mirror. Members serve one-year terms and may renew once consecutively before stepping down for at least one term.

RFC lifecycle

Every substantive change — protocol rules, wire formats, public APIs, default parameters, security-relevant defaults — goes through an RFC. The lifecycle has four stages with fixed minimum durations:

1. Draft — the author posts an RFC document in the RFCs category of the forum. The draft must include motivation, design, alternatives considered, security implications and a migration plan. There is no minimum duration in this stage; the author iterates until the document is ready for review.
2. Review — the relevant working group seconds the draft and opens a public review window of at least two weeks. Any participant may comment. The author is expected to engage in good faith and to revise the document in response to substantive feedback.
3. Last call — once review feedback has been addressed, the working group declares last call. A one-week window opens during which only objections that introduce new information are considered. Editorial polish continues in parallel.
4. Accepted — if no last-call objection blocks the proposal, the working group marks the RFC accepted. The document is archived under /rfcs/ in the source mirror with a permanent number, and implementation work begins. Accepted RFCs cannot be silently revised; material changes require a new RFC that supersedes the previous one.

Withdrawn and rejected RFCs are also archived — the historical record is preserved so that a future contributor can see why a particular design path was not taken.

Decision-making

RFC acceptance is decided by the working group seconding the proposal. Decisions are made by rough consensus: an outcome is acceptable when no member of the working group sustains a substantive objection after good-faith discussion. Numeric voting is reserved for procedural matters (electing a working-group chair, ratifying membership changes) and uses simple majority of seated members.

Conflict resolution

When two working groups disagree, or when a contributor believes a working group has acted outside its remit, the dispute is escalated to a governance review panel drawn from the chairs of every working group not directly involved. The panel reviews the documented record, hears both sides in a single public session, and issues a written decision within fourteen days. Panel decisions are binding for the dispute at hand and become precedent for future disputes of the same kind.

Conduct enforcement

The conduct working group operates independently of the technical working groups. Its decisions are not reviewable by the governance review panel and may be appealed only through the procedure described in the code of conduct.

Amending this document

This governance model is itself an RFC. Amendments follow the same lifecycle as any other RFC, with one exception: the review window for governance RFCs is extended to four weeks, and acceptance requires the endorsement of at least two-thirds of seated working-group members across all groups.