Trust Registries enable a Relying Party to determine the authenticity and authorization of a legal entity within a digital credential ecosystem. Trust Registries are crucial to establish for production environments, because they allow relying parties to make informed decisions on whether to trust the credentials they receive.

cheqd has pioneered a industry-leading trust registry solution, allowing users to create hierarchical chains of trust, with each trust registry entry being DID-Resolvable.

cheqd’s Trust Registry Model

cheqd offers an industry-leading, decentralized trust registry solution, allowing issuers to be accredited through hierarchical chains of trust called Decentralized Trust Chains (DTCs). Each entry in the registry is:

• ✅ DID-resolvable

• 📜 Cryptographically signed and verifiable

• 🌍 Publicly discoverable using DID-Linked Resources

• 🔗 Linked to governance frameworks

Learn about cheqd Trust Registries

cheqd enables you to build Decentralized Trust Chains — a powerful model for structuring trust in credential ecosystems without relying on centralized authorities or static whitelists.

Using cheqd’s flexible DID and DID-Linked Resource architecture, trust is established through a chain of cryptographically verifiable credentials:

• Root Authorizations define the governance framework and root of trust

• Verifiable Accreditations delegate authority to trusted organisations

• 🏷Verifiable Attestations (Credentials) are issued by accredited entities to end users

Each link in the chain is publicly resolvable, tamper-evident, and policy-bound — forming a complete lineage of trust from issuer to root authority.

Before you begin building, we recommend familiarising yourself with how Decentralized Trust Chains work and the role of each credential type:

Get started

Use cheqd Studio APIs to define, issue, and publish trust registry entries:

• Create and manage Root Authorizations, Accreditations, and Attestations

• Resolve trust chains in real time using standard DID resolution

• Anchor trust registries on-chain while keeping business logic off-chain

For verification, use TRAIN to validate the trust registry to determine whether an issuer DID is accredited, and what they are accredited for — by traversing the full trust chain to its root.

Users are able to issue Verifiable Accreditations to determine the validity of the accreditation, as well to traverse the trust chain to a root of trust.

Step 1: Issue Accreditation

Make sure you have already created at least one Verifiable Accreditation that you are able to query in the verify API.

Step 2: Use the Verify Accreditation API

Introduction​

Verifiable Credentials (VCs) are most commonly issued by legal entities to assert facts such as identity, qualifications, or authorization. Their core purpose is to provide the Relying Party — the entity verifying the credential — with a Level of Assurance (LoA) that the claims within the credential are legitimate.

However, in practice, it’s often difficult for relying parties to determine whether a legal entity issuing a credential is authentic, or a fraudulent impersonation. There is no built-in mechanism in most credential ecosystems for verifying whether a DID-based issuer is recognised, authorized, or trustworthy.

To fully establish trust, relying parties must be able to:

• Identify who issued a credential

• Understand whether the issuer was authorized to issue it

• Trace who accredited the issuer, and under what governance framework

Introducing Decentralized Trust Chains (DTCs)

To solve this challenge, cheqd introduces a verifiable trust infrastructure called Decentralized Trust Chains (DTCs) — a model that complements and extends approaches like the EBSI Trust Chain Framework.

DTCs allow participants to create hierarchical chains of trust, where:

• A Root Trusted Accreditation Organisation (rTAO) defines the governance model

• Verifiable Accreditations delegate authority to other legal entities (e.g., TAOs, Trusted Issuers)

• Verifiable Credentials are issued by accredited issuers, with embedded metadata that references the trust chain

Together, these components form a decentralized trust registry for each ecosystem.

Publicly Verifiable, Policy-Governed Trust

cheqd’s DTC model introduces both permissions and policies:

• Permissions define what an entity is allowed to do (e.g. issue or accredit)

• Policies define who granted that permission, under what framework, and with what legal or operational requirements.

This infrastructure is made publicly resolvable by publishing all authorizations and accreditations as DID-Linked Resources on the cheqd ledger. This means:

• 🧩 Trust relationships are machine-verifiable

