cheqd Trust Registries
- Name: cheqd Trust Registries
- URL: https://docs.cheqd.io/product/studio/trust-registries.md
- Category: trust-registry infrastructure / issuer-accreditation middleware / decentralized-identity governance layer
- Tags: cosmos-ecosystem
- Summary: cheqd Trust Registries are best understood not as a generic credential feature inside cheqd, but as a distinct issuer-authorization control plane built on decentralized identifiers, DID-linked resources, verifiable accreditations, and optional DNS-anchored roots. The core move is to separate three things that many credential systems blur together: a root authority that defines governance, accreditation credentials that delegate who may accredit or issue, and downstream attestations that must carry machine-readable references back to that trust chain. That makes cheqd Trust Registries a useful comparison class for EBSI trust-chain designs, attestation registries, and emerging agent trust registries: the main question is not just whether a credential verifies cryptographically, but who authorized the issuer, under what policy, and how a verifier resolves that lineage.
- What it does:
- Lets ecosystems publish decentralized trust registries as hierarchical Decentralized Trust Chains (DTCs) rather than as static issuer allowlists
- Splits the trust hierarchy into Root Trusted Accreditation Organisations (rTAOs), Trusted Accreditation Organisations (TAOs), and Trusted Issuers (TIs)
- Uses verifiable accreditations to delegate authority down the chain and policy references in issued credentials to link attestations back to parent accreditations and root governance
- Stores trust-registry material as DID-resolvable, cryptographically signed DID-Linked Resources on cheqd so verifiers can resolve entries through standard DID tooling
- Supports schema- and jurisdiction-scoped permissions through accreditation payloads, so issuers are authorized for specific credential types rather than receiving a blank trust badge
- Pairs with TRAIN infrastructure so validators can traverse accreditations to a root and optionally confirm the root authority through DNS anchoring
- Extends the same trust-chain model into AI-agent onboarding flows, where cheqd Studio APIs and MCP tooling provision DIDs and credentials inside an agent trust registry
- Key claims:
- The strongest mechanism insight is that cheqd is not only publishing credentials or attestations; it is publishing issuer authority itself as a verifiable chain. That turns trust from an offchain bilateral assumption into a resolvable object graph.
- The DTC docs make the role split unusually legible. An rTAO sets the governance baseline, TAOs manage delegated accreditation scope, and TIs issue end-user credentials. Keeping those roles distinct is more analytically useful than flattening the system into one generic
issuer registry. - The model is explicitly policy-bearing, not only identity-bearing. The docs say permissions define what an entity may do, while policies define who granted that permission and under what framework. That means the real control surface sits in governance framework design, accreditation scope, and revocation authority.
- DID-Linked Resources matter here because they make trust-registry entries publicly resolvable and machine-verifiable without relying on one hosted directory. The registry is meant to travel through DID resolution rather than through one SaaS allowlist.
- TRAIN adds a second important layer beneath the product story. It separates publication of trust-chain credentials from validation of those credentials, and further separates cryptographic accreditation traversal from optional DNS anchoring of the root authority. That makes root-discovery and root-authentication distinct control surfaces.
- The AI-agent setup docs are useful because they show the trust-registry model is being reused outside traditional human credential ecosystems. cheqd is positioning the same authorization chain for agent issuers, auditors, governance authorities, and agent wallets.
- cheqd Trust Registries belong in the active corpus because they preserve a reusable mechanism that would be blurred if left only under the parent
cheqdpage: issuer trust is decomposed into root governance, delegated accreditation, DID-addressable publication, and validator-side chain traversal.
- Whitepaper: No standalone trust-registry whitepaper surfaced in this pass. The strongest primary materials were cheqd’s official trust-registry docs, the Decentralized Trust Chains documentation, the TRAIN docs, and the AI-agent trust-registry setup guide collected in
../whitepapers/cheqd-trust-registries-primary-sources-2026-05-14.md. - Sources:
- https://docs.cheqd.io/product/studio/trust-registries.md
- https://docs.cheqd.io/product/getting-started/ai-agents/trust-registry.md
- https://docs.cheqd.io/product/getting-started/ai-agents/trust-registry/setup.md
- https://raw.githubusercontent.com/cheqd/product-docs/main/studio/trust-registries/README.md
- https://raw.githubusercontent.com/cheqd/product-docs/main/studio/trust-registries/dtc/README.md
- https://raw.githubusercontent.com/cheqd/product-docs/main/studio/trust-registries/train/README.md
- https://github.com/cheqd/product-docs
Internal linkages
-
Parent chain / DID stack and adjacent issuer-governance substrate: cheqd
-
Stronger comparison points for shared attestation publication or document-proof trust packaging: ethereum-attestation-service and openattestation
-
Last reviewed: 2026-05-23 UTC