> For the complete documentation index, see [llms.txt](https://docs.blerify.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.blerify.com/trust-registry/decentralized-root-of-trust.md). # Blerify's Decentralized Root of Trust Blerify's Trust Registry anchors issuer identity and credential status on-chain, so any verifier can confirm that a credential came from a trusted issuer — without calling Blerify at verification time. This page explains the two on-chain registries, how they work together, and how the Trust Registry fits into the verification pipeline. *** ## Two registries, two questions Every credential verification answers two independent questions: | Question | Registry | | ------------------------------------------ | --------------------------------------------- | | Is the issuer trusted? | **ChainOfTrust** (issuer trust) | | Has this specific credential been revoked? | **Verification Registry** (credential status) | They're separate contracts with separate concerns. You can use one without the other. *** ## ChainOfTrust — issuer trust The ChainOfTrust contract is a hierarchical on-chain registry of issuer signing keys. Each entry associates a public key with an entity, a parent entity, and an expiration window. When a verifier checks a credential, Blerify walks the chain from the credential's signing key up to the root, verifying that every level is active and unexpired. If any ancestor is expired or revoked, the entire chain fails — the credential is untrusted regardless of its cryptographic signature. **Key properties:** * **Hierarchical**: issuers are organized in a tree. A root authority endorses intermediaries; intermediaries endorse issuers. Each level carries its own expiration. * **Single traversal**: trust and certificate-level revocation are resolved in one on-chain query — no separate CRL or OCSP call needed for the issuer's signing key. * **Format-agnostic**: works identically for W3C Credentials (DID-based or X.509-based) and ISO 18013 mDocs. * **EVM-compatible**: deployed on any EVM-based blockchain; Blerify operates nodes on supported chains. **What endorsing trust means:** When an entity is endorsed at a given level in the chain, it must acknowledge the endorsement before trust is established. The endorser retains the ability to revoke or update the endorsement — but endorsing an entity does not give the endorser control over that entity's own identity or its descendants. *** ## Verification Registry — credential status The Verification Registry tracks the lifecycle of individual credentials by their digest (a hash of the credential content), keyed by issuer. Each credential can be in one of three states: | State | Meaning | | --------- | ---------------------------------- | | `ISSUED` | Valid | | `ON_HOLD` | Temporarily suspended — reversible | | `REVOKED` | Permanently revoked — irreversible | A verifier queries `getDetails(issuer, digest)` and receives the credential's current state, its expiration, and whether it's on hold. **What this is not:** the Verification Registry answers *"has this credential been revoked?"* — it does not answer *"is the issuer trusted?"*. Both checks run independently in the verification pipeline. *** ## How the two registries interact During a verification, the pipeline runs both checks in sequence: ``` Credential received │ ▼ Issuer trust check ──── ChainOfTrust ──── trusted? ──── continue │ no │ ▼ ▼ fail: UNTRUSTED_ISSUER Credential status check │ Verification Registry │ ISSUED? ── continue to assurance checks ON_HOLD / REVOKED? ── fail: REVOKED ``` A credential can fail either check independently. A valid signature from a trusted issuer doesn't help if that specific credential has been revoked; and an unrevoked credential from an untrusted issuer fails the first gate. *** ## Decentralized Public Key Directories (DPKDs) The ChainOfTrust implements the DPKD pattern: an on-chain registry where issuer identity and public keys are publicly recorded and resolvable without trusting any single operator. DPKDs support multiple credential data formats including W3C Verifiable Credentials, ISO 18013 digital credentials, and EBSI Legal Entity formats. Entries carry immutable timestamps that record when an entity was registered and when it ceased to be valid, enabling time-bound verification — a verifier can confirm that an issuer was trusted at the moment a credential was issued, even if that issuer has since been removed. *** ## Decentralized Trusted Lists (DTLs) DTLs extend the DPKD model with reputational trust endorsements. Where DPKDs record *identity and keys*, DTLs record *who vouches for whom, and for what purpose*. A DTL is a multi-level smart contract where entities endorse trust to other entities for general or specific purposes. Like DPKDs, DTLs use immutable timestamps — if an entity's reputational endorsement is removed, any credential issued by that entity after the removal timestamp can be rejected. DTLs are designed to be self-managed by the entities that issue and receive endorsements, with no central operator required. They interoperate with DPKDs: a DID resolved via a DPKD can be cross-referenced against a DTL to apply additional trust filtering. *** ## Access recovery In the DRoT model, entities always retain a path to recover access. The entity that originally endorsed trust can update or restore the endorsed entity's access when needed. This doesn't mean the endorser controls the endorsed entity — it means the trust relationship can be repaired if keys are rotated or lost. *** ## Credential-embedded registry pointers (mDocs) For ISO 18013 mDoc credentials, issuers can embed a pointer to the Verification Registry directly in the credential. The pointer is a base58-encoded reference in a custom namespace within the credential document. When a verifier encounters this pointer, the revocation check resolves directly to the referenced on-chain registry — no external configuration or lookup required. This is the preferred approach for mDoc issuers: the credential carries its own verification path, independent of how the verifier is configured. For credentials without an embedded pointer, the verification pipeline falls back to issuer-configured revocation methods. *** ## Next steps [**DID Method did:lac1**](/trust-registry/did-method/did-method-did-lac1.md) — Blerify's DID method builds on top of the DRoT infrastructure: resolving issuer DIDs traces back to keys registered in the ChainOfTrust. See also: [DID Controller](/trust-registry/did-method/did-controller.md) — how smart contracts manage DID operations on supported registries. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.blerify.com/trust-registry/decentralized-root-of-trust.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.