• 🔍 Verifiers do not need prior knowledge of each entity

• 🛠️ Resolution follows W3C standards like DID-Core, DID Resolution and DID-Linked Resources.

The result: A scalable, cryptographically verifiable way to determine whether an issuer — and the credential they issue — can be trusted.

Glossary

There are many terms used within this guide, and as such, familiarise yourself or refer back to the concepts within the glossary below:

Establishing a Trust Hierarchy

Decentralized Trust Chains are based on the concept of a hierarchical trust model, conceptually similar to traditional Public Key Infrastructure (PKI). At the top sits a Root of Trust, from which trust is delegated through a verifiable chain of credentials.

In this model, each participant is identified by a Decentralized Identifier (DID) and may be granted permission — via a Verifiable Accreditation — to accredit others or issue credentials themselves.

How the Hierarchy Works

Trust is delegated top-down through Verifiable Accreditations:

The following diagram show how a Root TAO accredits two TAOs lower in the hierarchy:

Each role is cryptographically linked through issued Verifiable Credentials, creating a machine-verifiable trust path.

Verifiable Credentials & Policy Enforcement

• Credentials are issued with a termsOfUse section that references an Attestation Policy, linking them back to the issuer’s accreditation and the root of trust.

• Digital Wallets or agents can present these credentials for verification.

• Verifiers can then resolve and validate the entire trust chain — from the issuer to the rTAO — using DID resolution and optional DNS anchoring.

Trust Infrastructure Roles and their Permissions

As shown in the diagram above, legal entities can play the following roles:

• In a Decentralized Trust Chain, each legal entity assumes a defined role with clearly scoped permissions. While a single DID may represent multiple roles in simple ecosystems, every complete trust chain should include these three functional roles:

  • Root Trusted Accreditation Organisation (rTAO)

  • Trusted Accreditation Organisation (TAO)

Root Trusted Accreditation Organisation (rTAO)

The rTAO is the root of governance in a trust chain. It establishes the ecosystem’s rules and authorizes who can issue or accredit within it.

Capabilities:

• Issue a Root Authorization that defines the Trust Framework

• Self-accredit for governance or issuance

• Accredit TAOs and TIs to delegate responsibility

• Revoke accreditations from any participant in the trust chain

Credential Type:

• VerifiableAuthorizationForTrustChain

Policy Type:

• TrustFrameworkPolicy (included in termsOfUse)

Trusted Accreditation Organisation (TAO)

A TAO manages a delegated segment of the trust chain under the rTAO. It may further accredit entities or take on the role of issuer if permitted.

Capabilities:

• Accredit itself to issue VCs

• Accredit other TAOs or Trusted Issuers

• Revoke accreditations issued within its scope

Credential Type:

• VerifiableAccreditationToAccredit

Policy Type:

• AccreditationPolicy (included in termsOfUse)

Trusted Issuer (TI)

A Trusted Issuer is an entity that issues domain-specific Verifiable Credentials under the conditions granted by its accreditation.

Capabilities:

• Issue Verifiable Credentials to users or organisations

• Only within the types, schemas, and jurisdictions defined in their accreditation

Credential Type:

• VerifiableAccreditationToAttest

Policy Type:

• AccreditationPolicy (accreditation) + AttestationPolicy (included in the issued credential’s termsOfUse)

Policies Overview

Policies define the rules, permissions, and governance bindings for each layer of the trust chain. They are embedded into credentials via the termsOfUse field and fall into three types:

How Policies are Linked

• Root Authorization includes a TrustFrameworkPolicy

• Each Accreditation must reference:

  • A parent AccreditationPolicy, or

This layered policy model enables verifiers to traverse and validate the entire trust chain — from a single credential back to a rTAO (optionally anchored in DNS) — while ensuring that all participants adhere to consistent governance and operational standards.

Trust Types in Decentralized Trust Chains

Trust Chains are constructed from three verifiable building blocks:

1. Authorizations

• Define the rules of the ecosystem

• Issued by the rTAO as a VerifiableAuthorizationForTrustChain

• Reference the root governance framework

