cheqd is a purpose-built network for decentralised identity. This documentation site provides technical and product information for all identity features & functionality on the cheqd network.

Integrate with cheqd

cheqd maintains an array of products and packages with varying levels of integration complexity to allow its partners and customers to have multiple ways of plugging into cheqd's identity functionality. Via these different packages, customers and partners can create cheqd DIDs, DID-Linked Resources, Status Lists, Trust Registries and Schemas, as well as use cheqd's Credential Payments model.

There are three core ways of integrating and building with cheqd:

What functionality does cheqd offer?

cheqd's identity functionality is fully standards-compliant, ensuring interoperability and no vendor lock-in. cheqd's tooling and different product offerings offer a variety of building blocks for any Trusted Data Market.

Industry Standard DID Support

If you want to utilise cheqd DIDs or DID-Linked Resources within applications without a specific cheqd integration, you can incorporate a Universal Registrar or Universal Resolver driver to support did:cheqd alongside other commonly adopted DID methods.

Get started with cheqd Studio

cheqd Studio is the easiest route to get started with cheqd's identity functionality, or for testing with very low integration effort. Using simple REST APIs, it is possible to integrate cheqd Studio in a few lines of code.

Under the hood, cheqd Studio utilises the Veramo SDK cheqd Plugin, providing the most feature complete set of functionality and tooling.

If you'd rather build a deeper integration using a Software Development Kit (SDK) or lower level package, we've created a simple diagram to show how our packages are structured below.

Understanding cheqd's capabilities

cheqd supports a wide array of standards and protocols via different Software Development Kits (SDKs) and integrations.

Understanding the structure of cheqd's packages

One of cheqd's primary motives is to make itself accessible to the widest set of identity applications possible. To accomplish this, cheqd has built a flexible set of packages and tooling to accommodate its identity capabilities into a broad set of external SDKs and applications.

These can be represented through the visual below:

Partner SaaS products

You can also leverage SaaS products from our partners that consume these underlying SDKs to build high-quality credential ecosystems on top of cheqd’s infrastructure:

Get involved

The cheqd Discord is our primary chat channel for the open-source community, software developers, and node operators.

Please reach out to us there for discussions, help, and feedback on the project.

🙋 Find us elsewhere

Introduction

cheqd Studio is a set of APIs, guides and tutorials to help users establish an end-to-end trusted ecosystem for digital credentials.

Using REST APIs, customers can build cheqd's trust infrastructure into existing applications. All of cheqd’s existing open-source libraries remain available, and cheqd Studio does not necessitate developers to switch their SSI stack in their entirety, but allows them to build into their existing tooling, for example alongside APIs such as the Universal Resolver.

Get started

Features

cheqd Studio directly leverages our Veramo SDK Plugin, making a wide array of features available from launch, including:

Understanding the different modes and client choices

With cheqd Studio, there are multiple ways it can be deployed and hosted to support clients with different requirements.

Option 1: Custodied by cheqd (Custodian Mode)

This mode is the most simple for users, allowing cheqd to custody both Cosmos AND Identity keys in Veramo KMS. This means that manages both ledger-writes and signing identity transactions on behalf of the customer.

To ensure this is highly secure, we have deployed an instance of a Veramo Key Management Store (KMS) which uses a Postgress DB (TypeOrm) to store Cosmos AND identity keys in one encrypted table, so it cannot be read in plaintext. This design allows us to segment different customers' keys securely and efficiently.

We use similar techniques to Password Managers such as 1Password and Bitwarden to ensure that even if the database were to be compromised, the keys would remain encrypted and unusable.

User optionality and toggles:

Within Custodian mode, we also enable clients to toggle

Option 2: Self-custodied (Client-managed mode)

Client-managed mode gives the cheqd Studio user the ability to utilise their own identity keys for signing identity transactions, while still allowing cheqd Studio to manage the CHEQ account keys for writing to the cheqd network. This mode is intended to be used for more production environments where the user signs each identity transaction independently, affording a greater level of security and control to the client.

Architecture

Under the hood, cheqd Studio leverages our Veramo SDK Plugin for its identity functionality. Check out our guide on supported SDKs to understand how cheqd Studio fits together with our other Open Source packages.

Alternative: Use an SDK

If you would rather a deeper integration with lower-level packages, instead of REST APIs, take a look at our suite of cheqd supported SDKs below. Each offers a different set of protocols and underlying technical capabilities.

The user is required to Log In to our cheqd Studio portal and then access their API key to authenticate with our APIs. The API key guards the API from unauthorized access and is required for both testing production environments.

Step 1: Get started with cheqd Studio

Head to our cheqd Studio and click Get Started.

Step 2: Create your account

cheqd Studio uses a third party service called LogTo to handle user authentication and login. You can create an account or sign in using:

• Email and password

• Google single sign-on

• Discord login

Click Sign In or Create Account to continue.

Step 3: Create a new API key and authenticate with cheqd Studio APIs

Once signed in, create an API key from your account dashboard. This key is required to authenticate with cheqd Studio APIs and protects your environment from unauthorized access.

Step 4: Start using cheqd

Get started with our tutorials for cheqd Studio functionality.

Step 5: Select a Billing plan

You will be able to get started for free on our free trial, but following the expiry of the free trial, users need to sign up for a paid billing plan. cheqd Studio billing uses Stripe as a payments processor and users will need to input their card information to initiate a billing plan.

API keys are unique data strings used to authenticate a user and enable access to privileged operations on cheqd Studio APIs. All cheqd Studio APIs use API keys as the mechanism to authenticate client requests. Your API key should be kept confidential and secure at all times.

• Authentication is required for all API requests; without it, the requests will fail.

• All API requests must be made over HTTPS.

Step 1: Sign into cheqd Studio

Follow the tutorial here to get started with your cheqd Studio account.

Step 2: Generate API key

Navigate to the "Developers" tab on cheqd Studio and select "Create an API Key". You are able to choose the expiry date of the API key, and it will automatically be set to expire 1 year from the current date.

Step 3: Use your API key to authenticate with cheqd Studio APIs

Navigate to the "APIs" tab and copy/paste your API key into the API key box towards the top of your page. This will enable you to authenticate with the cheqd Studio APIs, allowing users to use cheqd Studio APIs within their existing Billing Plan and usage limits.

Step 4: Start using cheqd

Get started with our tutorials for cheqd Studio functionality.

Users may exhaust their usage limits in their cheqd Studio billing plan, but may want to continue using the Studio before their usage limits refresh. Therefore, users can manually top up their account with CHEQ tokens to use any APIs that involve a ledger-write, e.g:

1. Creating, Updating or Deactivating DIDs

2. Creating unencrypted or encrypted Status Lists

3. Creating Trust Registries

4. Creating other DID-Linked Resources

Step 1: Locate your cheqd address (for CHEQ)

The following API can be used to fetch the new account information:

• customer_id is used as an identifier for the particular customer using cheqd Studio. It is generated as a sub-field of the JWT token used in the authorization header.

