Koinos Living Roadmap

This repository defines the vision, data, and maintenance process for a living roadmap of the Koinos ecosystem.

The goal is not to publish a calendar of promises. The goal is to show, with verifiable evidence:

• which projects and services exist;
• their actual current state;
• which problems or improvements are being considered;
• which work is active, blocked, or needs an owner;
• who maintains or coordinates each initiative;
• which dependencies exist between projects;
• how the community can contribute.

A future delivery date is not a roadmap requirement. Actual review, start, launch, and status-change dates should still be preserved.

Product Scope

The application should separate four related but distinct concepts.

Ecosystem Map

A catalog of all known ecosystem projects, whether or not they are part of the current priorities.

It should include:

• protocol and system contracts;
• microservices and public infrastructure;
• tools for node operators and block producers;
• SDKs, libraries, and developer experience;
• wallets, explorers, and applications;
• DeFi, bridges, and financial services;
• governance, funding, and community coordination;
• documentation, education, and communications;
• research and experiments.

Implementation Status

A view of the technical and operational state of each project:

• what has been implemented;
• what is deployed and working;
• what has reproducible tests and releases;
• what is actively maintained;
• what is blocked or abandoned;
• what needs an audit or human confirmation.

GitHub activity can be used as a signal, but it must not be interpreted automatically as progress, quality, or effective maintenance.

Roadmap

A selection of improvements and initiatives that matter to the evolution of Koinos. Not every project in the catalog needs to appear here.

The roadmap should explain:

• which problem needs to be solved;
• which outcome is sought;
• why it matters;
• which other initiatives it depends on;
• who is willing to take responsibility;
• which milestones would demonstrate real progress.

History

Completed initiatives should move into the historical record while preserving their owners, evidence, and outcomes. This keeps the roadmap focused on the present and future without losing the ecosystem's memory.

Koinos already has an interactive history page that can be integrated with this workflow.

Principles

No Artificial Dates

Future priorities should be expressed through relative horizons:

• Now: work that is active or ready to begin;
• Next: the next set of initiatives, subject to capacity and dependencies;
• Later: a desirable direction that is not ready yet;
• Research: a hypothesis that needs investigation before becoming a commitment.

These horizons are not delivery dates.

Evidence Before Perception

Every status claim should link to evidence whenever possible: code, a pull request, a release, a test, documentation, a deployed service, or confirmation from the responsible person.

Confirmed Ownership

An initiative should not be assigned publicly to a person or team without confirmation. The system must be able to show Needs owner and Seeking contributors clearly.

Verifiable Progress

The roadmap should not use arbitrary percentages. Progress should be represented through:

• initiative status;
• completed milestones compared with defined milestones;
• completion criteria;
• associated evidence;
• outstanding blockers and dependencies.

Transparency About Uncertainty

Unknown and Needs verification are valid states. Acknowledging missing information is better than presenting a conclusion without evidence.

A Versioned Source of Truth

Canonical roadmap data should be maintained in this repository, reviewed through pull requests, and consumed by koinos.io/roadmap.

Initial Audit of the Public Roadmap

Initial review: August 4, 2026.

The roadmap published on koinos.io currently presents a timeline made up of 34 historical and future entries.

Its current implementation lives directly in the Roadmap.js component through three static collections:

• historical milestones from 2020 through 2024;
• Q3 and Q4 2025 initiatives;
• an open-ended section named Beyond.

The initial structural audit identifies these limitations:

• only the binary states done and todo are available;
• 2025 is still presented as future planning;
• history, deliveries, maintenance, products, and research are mixed together;
• owners and contributors are not shown;
• dependencies and blockers are not explicit;
• completion criteria are missing;
• implementation and deployment evidence is not linked;
• the last verification date is not shown;
• an operational product, a pending improvement, and a research idea are not distinguished;
• content must be changed manually inside the visual component.

The current roadmap is therefore a useful starting source, but it should not be treated as a current description of the ecosystem without verifying each entry.

Proposed Taxonomy

Categories

• protocol
• system-contracts
• node-infrastructure
• public-infrastructure
• developer-tooling
• wallets
• explorers-data
• applications
• defi-bridges
• governance-funding
• documentation-education
• community-communications
• research

A project may belong to several categories, but it should have one primary category.

States

• exploring: a hypothesis that is still under investigation;
• proposed: a described proposal that has not been validated yet;
• ready: scope and owner are confirmed;
• in-progress: active work with recent evidence;
• blocked: an explicit impediment exists;
• operational: running in production or providing its intended service;
• maintenance: operational and focused on stability or incremental improvements;
• completed: the defined outcome has been achieved;
• archived: no longer maintained or replaced;
• needs-owner: no person or team has been confirmed;
• needs-verification: available information is insufficient to confirm the state.

Development state and operational state may need separate fields. A service can be deployed and operational while its next version remains blocked.

Initiative Record

At a minimum, each entry should be able to represent:

id: public-snapshots
title: Public Snapshots
summary: Provide reproducible and verifiable snapshots for node operators.
kind: initiative
category: public-infrastructure
status: needs-verification
horizon: next
owner:
  status: unconfirmed
  people: []