2. Accreditations

• Grant permission to accredit or issue

• Are always domain-specific and non-transferable

• Must include an AccreditationPolicy in termsOfUse

• Allow entities to govern or issue

3. Credentials (Attestations)

• Assert facts (identity, qualifications, rights)

• Must include an AttestationPolicy that:

  • Links back to the issuer's accreditation

  • Establishes a trust path to the root authority

In Summary:

Get Started

Get started

Use cheqd Studio APIs to define, issue, and publish trust registry entries:

• Create and manage Root Authorizations, Accreditations, and Attestations

• Resolve trust chains in real time using standard DID resolution

• Anchor trust registries on-chain while keeping business logic off-chain

For verification, use TRAIN to validate the trust registry to determine whether an issuer DID is accredited, and what they are accredited for — by traversing the full trust chain to its root.

What is TRAIN?

TRAIN (TRust mAnagement INfrastructure) is a framework, led by the team at the , for establishing and validating decentralized trust. It allows ecosystems to verify whether Verifiable Credentials (VCs) were issued by authorized and trustworthy entities through cryptographically linked trust chains.

TRAIN includes two core components:

A Trusted Accreditation Organisation (TAO) can extend trust further down the hierarchy by accrediting Sub-Trusted Accreditation Organisations (SubTAOs). These SubTAOs may then be authorized to issue further Verifiable Accreditations or Verifiable Attestations, subject to defined constraints.

The Verifiable Accreditation should include:

Permissions

The credentialSubject section outlines what the SubTAO is accredited to do — including supported credential types, relevant schemas, and jurisdictional constraints.

Whereby:

Policies

The termsOfUse field contains an AccreditationPolicy, which points back to both the parent accreditation and the original root authorization. This maintains traceability through the full trust chain.

Whereby:

Example of fully formed Accreditation

The example below shows a Verifiable Accreditation that is issued by an TAO to a SubTAO, granting permission to issue further accreditations under a defined schema and policy chain.

For all Verifiable Accreditations, the accreditations are stored as DID-Linked Resources (DLRs), linked to the DID of the Accreditor. This means that the Accreditations are publicly available, fully DID resolvable and are signed by the authentication keys within the DID Document of the Accreditor.

To issue a Verifiable Accreditation, follow the tutorial below:

A Trusted Accreditation Organisation (TAO) can delegate authority to Trusted Issuers (TIs) by issuing them Verifiable Accreditations. These accreditations grant permission to issue specific types of Verifiable Attestations — such as diplomas, licences, or professional credentials — within the boundaries of a defined governance framework.

The Verifiable Accreditation should include:

Permissions

Root TAOs can set permissions under which TAOs must abide. This creates a level of codified governance for the trust ecosystem.

Field descriptions:

Policies

The termsOfUse field contains the AccreditationPolicy, which provides governance context by linking to both the TAO’s parent accreditation and the root authorization of the trust chain.

Whereby:

For all Verifiable Accreditations, the accreditations are stored as DID-Linked Resources (DLRs), linked to the DID of the Accreditor. This means that the Accreditations are publically available, fully DID resolvable and are signed by the authentication keys within the DID Document of the Accreditor.

To issue a Verifiable Accreditation, follow the tutorial below:

A Root Trusted Accreditation Organisation (rTAO) can delegate trust by issuing Verifiable Accreditations to Trusted Accreditation Organisations (TAOs). These accreditations define the permissions and scope under which the TAO can operate.

The Verifiable Accreditation should include:

To ensure a Verifiable Credential (VC) is not only technically valid but also issued by an authorized and trusted party, it must include metadata that links back to its origin in a trust registry.

This is done using the termsOfUse property, where the Trusted Issuer includes an AttestationPolicy referencing:

• The Verifiable Accreditation that granted them permission

What is a Root Authorization?

A Root Authorization — formally a Verifiable Authorization for Trust Chain — defines the governance framework and trust rules for an entire decentralized trust ecosystem.

It serves as the starting point for all Verifiable Accreditations and Verifiable Credentials issued within a trust chain. Every accreditation and attestation must ultimately trace back to a valid Root Authorization to establish its legitimacy.