• cheqd_account is used to pay for identity transactions on either testnet or mainnet. A cheqd account is automatically generated when a new customer_id is generated.

Step 2: Adding CHEQ tokens to your account

If you exceed the usage limits in your cheqd Studio billing plan but want to continue using ledger-based functionality before your limits reset, you can manually top up your account using CHEQ tokens.

If you need to add CHEQ tokens to your cheqd Studio cheqd_account, there are a few steps you need to follow:

Once you have successfully created an account and have topped up your CHEQ tokens, you are ready to get started!

Step 3: Continue using cheqd

Get started with our tutorials for cheqd Studio functionality.

Run as standalone application using Docker Compose

If you want to run the application without any external databases or dependent services, we provide a Docker Compose file to spin up a standalone service.

docker compose -f docker/no-external-db/docker-compose-no-db.yml up --detach

This standalone service uses an in-memory database with no persistence, and therefore is recommended only if you're managing key/secret storage separately.

The no-db.env file in the same folder contains all the environment variables necessary to configure the service. (See section Configuration above.)

Run with external Key Management System (KMS) and/or authentication service using Docker Compose

Construct the postgres URL and configure the env variables mentioned above.

Spinning up a Docker container from the is as simple as the command below:

Configure PostgreSQL database

Configure the environment variables in the :

1. POSTGRES_USER: Username for Postgres database

2. POSTGRES_PASSWORD: Password for Postgres database

3. POSTGRES_MULTIPLE_DATABASES

Then, make the Postgres initialisation scripts executable:

Start LogTo service

Configure the environment variables in the with the settings described in section above.

Then, run the LogTo service to configure the LogTo application API resources, applications, sign-in experiences, roles etc using Docker Compose:

Configuring LogTo is outside the scope of this guide, and we recommend reading to familiarise yourself.

Start credential-service app

Configure the environment variables in the with the settings described in section above. Depending on whether you are using external Veramo KMS only, LogTo only, or both you will need to have previously provisioned these services as there are environment variables in this file that originate from Postgres/LogTo.

Then, start the service using Docker Compose:

Running app or LogTo migrations

When upgrading either the external Veramo KMS or LogTo, you might need to run migrations for the underlying databases.

You can run just the migration scripts using defined in the Compose file.

For example, to run cheqd Studio app migrations on an existing Postgres database (for external Veramo KMS):

Or to run LogTo migrations on an existing Postgres database:

Build using Docker

To build your own image using Docker, use the provided.

Release 7: Manage and verify Credentials (07/11/2025)

Features

• Credential history Updates and Credential Details

• verify Credentials: both JWT and JSON-LD using file uploads and simple paste.

Bug Fixes

• Add expiry status in Credential Details Page

• error handling for jsonld credential verification

• minor ui bugs and test provider

Release 6: Issue Credential and support external providers (21/10/2025)

Features

• Add Download Credential & Supported Providers env

• Add Credential issuance using cheqd Studio

• Support for JWT and JSON-LD credentials

• Begin integration of dock issuance & credential history

Bug Fixes

• Add email validation in credenitals

• Adjusted responsiveness and min-max widths + more conservative resolution parallelisation limit

• Augmented state handling + interactive management

• Client-side favourable DID state management + table sorting

Performance Improvements

• Integrate did metadata api

Release 5: Optimisations and State management improvement (12/09/2025)

Features

• Display Resource Versions & UI improvements

Bug Fixes

• Apply member filters in server

• Create resource operation

• Improved state management & fixes in list operations

• Replace Buffer with Uint8arrays

Release 4: Add support for Organizations and Agents (09/09/2025)

Features

• Update Service section to support did name, type fields

• Add organizations and agents as default options for identifiers

Bug Fixes

• Url validations & Create DID form fixes

Release 3: Add support for Trust Ecosystems (03/09/2025)

Features

• Support Trust ecosystems in UI, including accreditations for members in the ecosystem

• Add authorization for specific schemas for members of ecosystems

Bug Fixes

• Release versioning + v1.7.1 beta

Release 2: Add DID-Linked Resources in UI (21/08/2025)

Features

• Add create Resource underneath DIDs in UI

• Optimize data rendering in create-resource

• Add new Settings Tabs

• User menu changes

Bug Fixes

• nav bar update

• Remove usdc prices

Release 1: Add new dashboard for cheqd Studio metrics (13/08/2025)

Features

• Add features for Dashboard and Api access in portal

• Add create DID option in UI

• Improve UI for managing API keys

Get Started

cheqd Trust Registries can be designed and built by companies that create AI agents, and verified by users of AI agents. Select your user type below to begin:

What are Trust Registries for AI Agents?

Trust Registries play a critical role in establishing trust for AI Agents. Acting as authoritative databases, they can verify the AI Agent is accredited and authorized to carry out certain actions, ensuring transparency and accountability.

Here’s how they support the AI ecosystem:

• Accreditation of AI Agents: Trust Registries maintain verified records of AI agents, ensuring that they are accredited by trusted organisations or ecosystems. Through accreditations, these trust registries validate that AI agents are legitimate and scope the permissions under which the AI agent can operate within.

• Transparency: Trust Registries enable users and organisations to query and verify the origins and accreditations of AI systems they engage with. By providing a publicly accessible record of trusted AI agents, Trust Registries empower stakeholders to assess the credibility and history of an AI system before utilising it. This enhances confidence in the system, especially when the AI’s decisions impact sensitive areas like personal data or legal outcomes.

• Governance

cheqd has developed a robust Trust Registry solution, enabling users to establish hierarchical chains of trust, with each registry entry being DID-resolvable for enhanced transparency and security.

Capabilities of cheqd's Trust Registries for AI Agents

cheqd’s Agentic Trust combine and build upon tried and tested capabilities, already deployed at scale:

• Integrations with popular AI/ML tooling, such as MCP servers for easing how AI agents can interface with decentralised identity.

• Work with our SaaS (cheqd Studio) or Software Development Kits (SDKs) depending on your desired level of control versus simplicity.

• SDKs in multiple software languages to suit preferences / skillsets.

Components of cheqd's AI Trust Registry Solution

Authorities can author trust registries and issue identifiers to agents using:

• cheqd studio (SaaS APIs) for easy and quick integration with no deployment requirements

• SDKs for more control and tighter integration

Agent frameworks, deployments or end-users can use:

• Model Context Protocol (MCP) to surface responses directly to users via the agent, including a /who_is command which has the agent verify itself.

• Hosted TRAIN APIs to verify Agent accreditations.

• SDKs to hold & proof credentials, including verifying signatures.

Establishing a Trust Hierarchy

cheqd's Trust Registry model is predicated on the notion of a trust hierarchy, which is conceptually very similar to traditional Public Key Infrastructure (PKI). Specifically, the model relies on a Root of Trust from which trusted relationships can be established.

In our model for AI Agents, each organisation in the trust hierarchy is able to issue Verifiable Accreditations to other entities, conveying a set of permissions or scopes that determine what the recipient entity is permitted to do.

