OpenVTC Wiki

8 min read

OpenVTC Ecosystem Overview

The Problem

OpenVTC exists to solve the Know Your Developer problem: how do you know that a contributor to an open-source project is who they claim to be? That their commit history is genuine? That they’re not a sock puppet or a compromised account? And increasingly, that they’re even human?

AI agents can now convincingly imitate real developers, committing, reviewing, and communicating in ways indistinguishable from a person. Traditional trust signals like GitHub reputation or commit history are unreliable when they can be generated by a machine.

Today, most digital identity is delegated — you prove who you are by showing that some authority (Google, your employer, a government) vouches for you. This works, but it creates dependencies on centralized gatekeepers, locks your identity to their platforms, and breaks down in contexts where no single authority is trusted by all parties.

The OpenVTC ecosystem takes a different approach: first-person identity. Instead of asking “who does an authority say you are?”, it asks “who do the people around you say you are?” Trust isn’t granted by a central authority — it’s built from the ground up through real relationships between real people, expressed as cryptographically verifiable credentials. The question becomes not just “who are you?” but “can I verify you’re a real person through a chain of real human relationships?”

The Big Picture

The ecosystem is a stack of open-source projects that together enable Verifiable Trust Communities (VTCs) — groups of people and organizations who establish, verify, and audit trust relationships without relying on a central authority. The system is built on W3C open standards for Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs). Zero-knowledge proofs let participants verify claims — like humanness, age, or membership — without exposing the underlying data, and the spec recommends ZKP presentation by default.

Here’s how the pieces fit together, from bottom to top:

Layer 1: Identity Infrastructure

At the foundation, every participant needs a cryptographically secure identity — a DID. The ecosystem uses did:webvh, a DID method that gives you a portable, self-certifying identifier with a verifiable history of changes. You host your DID document on your own domain or a domain controlled by the provider of your choice, and anyone can verify its entire history of updates, key rotations, and witness attestations.

The didwebvh-rs library provides the Rust implementation of this DID method, and the affinidi-webvh-service runs the infrastructure for hosting and resolving these DIDs at scale.

Layer 2: Key Management and Signing

Your DID is backed by cryptographic keys, but managing keys securely is hard. The Verifiable Trust Agent (VTA) solves this — it’s an always-on service that manages your keys, signs things on your behalf, and can run inside hardware-isolated enclaves so your key material never touches an unprotected environment.

The VTA is the heart of the Verifiable Trust Infrastructure (VTI). It acts as a signing oracle: applications ask it to sign credentials, DID updates, or messages, and it handles the cryptography. All keys derive from a single seed phrase using BIP-32 derivation, so backing up one mnemonic protects everything.

Layer 3: Secure Communication

Participants communicate via DIDComm v2 — end-to-end encrypted messaging where the encryption is tied to your DID. Messages are routed through mediators, so participants don’t need to know each other’s IP addresses. The Affinidi Trust Development Kit provides the messaging infrastructure, including a mediator service. As of mid-2026 the mediator is dual-protocol: it also speaks the leaner ToIP Trust Spanning Protocol (TSP) on the same connection, and the ecosystem’s official transport preference is now TSP first, with DIDComm as the interop fallback.

Layer 4: Trust Credentials

Trust relationships are expressed as Decentralized Trust Graph (DTG) Credentials — a family of Verifiable Credentials defined by the Trust Over IP Foundation (spec v0.3). These fall into four functional categories, with the foundational credentials being:

  • Membership Credentials — proof that you are a real, unique human within a community (the ecosystem’s answer to AI agent impersonation). Membership is verified through a bi-directional pair of VMCs.
  • Relationship Credentials — peer-to-peer trust attestations between two people. A relationship is verified through a bi-directional pair of VRCs (one each direction forms a complete edge).
  • Endorsement Credentials, Witness Credentials, and Persona Credentials — annotations that strengthen existing edges with skill endorsements, third-party attestations, and persona linking