The Root Authorization anchors the root entity — the Root Trusted Accreditation Organization (rTAO) — to a specific Trust Framework Policy, and enables verifiers to traverse the full chain of trust.

Purpose of a Root Authorization

Key Characteristics

• Credential Type: Must be of type VerifiableAuthorizationForTrustChain.

• Issuer: The DID of the Root Trusted Accreditation Organization (rTAO).

• Credential Subject: The DID being authorized — this can either be:

Required Fields

Example of a Root Authorization

Important Notes

• Self-Authorization: When the issuer and subject are the same DID, the rTAO self-declares adherence to the trust framework.

• Delegated Root Authorization: When the subject is a different DID, the rTAO is immediately empowering another trusted entity to operate under the framework.

• Policy Binding: All downstream Verifiable Accreditations and Attestations must reference a chain of authorizations and accreditations back to this Root Authorization.

Visual Flow

Summary

Overview

A Trust Chain is a hierarchical structure of Verifiable Accreditations (VAs) that connects a Trusted Issuer to a Root Trusted Accreditation Organisation (rTAO). This structure allows credentials to be verified as trustworthy using tools like TRAIN, by tracing authority through cryptographic delegation.

Each step in the chain is formalised using a Verifiable Accreditation, while the root is anchored using a Root Authorization for Trust Chain, which establishes the governance framework of the ecosystem.

If you're ready to issue your first accreditation, skip ahead to use cheqd Studio:

Overview

To enable DNS-based verification of root authorities in your trust ecosystem, TRAIN relies on a component called the TDZM (Trust-DNS Zone Manager). This component manages DNS zones where Root Trusted Accreditation Organisations (rTAOs) can anchor their DIDs using TXT or TLSA records.

This page explains how to deploy TDZM, anchor your rTAO, and configure the environment to support trust chain resolution using DNS.

Overview

TRAIN is a trust validation service that evaluates the trustworthiness of Verifiable Credentials (VCs) by checking whether the issuer's Decentralized Identifier (DID) can be traced back to a trusted source—known as a root of trust.

This page explains how TRAIN performs trust validation for credentials issued within the cheqd ecosystem, using Decentralized Trust Chains (DTCs) to verify each step in the chain from the credential issuer to a recognized root authority.

Get started with TRAIN TTV API

Use the TRAIN APIs below to validate your trust chain:

What TRAIN Does

TRAIN's Trust Validator (TTV) validates credentials by:

1. Taking a Verifiable Credential (VC) as input.

2. Identifying the issuer DID from the credential.

3. Following the credential's trust chain, resolving links between DIDs, Verifiable Accreditations, and Trust Anchors.

4. Verifying whether the top-level (root) entity in the chain is a trusted source (e.g., DNS-anchored entity, government body, industry group).

How TRAIN Uses the cheqd Trust Anchor

Within the cheqd network, Trust Anchors represent root entities that can authorize other issuers via Verifiable Accreditations. These accreditations form Decentralized Trust Chains, which TRAIN evaluates to determine if a credential is trustworthy.

TRAIN integrates the cheqd Trust Anchor model by:

• Recognizing VerifiableAccreditation credentials as establishing authority between entities.

• Resolving these links recursively up the chain until it reaches a root-level DID.

• Checking whether the root DID is associated with a DNS-anchored Trust Anchor using DNSTrustFrameworkPointer entries.

Validation Logic

When TRAIN evaluates a credential issued within cheqd's ecosystem, it performs the following checks:

1. Credential Verification Validates the signature and schema of the input Verifiable Credential.

2. Trust Chain Resolution Follows the termsOfUse field and associated VerifiableAccreditation resources to build the credential’s trust chain.

3. Anchor Resolution Locates the root DID and evaluates whether it has a valid DNSTrustFrameworkPointer or other proof-of-authority reference (e.g., X.509 linkage).

TRAIN Trust Validator (TTV) Request Format