The following diagram shows an example of how an AI Agent Creator can accredit two AI Agents lower in the hierarchy:

Through this type of relationship, an AI Agent can prove that it is accredited by an AI Agent Creator through presenting the Verifiable Accreditation, which is stored on the cheqd blockchain.

Similarly, an AI Agent creator can prove that it is also trustworthy, demonstrating that it is a real actor rather than a fraudulent actor. In the diagram below, a Governance Authority (such as an accreditation body for AI Agent Creators) can accredit AI Agent Creators directly.

Therefore, relying parties can query the accreditations of AI Agents all the way back to a Root of Trust.

Use cases for AI Agent Trust registries

Below are a series of use cases to which this solution architecture can be applied:

Learn more about cheqd's Trust Registry model

Read through some of our guides below to getting setup with trust registries on cheqd:

Building a Trust Registry for your AI Agent is split into two core flows that are distinct, but also contain some overlapping dependencies:

✅ Get Started

Get started with the setup of your AI Agent Trust Registry using the guides below:

Learn more about cheqd's Trust Registry model

Read through some of our guides below to getting setup with trust registries on cheqd:

Users are able to build AI Agent Trust Registries using our cheqd Studio APIs. The following steps will enable organisations, governance authorities, auditors and AI Agents to establish permissions, rules and hierarchy between each other.

Step 1: Set up your cheqd Studio account

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

Step 2: Create a Root DID

The first step for any trust registry is a Root DID, which acts as a trust anchor for the chain of trust below. This DID should be for the highest level of trust in your ecosystem, such as a governance authority, a managing company or an auditor.

Step 3: Design Schemas for your Ecosystem

When you accredit an AI Agent or Organisation that builds AI Agents, you need to do so for a particular purpose. These purposes are defined in schemas, containing the fields that MUST or MAY be present in an accreditation or credential.

We have created some template schemas that we suggest you use within your trust registry!

3.1 Verifiable Attestation

This is a schema for a Verifiable Credential issued to your AI Agent from a Trusted Issuer. The Issuer attests to features of the AI Agent, hence we call it a Verifiable Attestation.

This schema can be always retrieved from the cheqd ledger at:

3.2 Verifiable Accreditation

This is a schema for a Verifiable Credential between two DIDs, to accredit the DIDs for specific purposes. The accreditedFor section of the Accreditation can be modified with specific schemas for AI Agents.

This schema can be always retrieved from the cheqd ledger at:

3.3 Custom Schemas

Builders can create custom schemas for their AI Agents, or for the accreditations between different organisations in their ecosystems. This is achieved through editing the accreditedFor section of a Verifiable Attestation above.

For example, the following schema shows how the configuration of an AI Agent can be represented within a schema:

Step 4: Publish your schemas to cheqd as DID-Linked Resources

With the Root DID you created in Step 2, you can create links to your schemas, storing them on-chain in a resolvable format.

You can follow the tutorial here to publish your schemas as DID-Linked Resources. Generally we use the resourceType of JSONSchemaValidator2020 for JSON schemas written to the ledger.

This will store the schemas securely on the cheqd Network, where they can be fetched using DID URLs.

Step 5: Issue a Root Authorization for the Trust Chain

The Root Authorization in trust registries on cheqd is called a rootAuthorizationForTrustChain. This authorization contains information about the governance framework the AI Agents will operate in, and signifies to trust registry resolvers that they have reached the intended Root.

Authorizations are issued between two DIDs (which may be the same). As such, if you are managing the entire ecosystem, you may need to create multiple DIDs for different roles in the ecosystem. Otherwise, you need to be aware of the DIDs of the organisations you are seeking to authorize.

Generally, the Root Authorization also contains the schemas and types of credentials that will be issued below in the trust chain.

5.1 Verifiable Authorization for Trust Chain

Using POST

Use the following request format:

You can use the API below to make this transaction, using the parameter 'authorize'.

Step 6: Issue your next Accreditation

Depending on how many layers deep you want your trust registry, you now need to issue an accreditationToAccredit or an accreditationToAttest. In essence, you need to decide whether you want to accredit a subordinate entity to accredit other organisations (creating a deeper trust chain), or accredit a subordinate entity to issue Credentials to your AI Agent.

6.1 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.

6.2 Verifiable Accreditation to Attest

If you just want to accredit the subordinate DID to issue credentials to your AI Agent, use a 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.

Core Trust Registry Setup Complete!

Great! Now you have set up the core functionality for your trust registry. Next you will want to issue a Verifiable Attestation from the "trusted issuer" in the Trust Registry to an AI Agent:

Once you have created your Trust Registry for the accreditation and authorization of the organisations in your ecosystem, you can issue a credential to your AI Agent.

Step 1: Create DID for AI Agent

Each AI Agent must have its own DID to securely receive and manage credentials and accreditations. This identification allows the AI Agent to cryptographically control these credentials and accreditations.

Step 2: Choose Schema for Credential

As described in , you should have already designed and published schemas for your AI Agent ecosystem.

You must decide which schema to use for the credential you are issuing to the AI Agent. You should make sure that you, as an issuer, are accreditedToAttest for the specific credential schema you want to use.

Step 3: Compile Credential Request

To ensure the AI Agent's credentials are demonstrably verifiable to a root of trust, certain steps are essential in the credential issuance process.

An example of the request format is below:

The table below breaks down what components are required and why they are needed:

Step 4: Issue Verifiable Credential to AI Agent

Issue the compiled credential using the cheqd studio API enpoint below:

(Optional) Step 5: Publish Credential Response as a DID-Linked Resource

The Issuer, after issuing the credential to the AI Agent, may publish the response (the fully formatted verifiable credential) as a DID-Linked Resource.

The response format should look like the following example, including a proof (signed by the issuer).

You can follow the tutorial below to publish your issued credential as a DID-Linked Resource. Generally we suggest the resourceType of VerifiableAttestation for credentials issued to AI Agents.

This will store the schemas securely on the cheqd Network, where they can be fetched using DID URLs.

Step 5: Provision Verifiable Credential into AI Agent using MCP server

To complete the setup of your AI Agent trust registry and its associated credential, the final step is to provision this credential directly into the AI Agent's wallet using our MCP Server. Follow the tutorial below to finalize your setup!

This is an advanced guide for those who want to integrate AI Agents with the Cheqd Network to create DIDs, Issue Verifiable Credentials and store Verifiable Credentials.

Overview

The Cheqd MCP Server is a specialised implementation of the Model Context Protocol (MCP) that integrates with the cheqd network to provide secure decentralised identity management capabilities for AI applications. Built on the powerful combination of MCP's standardised context protocol and cheqd's robust identity infrastructure, this server enables AI agents to perform sophisticated identity operations while maintaining security, privacy, and verifiability.

Our MCP server is designed as a modular toolkit that can be easily integrated with existing AI workflows, particularly through Claude Desktop, Cursor, and other MCP-compatible client applications.

Benefits of using MCP with cheqd

