cheqd-primary-sources-2026-05-10

cheqd primary sources

Reviewed: 2026-05-10 UTC

Core product framing

• https://docs.cheqd.io/product
  • Official product overview. Best single-page summary of cheqd’s intended stack: DIDs, DID-Linked Resources, status lists, trust registries, schemas, and Credential Payments exposed through Studio, SDKs, and direct ledger integrations.
• https://learn.cheqd.io/
  • Official learning hub. Useful for confirming the project’s broader framing around decentralized identity, CHEQ token usage, governance, and product surfaces.
• https://github.com/cheqd/product-docs
  • Official docs repository mirror. Useful as a stable source handle for the product-docs surface.
• https://github.com/cheqd
  • Official GitHub organization page surfaced in search; useful as the project’s primary code/org handle.

DID method and ledger rationale

• https://docs.cheqd.io/product/architecture/adr-list/adr-001-cheqd-did-method
  • Key source for the did:cheqd method, why cheqd benchmarked against Hyperledger Indy, why it chose Cosmos, how namespaces work, and why both UUID-style and Indy-style identifiers are supported.

DID-Linked Resources

• https://docs.cheqd.io/product/learning-docs/decentralized-id/dlrs
  • Concise explanation of what DID-Linked Resources are and which ecosystem problems they aim to solve: centralization, link rot, and weak semantic version linkage.
• https://docs.cheqd.io/product/studio/did-linked-resources/understanding-dlrs/context
  • Stronger mechanism source for the range of resource types cheqd wants to anchor through DIDs: schemas, status lists, trust registries, visual overlays, documents, and logos.

Trust registries and policy transport

• https://docs.cheqd.io/product/studio/trust-registries/dtc
  • Core source for Decentralized Trust Chains (DTCs): Root Trusted Accreditation Organisations, subordinate accreditation bodies, trusted issuers, governance frameworks, and public trust resolution through DID-Linked Resources.
• https://docs.cheqd.io/product/studio/trust-registries/dtc/referencing-in-credential
  • Shows how cheqd expects trust metadata to travel inside credentials using termsOfUse, AttestationPolicy, parentAccreditation, and rootAuthorization, plus optional DNS-anchored validation via TRAIN.

Credential payments and access control

• https://docs.cheqd.io/product/learning-docs/cheq/credential-payments
  • Best short explanation of the commercial thesis: issuers need a payment rail to justify issuing credentials at scale, and cheqd frames Credential Payments as that adoption catalyst.
• https://docs.cheqd.io/product/studio/payments/learn/access-control-conditions
  • Important implementation-facing source for payment-gated encrypted resources, timelock-based conditions, and the access-control query logic used to unlock status lists or other DID-linked resources.
• https://docs.cheqd.io/product/studio/payments/learn/privacy-considerations
  • Most useful source on the hidden trust/privacy model of cheqd’s payment layer: herd privacy via large bitstring status lists, flat per-list pricing, and decryption-key sharding across nodes.
• https://docs.cheqd.io/node/architecture/adr-list/adr-001-payment-mechanism-for-issuing-credentials
  • Older but useful lineage document connecting cheqd’s payment design to Hyperledger Aries payment decorators and showing how memo-linked payment receipts were meant to fit into credential issuance.

Main takeaways from this pass

• cheqd’s distinct contribution is not merely a DID method; it is the combination of DID registration, DID-addressable auxiliary resources, issuer-accreditation infrastructure, and monetized verification flows.
• DID-Linked Resources are the most reusable primitive in the corpus pass because they relocate trust from ordinary web URLs into DID-addressable ledger resources for schemas, status data, governance files, and trust metadata.
• Decentralized Trust Chains show cheqd trying to make issuer authorization a machine-resolvable part of verification rather than an offchain business assumption.
• Credential Payments reveal a separate market-design layer: cheqd wants verification and status-checking to become billable trusted-data access without fully sacrificing holder privacy.
• The main analytical question cheqd sharpens is where control sits in a credential ecosystem: DID controllers, resource publishers, accreditation roots, policy authors, resolver infrastructure, Studio/API operators, or the parties that collect payment for trusted checks.