These credentials form the Decentralized Trust Graph — a graph whose nodes are entities (people, devices, agents, communities) and whose edges are credential pairs. Anyone can trace trust paths between participants. Communities can federate into Verifiable Trust Networks (VTNs), and trust registries provide authoritative records of which entities are authorized to perform specific actions within a community.

Layer 5: The User Experience

OpenVTC is the user-facing TUI that ties it all together for end users. It walks you through creating your identity, establishing trust relationships with others, and participating in trust communities — including multiple trust communities simultaneously, each with its own persona and lifecycle: the multi-community pivot completed in June 2026 (the Banyan milestone), with a working invitation-credential join flow and a Ctrl+K community switcher. Behind the scenes, it orchestrates the VTA, DIDComm messaging, and credential issuance.

On mobile, the VTI now ships two thin native apps — Authenticator (a holder’s pocket approver for AAL step-up over DIDComm v2) and PNM mobile (mobile counterpart of the pnm operator CLI) — both built on a shared Rust UniFFI engine, vta-mobile-core.

And for anyone who wants to stand the whole stack up themselves — from a throwaway learning VM to a hardened production deployment — the vti-setup repo provides tested, version-pinned setup guides organized by persona (developer, community manager, sysop).

The First Person Network

The ecosystem implements the First Person Protocol, described in the First Person Project white paper. The vision is a world where your digital identity belongs to you, your trust relationships are verifiable by anyone, and no single organization can revoke your identity or gatekeep your participation.

The name “first person” is deliberate — this is identity asserted by you, not about you by someone else. You create your own DID, you host it on the domain of your choice, and the trust graph is built from mutual attestations between peers.

Where Things Are Heading

As of July 2026, several of the fronts described in earlier versions of this page have landed — and the frontier has moved:

  • Multi-community is done. The end-user CLI’s rearchitecture completed in a single month (the Banyan milestone, June 2026): one VTA account, many persona-backed community memberships, a real invitation-credential join flow with verdict-based admission, and reciprocal membership credentials flowing both ways. What remains is polish: presentation-requirement discovery, persona key rotation, richer per-community views.
  • TSP is the new transport direction. In a coordinated June–July push across the TDK, VTI, and did-hosting-service, the ToIP Trust Spanning Protocol graduated from experiment to supported transport — interoperable with the ToIP reference implementation, served by the same mediators as DIDComm, and now preferred over DIDComm wherever both ends support it.
  • The VTA is broadening who it serves. Two new client classes emerged in June: AI agents — the VTA is being positioned as the trust anchor under personal-AI-agent runtimes, with an MCP server (vta-mcp) exposing its signing oracle and secrets vault to hosts like Claude Desktop, agent DID templates, and scoped credential issuance — and enterprises, with a proposed fleet-management model that separates owner and user duties. Meanwhile the phone completed its promotion: the mobile approver now cryptographically signs both approvals and denials.
  • Production posture is real. The VTI ran a systematic P0–P3 security campaign (TEE anti-rollback, storage AAD binding, audit hash chains, OpenAPI specs, fuzzing) and now publishes its crates via trusted publishing; the TDK sealed its public APIs behind a semver policy; three repos coordinated a fuzzing push; and the new vti-setup repo gives operators tested walkthroughs from sandbox to hardened deployment.
  • The spec is formalizing. The DTG credential spec has scaffolding on a branch for its first formal ToIP Working Draft, using the Spec-Up-T template.

The direction of travel is unchanged but closer: a fully self-contained, publicly deployable trust infrastructure that any community can adopt — now with the phone and the AI agent, not just the terminal, as first-class holders and approvers of credentials, and TSP as the emerging common transport underneath it all.

For a release-by-release timeline of how the ecosystem got here — including each project’s recent activity log — see the wiki log and the Recent Development section on each entity page.

Reading This Wiki

This wiki is organized into:

Start with the concepts if you want to understand the “why.” Start with the entities if you want to understand the “what.” The pages are heavily cross-linked — follow the threads that interest you.

Graph View

Backlinks