• Enhanced AI Trust and Verification: Enable AI agents to create, resolve, and verify decentralised identities, establishing a foundation of trust for AI interactions.

• Verifiable Credential Management: Simplify the issuance, verification, and management of verifiable credentials through standardised tools.

• Decentralised Identity Operations: Leverage cheqd's blockchain infrastructure for creating and managing DIDs with cryptographic security.

Integration with Credo Toolkit

The server includes deep integration with the Credo Toolkit (), which provides a comprehensive set of tools for interacting with the cheqd network through the OpenWalletFoundation's Credo-TS framework. This integration enables:

• DID Management: Create, update, resolve, and deactivate DIDs on the cheqd network.

• Resource Operations: Create and resolve DID-linked resources.

• Schema Management: Define and retrieve credential schemas for standardised credential formats.

The Credo Toolkit abstracts the complexity of these operations, presenting them as simple, well-documented MCP tools that can be invoked by AI agents with appropriate permissions. By leveraging the Credo Toolkit integration, the MCP server provides comprehensive tools for managing the full lifecycle of decentralised identifiers (DIDs) and verifiable credentials on the cheqd network.

Target Use Cases and Scenarios

The Cheqd MCP Server is particularly well-suited for scenarios requiring trusted AI interactions with verifiable identity information:

• AI-Assisted Identity Verification: Enable AI agents to verify user identities through cryptographically secured credentials.

• Credential Issuance Workflows: Streamline the creation and issuance of verifiable credentials through AI-guided processes.

• Trusted Data Exchange: Facilitate secure sharing of verified data between organisations using AI intermediaries.

Getting Started

Prerequisites

• An MCP Compatible Desktop based AI Agent. We have tested with .

• Working understanding of cheqd network: Understanding of DID operations and verifiable credentials.

• Node.js 20 or higher (if running using npx).

Quick Start: Use the Remote MCP Server

The simplest way to get started with MCP and Trust Registry verification is to use our hosted remote MCP server.

Configuration

• Open your Claude Desktop configuration file:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

• Save the file and restart Claude Desktop.

• You should now see the Trust Registry verification tools available in Claude Desktop/ Cursor.

Alternative: Local Installation (For Developers)

If you prefer to run the MCP server locally, with more control on the configuration and environment variables, you can run locally using docker.

1. Get the code

Get the docker-compose.yaml specially designed for Claude Desktop:

2. Create Configuration File

Update your local env.example file with the required environment variables:

Replace your-testnet-mnemonic with a valid mnemonic for the cheqd testnet. You can generate one using the cheqd CLI or get one from the cheqd faucet.

Server Configuration Options

Credo Tool Configuration Options

3. Update Claude Config

Add the following configuration to your claude_desktop_config.json or .cursor/mcp.json

4. Restart Claude Desktop

When successfully started, the MCP tools will be available.

Using the MCP with Trust Registry

Once configured, you can interact with the Trust Registry through Claude by:

1. Using the verify-trust-registry tool to verify credentials against the Trust Registry

2. Running a verification check for a cheqd DID or credential

For detailed usage examples, refer to our .

Next Steps

Now that you have the Cheqd MCP Server running, you can:

• Explore the available tools for DID management and credential operations

• Create your first verifiable credential using the provided tools

• Set up a complete identity verification workflow

⚠️ Before you begin...

Make sure you have configured the MCP Client as per the setup instructions.

After the MCP server is running and Claude Desktop (or any MCP Client) is connected, you can ask the agent to create a DID just by typing:

Hello agent, can you create a DID on cheqd testnet?

What is happening under the hood?

In the background, Claude is communicating with our MCP Server which relays a request to one of our SDKs, . Using Credo, the AI Agent creates itself a DID that conforms to the .

As per our instructions on issuing a verifiable credential to your AI Agent, you can now use the Agent's DID as the subjectDID to create an accreditation for the agent using Cheqd Studio. The response from Step 4 will include a JWT token in the proof section.

Copy the JWT token and ask Claude Desktop (or any your choice of MCP Client) to accept the credential as follows:

Can you accept the credential from this JWT token "eyJhbGciOiJFZ....."

Claude/Client should use the import-credential tool to add this credential to it's wallet as shown below:

What is happening under the hood?

In the background, Claude is communicating with our MCP Server which relays a request to one of our SDKs, . Using Credo, the AI Agent imports a Credential into the identity wallet associated with itself.

We have built additional functionality into the MCP Server for other use cases, including:

Follow these instructions to Issue a new Credential from your MCP Client (e.g. Claude Desktop) using the MCP Toolkit.

⚠️ Before you begin...

Make sure you have configured the MCP Client as per the setup instructions.

Step 1: Start your Holder Agent

Our contains "demo" profile, which includes a Holder ACA-py Agent setup. Start the Holder Agent with the following command

Step 2: Create Connection between Holder and Claude Desktop.

Although, either agents can start the connection, in this tutorial we will start the invite from Holder.

Open the Holder API at or use Postman, to create a new connection request. Copy the invitation_url from the response.

Parameters and Request Body

For automated acceptance, pass the following parameters:

A simple request body is below:

Step 3: Claude Desktop accepts the invitation

Go to Claude Desktop, and accept the connection by pasting the invitation_url value.

Step 4: Ask Claude to issue a Credential

Now you can ask Claude Desktop to issue a Credential Offer to the connection. Claude will interpret the message automatically and do all the steps necessary to issue a Credential Offer.

For this tutorial, we asked Claude to create a credential offer with score as 80 and subject as Mathematics.

When all the steps are completed, a Credential Offer will be sent to Holder agent.

Step 5: Holder accepts and stores the Credential.

The rest of the steps are from the Holder to accept the credential offer and store the credential. This can be achieved by the following API Calls from the Holder API at or Postman.

Parameters

Filter on "offer-received" state

Copy and save the cred_ex_id from the response and pass that in the next request to Accept the Offer.

Now, store the received Credential into the Holder wallet.

Follow these instructions to Verify a Credential from your MCP Client (e.g. Claude Desktop) using the MCP Toolkit.

⚠️ Before you begin...

Make sure you have configured the MCP Client as per the setup instructions and issued a Credential from the same MCP Client.

Step 1: Create Connection between Holder and Claude Desktop.

If the connection was disrupted, between the Holder and Claude Desktop.

Step 2: Ask Claude to issue a Proof Request

Ask Claude to issue a proof request with some conditions based on the attributes of your credential.

For this tutorial, we asked Claude to generate a proof request with score > 50.

Step 3: Holder checks Request and sends Proof

The next steps are at the Holder Agent side to accept the proof request and send the response. It can be simulated by running the following APIs in sequence from the Holder API at or Postman.

Parameters

To narrow down the latest proof request, pass the following parameters

Copy and save the pres_ex_id and the proof request by_format.pres_request.anoncreds from the response.

Fetch the relevant credentials and then create a proof response. Send the proof response by calling the below API.

Request Body

For this tutorial, as the credential is AnonCreds, we are sending an AnonCreds proof in the body. The values will be based on the presentation request and the credentials retrieved in the previous two steps.

