The credential and governance layer: Verified Trust Communities (VTCs) and Verified Relationship Credentials (VRCs) built on W3C Verifiable Credentials. Multi-step trust operations run as trust-task ceremonies, credentials are issued through a unified Credential Factory, and community rules are enforced by a Governance Guard backed by a data-driven Policy Engine.
Layer 3 is no longer just designed — it is implemented and shipped in v0.1.0. The Credential Factory, Governance Guard, Policy Engine, and the trust-task ceremony engine are all working code, exercised today by the reference applications.
Layer 3 is the credential and governance layer — where the authenticated relationships established in Layer 2 are used to perform meaningful trust tasks: issuing credentials, verifying membership, delegating authority, and participating in governance.
The core primitives at this layer are:
Together, these primitives enable a trust graph that is sovereign (no central authority), private (relationships are disclosed only to parties who need to know), tamper-proof (cryptographically signed), and traversable (the graph can be queried to answer trust questions like "is this person a member of this community?" or "does this agent have authority to act on behalf of this person?").
Layer 3 runs multi-step operations as ceremonies: an ordered sequence of steps,
each of which is either a policy gate (a decision that must allow) or an effect
(an action dispatched through the transaction coordinator). The ceremony and step definitions live
in the database (ceremony_templates and trust_task_templates), while the
executors live in code. Every step is recorded as a request/response pair in the
trust_tasks log, giving each operation a complete, auditable trail.
VTC establishment — creating a community and minting its founding members'
membership credentials in a single atomic transaction, then fanning out delivery over TSP — is
live in the testbed, alongside membership onboarding, VRC
personhood, and policy evaluation ceremonies. The ceremony engine,
templates, and the trust_tasks audit log all ship in v0.1.0.
The Credential Factory is the single interface for minting, verifying, and displaying credentials. It routes each request to the correct signing path — W3C Verifiable Credentials for the DTG credential types, CESR for community credentials, and JCard/JSON for relationship cards — and validates governance rules before issuing any community-governed credential.
The DTG credential family it covers includes relationship (VRC), membership (VMC), invitation (VIC), persona (VPC), endorsement (VEC), witness (VWC), and delegation (VDC) credentials, plus relationship cards (RCards). Higher layers ask the factory for a credential by kind and scenario rather than by storage format.
Every consequential action — issuing a credential, approving a membership, crystallizing a ceremony, changing a role — passes through the Governance Guard. The guard is stateless and owns the cryptographic checks (Ed25519 signature verification and M-of-N threshold counting, which cannot be expressed as policy) and the database reads that assemble the facts a decision needs.
The authorization decision itself belongs to the Policy Engine, an in-process
interpreter for structured JSON policy documents. A community's rules live as data in its
governance.policy_rules column and can be edited at runtime — no code change, no
redeploy. The engine supports six comparison operators, nested
any/all/not groupings, and the allow /
deny / requireStepUp / requireConsent decision vocabulary,
with a fail-closed default: deny short-circuits, and a rule whose fact cannot be
determined refuses rather than guesses.
The Trust Tasks framework is
an independent effort to standardize how trust tasks are executed. We have incorporated its
approach: our trust tasks use peer-scoped type identifiers —
task:p2pts:<family>:<slug>:<version>, for example
task:p2pts:policy:evaluate:0.1 — carried in a conformant JSON envelope with request
and response forms, and our policy documents use the framework's document and decision vocabulary.
This adoption is in anticipation of interoperability. Our identifiers stay peer-scoped rather than web-domain-scoped, so any mapping to the trusttasks.org vocabulary would be applied out-of-band at the boundary. That interop is not implemented yet — no bridge ships in v0.1.0, and a formal compatibility assessment against the registry is still pending.
Visit trusttasks.org →A VTC is a governance-bounded cluster of VTAs. Think of it as a digital cooperative: members join by meeting defined criteria, participate according to shared rules, and can be removed if they violate those rules. VTCs can represent anything from a small family group to a large professional association or a decentralized autonomous organization.
VTCs are defined by their governance rules — who can join, what credentials are required for membership, what actions members can take, and how disputes are resolved. These rules are encoded in the VTC's DID Document and enforced cryptographically.
A VRC is a W3C Verifiable Credential that proves a relationship between two VTAs. Unlike a traditional credential (which is issued by one party to another), a VRC is bidirectional — both parties sign it, and both parties hold a copy. This makes VRCs tamper-proof and non-repudiable: neither party can deny the relationship without invalidating their own signature.
VRCs can encode many types of relationships: membership in a VTC, delegation of authority, endorsement, employment, family relationship, or any other trust relationship that needs to be cryptographically provable.
VRCs are built on the W3C Verifiable Credentials Data Model — an open standard for cryptographically verifiable claims. This means VRCs are interoperable with any system that supports the VC standard, including existing identity wallets, credential issuers, and verifiers.
An R-Card is a W3C Verifiable Credential that represents a VTA's public profile information — the digital equivalent of a business card for the trust graph. R-Cards support per-claim disclosure control with four visibility levels: always public, discretionary (visible only to VTAs with an established relationship), never disclosed via R-Card, or available only through a zero-knowledge proof. R-Cards are exported in JCard format for interoperability with existing VC systems.
A trust task is a defined, repeatable action that requires trust — for example, "verify that this person is a member of this community," "confirm that this agent has authority to sign this document," or "check that this organization meets these compliance requirements." Trust tasks are the unit of work at Layer 3, expressed as conformant JSON documents and executed using verifiable credentials as the evidence of trust.
In this stack, a community's governance rules are not hard-coded — they are a policy document stored with the community and evaluated by the Policy Engine at each decision point. That means the answer to questions like "how many admins must approve?", "which credential kinds may be issued?", or "may this child community affiliate?" can change at runtime, per community, with a full history and without touching the code that runs the stack.