Cowrie Research

cheqd

4 min read

cheqd

  • Name: cheqd
  • URL: https://docs.cheqd.io/product
  • Category: decentralized-identity network / DID-and-resource registry / trust-registry infrastructure / credential-payments middleware
  • Tags: cosmos-ecosystem
  • Summary: cheqd is a Cosmos-based DID, resource, and trust-registry stack. The useful part is not the usual SSI branding. It is the attempt to keep identifier control, linked metadata, issuer accreditation, and paid verification resources in one system instead of scattering them across separate registries and hosted APIs.
  • What it does:
    • Defines a W3C-oriented did:cheqd method on a Cosmos-based network, with Universal Registrar / Resolver support and both UUID-style and Indy-style identifiers
    • Stores DID-Linked Resources on-ledger so schemas, status lists, trust registries, governance documents, logos, and related metadata can be resolved through DID URLs instead of ordinary web links
    • Publishes Decentralized Trust Chains (DTCs) where Root Trusted Accreditation Organisations, subordinate accreditation bodies, and trusted issuers are linked through verifiable accreditations and machine-readable policy references
    • Lets credentials include termsOfUse / AttestationPolicy references back to parent accreditations and root authorizations so verifiers can trace issuer authority
    • Offers Credential Payments that gate encrypted status lists or other DID-Linked Resources behind onchain payment conditions, so issuers can charge verifiers or holders for trusted checks
    • Exposes the stack through cheqd Studio APIs, SDKs, direct ledger integrations, and partner SaaS products rather than requiring every adopter to run raw ledger-side identity tooling
  • Key claims:
    • The product overview makes the project’s real surface area unusually explicit: cheqd is not only a DID network, but a package set for DIDs, DID-Linked Resources, status lists, trust registries, schemas, and credential-payment flows.
    • ADR 001 for the did:cheqd method says cheqd chose Cosmos partly to escape Hyperledger Indy’s permissioned-write model and limited token functionality, which is analytically important because cheqd is positioning itself as a more open, tokenized successor to earlier SSI ledger designs rather than a clean-sheet identity primitive.
    • The DID-Linked Resources docs show cheqd’s most reusable mechanism: turning schemas, revocation/status data, trust registries, governance documents, logos, and other metadata into DID-addressable resources. The key insight is that identity power often sits in auxiliary files and URLs, not just in the credential itself.
    • The DTC docs add a second control plane above simple credential issuance. cheqd’s model says trust depends not only on whether a credential verifies cryptographically, but whether the issuer can be traced through a hierarchy of accreditations, governance frameworks, and optional DNS-anchored root authorities.
    • The trust-registry reference docs show that policy is meant to travel with credentials through termsOfUse, parentAccreditation, and rootAuthorization fields. In other words, cheqd is trying to make issuer authorization machine-resolvable at verification time instead of leaving trust as an offchain bilateral assumption.
    • The Credential Payments docs reveal a distinct commercial primitive: verifiers can pay to decrypt status lists or other DID-linked resources, with access control derived from onchain payment conditions and timelock checks. That makes cheqd relevant not only to identity middleware, but also to markets for trusted data access.
    • The privacy docs are especially useful because they show where the payment model could leak correlation and how cheqd tries to mitigate it: large bitstring status lists, flat per-list pricing, and sharded decryption-key control are all attempts to monetize verification without making individual credential checks trivially linkable.
    • cheqd belongs in the active corpus because it helps separate several layers that often get flattened together under “decentralized identity”: DID registration, resource hosting, issuer accreditation, policy transport, credential-status verification, and payment capture.
  • Whitepaper: No canonical standalone cheqd protocol whitepaper surfaced in this pass. The strongest primary materials were the official product docs, DID-method and payment ADRs, DID-Linked Resource docs, trust-chain docs, and credential-payment docs; see ../whitepapers/cheqd-primary-sources-2026-05-10.md.
  • Sources:

Internal linkages

Control surface

  • The chain holds identifiers, linked resources, status references, and payment conditions.

  • The leverage still sits in resolver defaults, Studio packaging, accreditation-framework design, and how paid verification access gets packaged for real users.

  • The useful question is simple: is a team here for DIDs, for machine-resolvable issuer authorization, or for paid verification resources? Those are related, but they are not the same product.

  • Last reviewed: 2026-05-27 UTC

Graph View

Backlinks