Step 4: Ask Claude to validate the Presentation Response

Finally, you can ask Claude to check the status of the Proof Request with the following prompt.

"Can you check the status of the proof request?"

Claude should get the latest status and summarise if the verification result was true or false.

⚠️ Before you begin...

Make sure you have configured the MCP Client as per the setup instructions.

To validate your AI Agent, you can simply use the whois prompt provided by the Cheqd MCP Server.

Then Click "Send" button without writing any other prompt:

You can also use /<mcp-server-name>:whois if using a CLI client:

The response should be similar to below. Claude/Client should use list-credentials to get the latest credentials from Agent's wallet, and then use verify-trust-registry tool to verify the credential.

Then present a summary of the credential:

Learn more about what's happening under the hood:

Under the hood, the MCP Server is using our trust registry validation engine called TRAIN to recursively verify the issuer of the credential, up to a root of trust.

Read more about our Decentralized Trust Chain (DTC) approach and how TRAIN works below:

A Decentralized Identifier "DID" is a globally unique identifier that does not require a centralized registration authority because it is registered with distributed ledger technology or other form of decentralized network.

What options do I have for creating DIDs on cheqd?

There are many different ways to create DIDs on cheqd, with options for easy integration (e.g. cheqd Studio) and more bespoke integrations (e.g. Credo, ACA-Py and Veramo). Below are a list of SDK options for creating cheqd DIDs.

Get started with cheqd Studio

The easiest way to start creating DIDs is with our product cheqd Studio, allowing users to build and create did:cheqd DIDs using REST APIs.

Partner SaaS support

cheqd DIDs are also supported in a range of SaaS offerings from cheqd partners, making it possible to use did:cheqd across different platforms:

Read up on our DID Method

DIDs created on cheqd use the did:cheqd DID Method. This is fully defined below, as well as the associated ledger-write fees:

In cheqd Studio, you can easily create and publish a did:cheqd DID to the cheqd testnet or mainnet, anchoring it on-ledger with associated public keys and metadata. This DID can then be used to:

• Sign and issue verifiable credentials as an 'issuer'.

• Establish a trusted identity on cheqd for entities like organisations, digital products or AI Agents.

• Serve as the parent identifier for DID-Linked Resources (e.g. status lists, trust registries).

This tutorial walks through the process of creating an Issuer DID using cheqd Studio's API or interface, including how to configure your keys, DID Document, and optional service endpoints.

🔐 Once registered, the DID becomes publicly resolvable and forms the cryptographic foundation of your identity as an issuer in decentralized ecosystems.

Step 1: Set up your account

Make sure you have set up your account with cheqd Studio and have generated an API key to authenticate with our APIs, using our guides below:

Step 2: Create a DID and associated DID Document

Using the /did/create API, users have two options for creating a did:cheqd DID and associated DID Document on-ledger:

1. Filling out a simple form using the application/x-www-url-form-encoded or application/json option within an API client of your choice.

2. Compiling a full DID Document body yourself using the application/json option, using already created identity keys, within an API client of your choice.

Option 1. Choose from a few variables and we will compile the DID for you

This is the easiest way to create DIDs on cheqd and is recommended for users who are not overly familiar with compiling DID Documents.

Using application/x-www-url-form-encoded

Using the application/x-www-url-form-encoded option, users are able to choose between the following variables to compile your DID:

From this request, cheqd Studio will automatically create and publish a DID and associated DID Document to the ledger and return it as a response.

Using application/json

Alternatively, you can use the application/json option and pass only a few specific inputs, for example:

Or, if you have that you want to use, you can reference the created key ID, kid, in the request:

Using the application/json option, users are able to choose between the following variables to compile your DID:

Option 2. Publish a fully compiled DID Document body yourself

Instead of generating a DID Document using simple parameters, you can create a fully formatted DID Document yourself. Before, submitting a manually created DID, you will need to have to input the key material into the DID document.

Step 1: Create a new keypair

Use the to generate a new keypair within the Credential Service key management store. Copy the publicKeyHex.

Step 2 (option 1): Utilise the DID Document template helper

To simplify this process of formatting a DID Document using your own keys, we've created a . Simply paste in your publicKeyHex and choose the variables to compile your DID Document template.

Step 3: Paste the response

Within the /did/create JSON payload, paste the response of your DID Document template, with your own signing keys.

Request format:

Step 2 (option 2) Use application/json options

Alternatively, you can use the application/json request format below.

You can use the kid created from Step 1 within the options section, and then compile the remainder of tour DID Document.

Step 3: Hit execute on the API

Hit execute on the API below to create your did:cheqd DID and associated DID Document.

List DIDs associated with your account

After creating a DID or multiple DIDs, users can list all the created DIDs associated with their account. Using the /did/list API.

Alternatives

Below are a list of alternatives for creating cheqd DIDs.

In decentralized identity systems, all actors—whether Issuers, Holders, or Verifiers—require cryptographic keys to prove control over a Decentralized Identifier (DID) and to sign or verify interactions (e.g. credential issuance or presentation).

This tutorial guides you through generating a key pair that can be used to:

• ✅ Create a new DID (e.g. did:cheqd or did:key)

• ✅ Import into cheqd Studio for identity operations

• ✅ Use directly in SDKs or agent frameworks that support key-based identity

Why Identity Keys Matter

DIDs are built on public-private key cryptography. The public key is embedded in or referenced by the DID Document, while the private key remains securely held by the actor controlling the identity.

Without keys, you can’t:

• Create a DID

• Authenticate or prove control of an identity

• Sign or verify credentials and presentations

• Rotate or deactivate identifiers

Step 1: Choose Your Key Type

cheqd Studio supports two cryptographic key types for identity operations:

✅ Choose Ed25519 for identity-specific use cases. Use secp256k1 if you need compatibility with blockchain-based tooling, wallets, or ecosystems that already rely on this curve.

Step 2: Hit the API below

Use the API below to create and generate your new identity key pair of either type Ed25519 or secp256k1.

Step 3 (Alternative): Fetch Identity Key Details

If you've already generated a key pair using cheqd Studio and want to retrieve, reference or use it later, you can do so by referencing its Key ID (kid). This is useful for:

• Recovering key material generated earlier (e.g., to construct a DID or sign a credential)

• Working with shared or externally provisioned keys

• Avoiding duplicate key creation when managing identities programmatically

In decentralized identity systems, Holders (also referred to as Subjects) are the recipients of Verifiable Credentials—typically representing individuals, organisations, objects or devices.

To enable credential interactions such as receiving, presenting, and proving control over an identity, each Holder needs a unique cryptographic key pair. This key pair is used to create a Decentralized Identifier (DID) that represents their identity.

Use Cases for Holder Identity Keys

After generating a key pair using the API below, you can use it to:

• ✅ Generate a did:key identifier, an off-ledger, self-contained DID that is ideal for lightweight identity use cases

Why Use did:key for Holders?