The following fields are used when submitting a request to the TRAIN Trustworthiness Validator (TTV). This validator checks whether the issuer of a Verifiable Credential is trustworthy by tracing their accreditations up a trust chain. The fields below are passed as JSON in the request body and instruct TRAIN on how to resolve and validate the issuer's authority and compliance with a defined trust policy.

TRAIN Trust Valdiator (TTV) Response Format

When a trust validation request is submitted, the TRAIN Trust Validator returns a structured JSON response describing the outcome of the trust chain evaluation. This includes the result of DNS anchoring checks (if requested) and the discovered trust framework that governs the credential's validation.

Below is a breakdown of each field returned in the response:

Benefits of Using TRAIN with cheqd

• Decentralized Assurance: No need to trust a single registry—chains of accreditations are independently verifiable.

• DNS Anchoring: Leverages globally resolvable domain infrastructure to provide high-assurance validation.

• Interoperable: Built on open standards like DIDs, VCs, and JSON-LD for compatibility with other ecosystems.

Sequence Diagram for Validation

Below is a sequence diagram showing how a request is fully validated.

Users are able to issue Verifiable Accreditations as DID-Linked Resources on-ledger, which may be used to verify whether a particular recipient of an accreditation is accredited to issue a certain type of credential, under the scope of a particular governance framework. This implementation on cheqd builds on the principles of the EBSI Trust Chain model, using DID-Linked Resources to create a more standardised format for storing, retrieving and dereferencing to trust registry entries.

Step 1: Set up your account

Make sure you have set up your account with cheqd Studio and are logged in, using our guide below:

Step 2: Create a DID

Before you can create a Verifiable Accreditation, you need to create a DID which is used to link to one or multiple Verifiable Accreditations on-ledger. Use the API in the page below to create a DID:

Step 3: Choose the type of Accreditation

Verifiable Accreditations are JSON objects that take the form of the Verifiable Credential data model. There are three types of Verifiable Accreditation:

Step 4: Compile the appropriate request format for the API

For each accreditation type, the user will need to use a different request format for the API.

Verifiable Authorization for Trust Chain

Verifiable Accreditation to Accredit

For a trusted ecosystem, these attestations are required to trace the legitimacy of a credential issuer to a root-of-trust.

Verifiable Accreditation to Attest

For a trusted ecosystem, these attestations are required to trace the legitimacy of a credential issuer to a root-of-trust.

Step 5: Make request to the API

Step 7: Reference the Verifiable Accreditation

Owing to the design of DID-Linked Resources, following the creation of the a Verifiable Accreditation, users are able to reference the specific version, or create a query to always fetch the latest version of the Accreditation.

Using a DID Resolver or the search DID endpoint, users can find the DID URL and unique resourceId of the Verifiable Accreditation. The unique resourceId allows users to specify this exact version of the Accreditation.

In the DID Document Metadata, users should find "linkedResourceMetadata", like the following snippet:

Specific version of the Verifiable Accreditation

Here, the "resourceURI" specifies the DID URL of the specific Verifiable Accreditation that was created.

Latest version of the Verifiable Accreditation

In order to reference the latest version of the Verifiable Accreditation, the following construction needs to be used:

did:cheqd:<namespace>:<resourceCollectionId>?resourceName=<resourceName>&resourceType=<resourceType>

For example:

did:cheqd:testnet:0a5b94d0-a417-48ed-a6f5-4abc9e95888d?resourceName=OxfordUniversityAccreditation&resourceType=VerifiableAccreditationToAccredit

Verifiable Accreditation at specific point in time

In order to reference the Verifiable Accreditation at a particular point in time, the following construction needs to be used:

did:cheqd:<namespace>:<resourceCollectionId>?resourceName=<resourceName>&resourceType=<resourceType>&resourceVerionTime=<XMLDateTime>

For example:

did:cheqd:testnet:0a5b94d0-a417-48ed-a6f5-4abc9e95888d?resourceName=OxfordUniversityAccreditation&resourceType=VerifiableAccreditationToAccredit&resourceVersionTime=2023-02-22T06:58:18.61Z