Version 0.1.0 released the core stack. This page tracks what we are working toward next — the workstreams in flight, the design work we are doing, and the directions we are exploring — so that anyone building on the stack, or hoping to, can see where it is going.
This is a working roadmap, not a commitment schedule. The stack is developed in the open and the ordering of work changes as the design matures and as partners integrate it. What we can be precise about is what we are working on and how far along it is.
Each workstream below carries one of the same status labels we use across the site:
In Progress under active implementation · Design / Exploration being designed or investigated; not committed to an implementation shape · Planned agreed as a direction, work not yet started
Shipped vs. upcoming. For what is already built and released, see The Stack, the API Reference, and the CHANGELOG.
Five workstreams are open right now. They are not independent — the mobile app runs on the same stack as the web and TUI apps, and the infrastructure work is what lets people, communities, and servers find each other.
The web dashboard and the TUI proved out the agent application model on the desktop. The next reference application is a mobile agent app — a VTA that lives in your pocket, carrying your DIDs, your relationships, your profile claims, and your credentials, and able to scan an introduction, accept an invitation, or confirm a ceremony from the phone.
This is the workstream that makes Layer 4 real for people who will never open a terminal. It
does not change the protocol — it is the same app-api surface the other reference
apps use, presented for a small screen and a device that sleeps, moves between networks, and
gets lost.
A Utility Server is a network host: it runs the name registry, the credential registry, witness attestation, and the VTC governance primitives a community needs to bootstrap. Today those services are authoritative for the communities that trust them.
Bridging utility servers is the work of letting those hosts recognize and answer for one another, so a community hosted on one utility server can relate to members, credentials, and communities hosted on another — and so the trust graph spans hosts rather than stopping at the boundary of whoever provisioned your server.
Peers find each other today through a bootstrap server that provides discovery and a circuit relay for NAT traversal. That works, but a single bootstrap server is also a single place to be.
We are laying P2P infrastructure through connected bootstrap servers: a fabric of bootstraps that know one another, so an agent entering the network from anywhere can discover peers and reach them through relays without depending on one operator's machine being up. Connectivity is the foundation everything else stands on — it is why this workstream is in flight rather than queued.
Peers find each other through bootstrap servers you point your agent at, and communities are hosted on utility servers you choose to trust. Today, discovering which servers exist — and which ones are worth approaching — is left to whoever is setting things up.
We are going to host a directory at Trust Stackers for the utility and bootstrap servers that want to be found this way. Listing is an optional feature of setting up a server: an operator decides whether theirs should appear, and that decision stays theirs. The directory is a convenience for discovery — a place to look — not an authority over which servers are legitimate.
A Verified Trust Community today gives you membership, governance, credentials, invitations, and conversation. What it does not yet give you is a place — a scoped, membership-gated space inside the community where members work on something together.
Verified spaces would carry the trust model through to collaboration: a space whose access is decided by the community's own governance and the credentials it has already issued, rather than by an administrator's list. This is where trust tasks, the Policy Engine, and Layer 4 meet, and it is the piece we are actively designing.
Beyond the workstreams above, one direction is agreed in principle but has no work behind it yet. It is listed here so the shape of the whole journey is visible:
Order is driven by what unblocks integrations, not by a fixed date grid:
Nothing on this page is a delivery commitment, and workstreams may move as we learn more.
Working on something that touches this roadmap? We integrate the stack with partners and are glad to compare notes. Get in touch →