The did:key method is a simple, deterministic DID method that embeds the Holder’s public key directly into the DID itself. It doesn’t require blockchain anchoring, making it:

• ⚡ Fast and lightweight – no on-ledger operations required

• 🔐 Privacy-preserving – good for ephemeral or throwaway identifiers

• 🧪 Useful for testing and interoperability – widely supported by wallets and agent frameworks

Many ecosystems choose did:key for wallet-based identities, while keeping issuer DIDs on-ledger (e.g. did:cheqd) to ensure resolvability and public trust.

Take a deeper look into the did:key specification here:

Get Started

To create a did:key DID, you can generate an identity key pair using the API below on cheqd Studio.

Resolving a DID means retrieving the associated DID Document, which contains the public keys, service endpoints, and metadata that describe and verify the identity. In decentralized identity systems, DID resolution is the foundation for:

• Verifying the authenticity of a DID

• Retrieving public keys for signature validation

• Accessing service endpoints (e.g. credential issuance APIs)

• Dereferencing to DID-Linked Resources (DLRs), such as status lists or trust registries.

A user is able to input a DID (string) as a request format and resolve the DID to fetch the associated DID Document, DID Resolution Metadata and DID Document metadata.

Users are able to update DID Documents for various reasons, such as to include a new section (such as service) or to rotate the verificationMethod or authentication keys within the DID Document.

With the /did/update API, users are able to input either:

1. The specific section(s) of the DID Document to be updated; or

2. The full updated DID Document body.

Example Request formats

Update Service Section

To update individual sections of the DID Document, users are able to pass only the section they would like to update. For example, users may often want to update the service section to add or change a serviceEndpoint:

The above request format will replace the service section of the existing DID Document with the new section. No extra information, such as the verificationMethod or authentication keys need to be passed with the request, because cheqd Studio custodies the keys on behalf of the user.

Rotate Keys

Users may regularly want to rotate the keys used to control the DID. Like with the service section above, users are able to pass the sections of the DID Document that include the rotated keys, usually contained within theverificationMethod and authentication sections.

The example above will rotate the keys that control the DID Document, updating the DID Document's verificationMethod and authentication sections accordingly.

Pass full updated DID Document body

Users may alternatively want to update the DID Document body in full, and pass the updated DID Document to the API. For example:

This method may be better for users wanting to update larger portions of the DID Document, or for having full visibility over the updated body.

Get started with the API below

Use the /did/update API below to pass your DID Document update as a request, using either the full body or a specific section.

Deactivating a DID marks it as no longer active or in use. This process updates the DID Document on the ledger to signal to verifiers, wallets, and other clients that the DID should no longer be trusted for interactions such as credential issuance or presentation.

Once a DID is deactivated:

• ✅ It cannot be updated again

• ❌ It cannot be reactivated

• 🛑 Applications resolving the DID will see its status marked as deactivated

When to Deactivate a DID

You should deactivate a DID when:

• The associated identity (e.g. organisation, credential issuer) is no longer operating

• The cryptographic keys have been compromised or rotated to a new DID

• You want to enforce a clean break with no further updates to the DID Document

Security Requirement

To prevent unauthorized deactivations, a deactivate request must be signed by all of the Verification Method keys listed in the current DID Document.

This ensures that only the current controller(s) of the DID can authorize its deactivation.

🔐 If even one required key is missing or invalid, the request will be rejected.

How to Deactivate a DID

Use the API below to submit a request to deactivate a did:cheqd DID.

Verifiable Credentials are a tamper-evident data format for asserting a set of claims about a subject. You can issue and verify Verifiable Credentials and Presentations without building complex integrations, using our simple cheqd Studio APIs.

What options do I have for issuing credentials anchored on cheqd?

There are many different ways to issue verifiable credentials signed by DIDs anchored on cheqd, with options for easy integration (e.g. cheqd Studio) and more bespoke integrations (e.g. Credo and Veramo). Below are a list of options for issuing credentials with cheqd underneath:

Partner SaaS products

You can use SaaS products from our partners to create best-in-class credential ecosystems, built on cheqd:

Get started with cheqd Studio

Make sure you've and created your first DID, then you can start to:

Supported Credential types

cheqd supports all four major digital Credential types via its selection of SDKs and APIs. Below you can learn about these Credential formats:

Credential Coverage

Depending on what type of credentials you want to use, choose the SDK that suits your tech stack:

Using the /credential/create API, it is possible to issue Verifiable Credentials, signed by a cheqd DID, in a few clicks or lines of code.

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 an Issuer DID

Before you can issue a Verifiable Credential, you need to create an Issuer DID which is used to sign the Credential payload. Use the API in the page below to create an Issuer DID:

(Optional) Step 3: Create a Subject DID

Again, before you issue a Verifiable Credential, you need to know to whom you are issuing it. If you need to create a Subject DID, you can take a look at the page here:

Step 4: Compile your Credential body

Within the JSON object of the API request, you will need to input the issuer and subject information, as well as the attributes which you want to issue in the Credential. You may also want to add additional fields such as a credentialSchema.

Users have two options for compiling the Credential bodies and issuing Verifiable Credentials:

1. Filling out a simple form using the application/x-www-url-form-encoded option within an API client of your choice.

2. Compiling a Credential body yourself using the application/json option within an API client of your choice.

Option 1. Choose from a few variables and we will compile the Credential body for you

This is the easiest way to issue Credentials and is recommended for users who are not overly familiar with compiling JSON objects.

Using the application/x-www-url-form-encoded option, users are able to choose between the following variables and options to issue Verifiable Credentials:

Additional options for specifying credentialStatus bitstring index

Below are a set of examples of alternative input parameters for users to specify the bitstring index of the issued Credential. The bitstring index is where exactly the issued credential will map to within the Status List. This should be noted and stored by the issuer to keep a record of which issued credentials are active, revoked or suspended:

Option 2. Publish a JSON payload yourself

Instead of using simple form variables, you can issue a Verifiable Credential using a JSON payload with the application/json option.

Request format

Below is an example of the request format for issuing a Verifiable Credential using a custom JSON payload, including some of the possible parameters:

Step 5: Issue a Credential using the API below

Execute the API below to issue a Verifiable Credential, signed by your issuer DID.

Alternatives

Below are a list of alternatives for using Credentials with cheqd support. Each offers a different set of protocols and underlying technical capabilities.

t

cheqd Studio currently is setup to work with the Verida Wallet. In 2025, we will be building compatibility with a full suite of other digital identity wallets.

Verida Wallet

Subject DID

On the "Profile" tab, you will see your did:vda address under the section "DID".

For example: "did:vda:testnet:0xD7477C4a75143Af16A967381d09650A533Bd0DD7"

Rendering credentials

Credentials stored with the will automatically be rendered in the Verida Wallet as a credential. This custom display includes:

1. A scannable QR code

2. The profile icon of the Verida DID that issued / signed the credential

3. A tick of approval indicating the credential has been verified

Once you have issued your credential and have a JWT as part of the credential proof, you can use the /credential/verify API to check that the JWT has not been tampered.