repositories: []
services: []
outcomes: []
milestones: []
dependencies: []
blockers: []
evidence: []
help_wanted: []
last_verified: null
change_log: []

The final schema should distinguish between:

• project: a product or system with its own identity;
• service: a deployable or operational component;
• initiative: a sought change or outcome;
• milestone: a verifiable condition within an initiative;
• dependency: a required relationship between elements;
• evidence: a source supporting a claim;
• person/team: a confirmed owner, maintainer, or contributor.

Technical Audit Method

Every project or service should be reviewed through the same process.

1. Identity and Purpose

• the problem it solves;
• the users or systems that depend on it;
• official repositories and deployments;
• known maintainers.

2. Implementation State

• implemented functionality;
• partial or missing functionality;
• available branches, releases, and artifacts;
• unit, integration, and end-to-end tests;
• build reproducibility.

3. Operational State

• whether the service is deployed and reachable;
• the version actually in use;
• monitoring and runbooks;
• backups and recovery;
• known incidents or limitations.

4. Maintenance

• confirmed owners;
• available capacity;
• relevant issues and pull requests;
• outdated dependencies;
• security or continuity risks.

5. Next Improvements

Improvements should be derived from demonstrated problems rather than historical lists alone. Every proposal should identify impact, approximate effort, dependencies, risk, and a potential owner.

Audit Output

Each review should produce four groups:

• confirmed facts;
• information that needs verification;
• problems and risks;
• possible next improvements.

Collecting Feedback

Koinos Community Foundation

The first review round should validate:

• the initial inventory;
• owners and responsibility boundaries;
• the state of sensitive infrastructure;
• initiatives that are no longer current;
• priorities and dependencies;
• information that should not be public yet.

Community

After initial validation, public feedback should be requested to:

• add missing projects;
• correct states or descriptions;
• provide evidence;
• propose improvements;
• identify owners and volunteers;
• highlight undocumented dependencies or risks.

Conversations may happen on Telegram, Discord, or other channels, but accepted corrections should ultimately be recorded in the versioned source of truth.

Community popularity is a signal, not the only prioritization criterion. The process should also consider:

• impact on users and developers;
• operational or security urgency;
• effort and available capacity;
• dependencies that the work would unblock;
• the risk of not acting;
• the existence of a responsible owner.

Interactive Application

The application should live as a first-class page at koinos.io/roadmap and provide:

• a card-based portfolio view;
• a dependency graph;
• filters by category, state, horizon, and owner;
• Needs help, Needs owner, and Needs verification filters;
• a detailed page for each project or initiative;
• a status-change history;
• links to evidence and repositories;
• relationships with historical milestones;
• a structured way to propose corrections.

The interface should answer four questions quickly:

1. What exists?
2. What works, and who maintains it?
3. What is being improved, and why?
4. Where can a community member help?

Keeping the Roadmap Alive

Periodic Review

Every element should have a last verification date. Elements that have not been confirmed within the agreed review period should move automatically to needs-verification. This is an information review mechanism, not a delivery deadline.

Assisted Automation

The system can collect automatic signals such as:

• latest release;
• open pull requests and issues;
• CI results;
• endpoint availability;
• deployed version;
• broken links;
• age of the latest human confirmation.

Automation must not change strategic claims or assign owners by itself.

History and Traceability

Every status change should record:

• what changed;
• why it changed;
• who confirmed it;
• which evidence supports it.

Shared Stewardship

The roadmap needs a small group of stewards to maintain the schema, review contributions, and request confirmations. Project owners retain authority over the description of their work, while roadmap stewards preserve consistency and evidence standards.

Execution Plan

Phase 1: Inventory

• import the 34 entries from the current roadmap;
• inventory known repositories, services, and applications;
• classify every element;
• mark every unknown explicitly.

Phase 2: Audit

• begin with the protocol and critical infrastructure;
• continue with developer tooling;
• then review wallets, explorers, DeFi, and applications;
• document evidence, risks, and potential improvements.

Phase 3: Validation

• review with the Koinos Community Foundation;
• confirm owners;
• consult the wider community;
• incorporate corrections with traceability.

Phase 4: Interactive MVP

• define the validated schema;
• publish the catalog, filters, and detail views;
• add states, owners, evidence, and dependencies;
• integrate the page with koinos.io.

Phase 5: Continuous Operation

• automate verifiable signals;
• run periodic reviews;
• publish changes and stale elements;
• connect completed initiatives with the history page.

Recommended Initial Audit Order

1. Chain, system contracts, and governance.
2. P2P, mempool, and block producer.
3. Block store, transaction store, and account history.
4. JSON-RPC, REST, gRPC, and public services.
5. Testnet, snapshots, backups, and observability.
6. CLI, SDKs, libraries, and developer tooling.
7. Node tools, wallets, and explorers.
8. Bridges, DeFi, and applications.
9. Documentation, funding, and community coordination.

Definition of Success

The roadmap will be useful when anyone can distinguish clearly between:

• what is operational and what was only proposed;
• what is maintained and what is abandoned or unknown;
• a strategic priority and a backlog item;
• a confirmed owner and a historical attribution;
• an opinion and a fact supported by evidence;
• a blocked initiative and a concrete opportunity to contribute.