Step 1: Obtain Credential to Verify

To verify a Credential, you can either pass the full Credential body or the JWT proof. These can be either obtained from a Credential that has been issued or from a Verifiable Presentation presented to the user.

Step 2: Configure Verification Parameters

The user is able to set verification parameters to filter whether they want to verify certain aspects of a Credential, including:

Step 3: Pass the Credential to the API

Simply paste the JWT or the full credential body into the request field of the /credential/verify API, and the API will give you a response including the following verification policies:

1. Whether the Credential has been tampered

2. Whether the Credential has a valid issuance date

3. Whether the Credential has expired

A Verifiable Presentation is a collection of multiple Verifiable Credentials that are being presented by a holder to a verifier. In addition to checking whether the Credentials are untampered, Verifiable Presentation verification also checks that the holder subject DID is valid.

Step 1: Obtain Presentation to Verify

To verify a Credential, you can either pass the full VP-JWT string or a JSON object. These can be either obtained from a Verifiable Presentation presented to the user.

Step 2: Configure Verification Parameters

The user is able to set verification parameters to filter whether they want to verify certain aspects of a Presentation, including:

Step 3: Execute the API

Use the API below to verify a Presentation

Using cheqd's innovative DID-Linked Resource module, cheqd is able to support decentralized and scalable Verifiable Credential revocation and suspension. Using this API, the user is able to choose whether they would like to publish the revocation status to the cheqd ledger or elsewhere.

Step 1: Locate the Credential Body or JWT to be revoked

It is best practice for issuers to keep a record of the Credentials they have issued, including the "statusListIndex" of the Credentials. From this record system, issuers should be able to fetch either the full Credential Body or the JWT proof of the Credential they want to revoke.

Step 2: Decide whether to publish update to the ledger

When revoking a Credential, issuers can decide whether they want to publish an updated Status List on-ledger, with the revoked credential index updated in the bitstring. The parameter below can be changed to reflect this:

Step 3: Paste the Credential Body or JWT into the API

Paste the Credential Body or JWT into the API below and execute the API to revoke the Credential.

Credential Payments brings a significant evolution to the Verifiable Credentials landscape, allowing verifiers to directly pay issuers to unlock Credential Status information. Underneath the hood, we've engineered a robust and secure payment flow that streamlines the end-to-end payment process, with accuracy, speed, and cryptographic integrity.

Get started

Create encrypted Status Lists on-ledger, and pay to unlock the Access Control Conditions in CHEQ, using our cheqd Studio Payments APIs:

Learn more

Build your understanding of How Credential Payments work, including Access Control Conditions and how the model preserves privacy.

Alternatives

Below are a list of alternatives for using Credential Payments.

Build your knowledge about how cheqd's Credential Payment model works, including setting Access Control Conditions, and privacy-preserving payment flows.

Learn about Credential Payments

Get started

Using cheqd Studio, you can get started setting up your encrypted Status Lists with Access Control Conditions below:

Access Control Conditions

The Access Control Conditions outlined in this section establish a secure and structured framework for unlocking encrypted Status Lists and other DID-Linked Resource.

By employing a combination of Decentralised Identifiers (DIDs), DID-Linked Resources, encryption, and timed payment mechanisms, these access control conditions safeguard the integrity of the Resource, promote transparency, and control access to its data.

Request format: Payment conditions

For Credential Payments, the predominant Access Control Condition is a payment made from the Verifier of a Credential back to the Issuer.

The payment conditions outlined in the code snippet below define the payment requirements that must be met to access and interact with an encrypted Resource. These are written into a payload.json file when a create Status List transaction is made to the ledger ().

These conditions are established to ensure that authorized entities or users contribute a specified fee before gaining access to the Resource.

The parameters within the payment conditions are defined as follows:

By including these payment conditions in the Status List Payload, the ledger enforces a financial gate from verifiers seeking access. Additionally, the timelock mechanism adds a layer of time-based verification to the payment process. With the timelock, the payment can only be made in a specific time-interval from the latest block-time on the cheqd network. This ensures that historical payments cannot be used to meet the access control conditions, and fresh payments need to be made to access the Resource, helping to maintain the integrity of the payment and access process.

Response format: Access Control Conditions

If a Payment Condition is set upon creation of a Status List or other Resource, this will populate an Access Control Condition which is broadcasted across series of nodes to monitor whether the conditions have been met. The Access Control Condition uses query language to directly fetch information from the cheqd ledger, and is fully derived from the inputs made into the Payment Condition.

Each of these conditions are defined as follows:

Once an Access Control Condition has been set, the decryption keys are sharded between an array of nodes to prevent any single node or few malicious nodes from decrypting the data. This comprehensive setup ensures secure and controlled access to the specified resource based on specified criteria and events from the cheqd blockchain.

Get started

Using cheqd Studio, you can get started setting up your encrypted Status Lists with Access Control Conditions below:

Privacy considerations

cheqd's implementation of Credential Payments uses encrypted DID-Linked Resources (such as a Status Lists), with Payment Conditions required to unlock. Learn about cheqd's Access Control Condition logic below:

There are multiple areas within this flow where privacy needs to be maintained:

1. Status List construction: Credential information within Status List should not constitute .

2. Verifier pays Issuer: Any payment for decrypting a Status List should not be correlatable to a Holder presenting or sharing a Credential.

Status List construction

The , which cheqd encrypts with payment conditions, utilises to represent whether a Verifiable Credential has been suspended/revoked or not. A bitstring can be thought of as a long list of 1s and 0s, where, if the binary value of the position in the list is 1 (one), the is revoked, if it is 0 (zero) it is not revoked.

This works by tying each issued Credential with a position and index on the bitstring, so that a Verifier will be able to check the value within the Credential against the public bitstring to ascertain whether the Credential has been revoked or not, using a as well as a .

As part of the bitstring construction. there is a minimum bitstring length of 131,072 entries (16kb uncompressed). Moreover, in this string, the indexes that are not specified are randomised between revoked and unrevoked. This means that there will never be a bitstring with a single entry, or a small amount of entries.

Using this type of construction, the privacy of the Holder is protected through "Herd Privacy" because there is no way that a third party can externally view the Status List and can correlate indices with a particular individual's credential without direct knowledge of a Holders' credential index.

The expands on these privacy considerations.

Verifier pays Issuer

As part of the Access Control Condition setup, the Issuer can set a single payment fee for meeting the Access Control Conditions and decrypting a particular Status List.

Through setting a flat price for decryption, there is no price variation from checking one persons' credential status versus another's. This means that for a particular Status List, all payments on the network will be made at the same price.

Once again, this creates a layer of "Herd Privacy" for the Holder, since the Credential index itself is decoupled from the payment fee. Therefore. while transactions will be visible on the network, there will be no way for a third party to surveil the network or draw conclusions about who's Credential status is being checked.

If there was a variation in the price per Credential status check within the same status list, this would be more likely to become correlatable, alongside other information, back to a specific individual.

Continual improvement

We will continue to improve and assess the privacy considerations as we roll out Credential Payments. Some areas we believe there may be scope for privacy leakage are as follows:

• Holders' Credential index is doxxed: If a Holder has a particular Credential index doxxed, as well as a link to the status list, there may be scope to monitor the Credential Status of that individual, through a payment. However, third parties will not know when that Holder is using their Credentials.

• Issuer creates single entry Status List with specific unlock price: If an Issuer does not use our preset Status List length and creates their own resource with a single or few entries, they may provide a higher likelihood of doxxing when an individual uses their Credential. This is why cheqd, and the specification, has enforced a minimum Status List length.

To create an encrypted Verifiable Credential Status List with a set of Access Control Conditions, an Issuer will need to follow the steps below:

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 an Issuer DID

Before you can create an encrypted Status List for charging for Credentials, you need to create a DID which is used to link the Status List on-ledger. Use the API in the page below to create a DID:

Step 3: Select the encrypted Status List API

When , a user will have the following options:

For the purpose of this tutorial, we will assume the user is creating an encrypted Status List. For unencrypted Status Lists, .

Step 4: Create encrypted Status List

Using the /credential-status/create/encrypted API, users have two options for creating an encrypted Status List on-ledger:

1. Filling out a simple form using the application/x-www-url-form-encoded option on the Swagger UI.

2. Compiling a Status List payload yourself using the application/json option on the Swagger UI.

Option 1. Choose from a few variables and we will compile the Status List for you

This is the easiest way to create encrypted Status Lists on cheqd and is recommended for users who are not overly familiar with compiling JSON objects.

Using the application/x-www-url-form-encoded option on the Swagger UI, users are able to choose between the following variables and options to create an encrypted Status List on-ledger:

From this request, cheqd Studio will automatically create and publish an encrypted Status List to the ledger with set Payment Conditions required to be met to unlock.

Option 2. Publish a JSON payload yourself

Instead of using simple form variables, you can create an encrypted Status List using a JSON payload yourself using the application/json option on the Swagger UI.

Request format

An example of the JSON payload needed to be submitted is below:

The table below expands on some of the required parameters:

Step 5: Hit the API

Once the Issuer has populated the requisite information for the encrypted Status List request, they can use the API below to submit it to the ledger.

Encrypted Status List Response format

The following code snippet shows an example of an encrypted Status List response format, which will be published to the ledger:

Issuers are able to add encrypted Status Lists to the body of the Credential if they have previously created an Encrypted Status List on-ledger.

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 an Issuer DID

Before you can create an encrypted Status List for charging for Credentials, you need to create a DID which is used to link the Status List on-ledger. Use the API in the page below to create a DID:

Step 3: Create an Encrypted Status List

Follow the tutorial here to create an encrypted Status List with a set of Payment Conditions to unlock:

Step 4: Specify the encrypted Status List within Credential body

Follow the instructions within the /credential/create API below to format and issue a Verifiable Credential.

cheqd Studio supports payments for verifying Credential Status. This is an innovative feature that is also commonly known as cheqd's Payment Rails. Using the API in this tutorial, there are multiple ways for a Verifier to pay an Issuer to unlock and verify a Credential's status.

Step 1: Set up an account

A Verifier will need a cheqd Studio account to take advantage of the /credential-status/check API and easily use cheqd's Credential Payments. Make sure you are set up and are logged in, using our guide below:

Step 2: Set parameters for check

Using the /credential-status/check API, users have two options for checking whether a particular Credential index is revoked or suspended:

1. Filling out a simple form using the application/x-www-url-form-encoded option on the Swagger UI.

2. Compiling the JSON transaction yourself using the application/json option on the Swagger UI.

This is the easiest way to check whether a particular credential index is revoked or suspended.

Using the application/x-www-url-form-encoded option on the Swagger UI, users are able to choose between the following variables to compile your DID:

Option 1: Automatically paying an Issuer to unlock a Credential Status

To automatically make a payment to an Issuer in order to verify an encrypted Status List, there is an additional variable:

If there is sufficient CHEQ in the account of the Verifier, this will automatically make a payment to the Issuer and meet the Access Control Conditions.

Step 3: Hit the API

In the same action, the Credential Service will perform a verification check on the Credential Status and pay the issuer the fee specified in the Payment Conditions.

Response format

The response format below will indicate clearly whether the check is successful and whether the Credential index in question is revoked / suspended or not.

Option 2: Manually Paying an Issuer to unlock a Credential Status

If a Verifier does not want to automatically pay the Issuer using the API, they can choose to make a manual payment to unlock the Credential Status information to build a higher level of trust within the Credential presented to them.

Step 1: Locating Issuers' payment address and conditions

If a Verifier wants to unlock access to the Resource, to gain access to additional information about a Credential presented to them, such as the Credential Status, firstly, the Verifier will be presented Credential, including a link to the Status List within the "credentialStatus" section of the Credential body.

Through following the link in"credentialStatus" section of the Credential body. the The Verifier will be directed to an on-ledger Resource, identifiable through a DID URL, for example:

This on-ledger Resource will contain:

• An encrypted potion of the Resource, such as a Status List bitstring. identified by the "encodedList" property.

• Unencrypted metadata about the Resource, including the issuers' payment address "feePayerAddress" and and the Payment Conditions, "feePaymentAmount" and "intervalInSeconds".

This gives the verifier requisite information they need in order to pay the Issuer to unlock the Credential Status. You can learn more about Access Control Conditions below.

Step 2: Pay the Issuer

Using one of , Verifiers can make a payment of the amount specified in the "feePaymentAmount" to the "feePayerAddress".

This payment should be made in CHEQ.

Step 3: Hit the API

cheqd Studio will perform a verification check on the Credential Status and pay the issuer the fee specified in the Payment Conditions.

Response format

The response format below will indicate clearly whether the check is successful and whether the Credential index in question is revoked / suspended or not.

Alternatively, if Verifiers have made the payment manually they can also use the /credential/verify API in the tutorial below:

The /credential-status/update/encrypted API enables users to update the indices of a Status List or rotate the encryption keys. This may be useful for revoking Credentials in bulk, rather than submitting individual /credential/revoke requests.

When a new encrypted Status List resource is published, this will also encrypt the latest version with a new set of encryption keys. This may therefore be used to rotate encryption keys, even if the listed indices are kept the same.

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

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.

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

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

3. Credentials (Attestations)

• Assert facts (identity, qualifications, rights)

• Must include an AttestationPolicy that:

  • Links back to the issuer's accreditation

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 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

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:

Permissions

The credentialSubject of the accreditation, issued by issuer defines what the TAO is authorized to do — including which credential types they can issue and in which jurisdictions.

Field descriptions:

Policies

The Root TAO can also set polices known as the AccreditationPolicy within the termsOfUse section of the Verifiable Accreditation.

Whereby:

Example of fully formed Accreditation

The example below shows a Verifiable Accreditation that is issued by an rTAO to a TAO, specifying a schema under which the recipient is able to use for issuing their own accreditations.

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:

t

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