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

• 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

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

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.

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

Alternatives

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

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

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.

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

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

🙋 Find us elsewhere

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

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.

Once you have created your Trust Registry for the accreditation and authorisation 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

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:

{
  "issuerDid": "did:cheqd:testnet:0a35d559-00ff-41b6-81ad-f64faa522771", // DID of Trusted Issuer
  "subjectDid": "did:cheqd:testnet:a7e8bf7c-9d97-4b1e-a7bb-43a6754aafbf", // DID of AI Agent
  "attributes": {
      "aiAgentName": "ChatGPT-4 Turbo",
      "aiAgentVersion": "4.0-turbo",
      "model": "GPT-4 Turbo",
      "modelVersion": "4.0",
      "contextWindow": 128000,
      "temperature": 0.7,
      "topK": 40,
      "topP": 0.9,
      "maxTokens": 4096,
      "fineTuned": false,
      "fineTuningDetails": null,
      "safetyRating": "ISO 42001 Certified",
      "evaluationMetrics": [
        "BLEU-4",
        "ROUGE-L",
        "F1 Score: 92.5%"
      ],
      "certificationAuthority": "AI Ethics Board",
      "validUntil": "2026-03-28T12:00:00Z"
  },
  "type": [
    "VerifiableCredential",
    "VerifiableAttestation",
    "AIAgentAuthorisation"
  ],
  "format": "jwt",
  "credentialSchema": "https://resolver.cheqd.net/1.0/identifiers/did:cheqd:testnet:c6630f1e-9248-4af6-b7ac-5bcaf646f213?resourceName=AIAgentAuthorisation&resourceType=JSONSchemaValidator2020",
    "termsOfUse": {
      "type": "AttestationPolicy",
      "parentAccreditation": "did:cheqd:testnet:0a35d559-00ff-41b6-81ad-f64faa522771?resourceName=AccreditationToAttest&resourceType=VerifiableAccreditationToAttest",
      "rootAuthorisation": "did:cheqd:testnet:c6630f1e-9248-4af6-b7ac-5bcaf646f213?resourceName=OrganisationAuthorisationForAIAgents&resourceType=VerifiableAuthorisationForTrustChain"
    }
}

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

{
  "credentialSubject": {
    "aiAgentName": "ChatGPT-4 Turbo",
    "aiAgentVersion": "4.0-turbo",
    "model": "GPT-4 Turbo",
    "modelVersion": "4.0",
    "contextWindow": 128000,
    "temperature": 0.7,
    "topK": 40,
    "topP": 0.9,
    "maxTokens": 4096,
    "fineTuned": false,
    "fineTuningDetails": null,
    "safetyRating": "ISO 42001 Certified",
    "evaluationMetrics": [
      "BLEU-4",
      "ROUGE-L",
      "F1 Score: 92.5%"
    ],
    "certificationAuthority": "AI Ethics Board",
    "validUntil": "2026-03-28T12:00:00Z",
    "id": "did:cheqd:testnet:a7e8bf7c-9d97-4b1e-a7bb-43a6754aafbf"
  },
  "issuer": {
    "id": "did:cheqd:testnet:0a35d559-00ff-41b6-81ad-f64faa522771"
  },
  "type": [
    "VerifiableCredential",
    "VerifiableAttestation",
    "AIAgentAuthorisation"
  ],
  "termsOfUse": {
    "type": "AttestationPolicy",
    "parentAccreditation": "did:cheqd:testnet:0a35d559-00ff-41b6-81ad-f64faa522771?resourceName=AccreditationToAttest&resourceType=VerifiableAccreditationToAttest",
    "rootAuthorisation": "did:cheqd:testnet:c6630f1e-9248-4af6-b7ac-5bcaf646f213?resourceName=OrganisationAuthorisationForAIAgents&resourceType=VerifiableAuthorisationForTrustChain"
  },
  "credentialSchema": "https://resolver.cheqd.net/1.0/identifiers/did:cheqd:testnet:c6630f1e-9248-4af6-b7ac-5bcaf646f213?resourceName=AIAgentAuthorisation&resourceType=JSONSchemaValidator2020",
  "@context": [
    "https://www.w3.org/2018/credentials/v1"
  ],
  "issuanceDate": "2025-04-04T02:43:52.000Z",
  "proof": {
    "type": "JwtProof2020",
    "jwt": "eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9.eyJ2YyI6eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSJdLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiVmVyaWZpYWJsZUF0dGVzdGF0aW9uIiwiQUlBZ2VudEF1dGhvcmlzYXRpb24iXSwiY3JlZGVudGlhbFN1YmplY3QiOnsiYWlBZ2VudE5hbWUiOiJDaGF0R1BULTQgVHVyYm8iLCJhaUFnZW50VmVyc2lvbiI6IjQuMC10dXJibyIsIm1vZGVsIjoiR1BULTQgVHVyYm8iLCJtb2RlbFZlcnNpb24iOiI0LjAiLCJjb250ZXh0V2luZG93IjoxMjgwMDAsInRlbXBlcmF0dXJlIjowLjcsInRvcEsiOjQwLCJ0b3BQIjowLjksIm1heFRva2VucyI6NDA5NiwiZmluZVR1bmVkIjpmYWxzZSwiZmluZVR1bmluZ0RldGFpbHMiOm51bGwsInNhZmV0eVJhdGluZyI6IklTTyA0MjAwMSBDZXJ0aWZpZWQiLCJldmFsdWF0aW9uTWV0cmljcyI6WyJCTEVVLTQiLCJST1VHRS1MIiwiRjEgU2NvcmU6IDkyLjUlIl0sImNlcnRpZmljYXRpb25BdXRob3JpdHkiOiJBSSBFdGhpY3MgQm9hcmQiLCJ2YWxpZFVudGlsIjoiMjAyNi0wMy0yOFQxMjowMDowMFoifSwidGVybXNPZlVzZSI6eyJ0eXBlIjoiQXR0ZXN0YXRpb25Qb2xpY3kiLCJwYXJlbnRBY2NyZWRpdGF0aW9uIjoiZGlkOmNoZXFkOnRlc3RuZXQ6MGEzNWQ1NTktMDBmZi00MWI2LTgxYWQtZjY0ZmFhNTIyNzcxP3Jlc291cmNlTmFtZT1BY2NyZWRpdGF0aW9uVG9BdHRlc3QmcmVzb3VyY2VUeXBlPVZlcmlmaWFibGVBY2NyZWRpdGF0aW9uVG9BdHRlc3QiLCJyb290QXV0aG9yaXNhdGlvbiI6ImRpZDpjaGVxZDp0ZXN0bmV0OmM2NjMwZjFlLTkyNDgtNGFmNi1iN2FjLTViY2FmNjQ2ZjIxMz9yZXNvdXJjZU5hbWU9T3JnYW5pc2F0aW9uQXV0aG9yaXNhdGlvbkZvckFJQWdlbnRzJnJlc291cmNlVHlwZT1WZXJpZmlhYmxlQXV0aG9yaXNhdGlvbkZvclRydXN0Q2hhaW4ifSwiY3JlZGVudGlhbFNjaGVtYSI6Imh0dHBzOi8vcmVzb2x2ZXIuY2hlcWQubmV0LzEuMC9pZGVudGlmaWVycy9kaWQ6Y2hlcWQ6dGVzdG5ldDpjNjYzMGYxZS05MjQ4LTRhZjYtYjdhYy01YmNhZjY0NmYyMTM_cmVzb3VyY2VOYW1lPUFJQWdlbnRBdXRob3Jpc2F0aW9uJnJlc291cmNlVHlwZT1KU09OU2NoZW1hVmFsaWRhdG9yMjAyMCJ9LCJzdWIiOiJkaWQ6Y2hlcWQ6dGVzdG5ldDphN2U4YmY3Yy05ZDk3LTRiMWUtYTdiYi00M2E2NzU0YWFmYmYiLCJuYmYiOjE3NDM3MzQ2MzIsImlzcyI6ImRpZDpjaGVxZDp0ZXN0bmV0OjBhMzVkNTU5LTAwZmYtNDFiNi04MWFkLWY2NGZhYTUyMjc3MSJ9.z9xTp5dSMACTLhrAsO-RBjcmaJJvWHqD6_78FTjaOkBroAMS0f8NlvpIrC7CGojkzCv_T8M_VBexzXU9I8JKAg"
  }
}

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!

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 authorised 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: Trust Registries also serve as a governance tool, ensuring that AI developers and platforms are held accountable for their actions. By maintaining a registry of accredited AI systems, these registries can track the ongoing compliance of AI agents, making it easier to enforce ethical standards and regulatory requirements. In the event of a failure or harm caused by an AI agent, Trust Registries offer a clear point of reference for auditing and resolving accountability issues.

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.

• Industry-leading whilst interoperable capabilities. e.g. DIDs, DID-linked resources, and Trust Registries.

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:

Run as standalone application using Docker Compose

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.

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.

Configure PostgreSQL database

1. POSTGRES_USER: Username for Postgres database

2. POSTGRES_PASSWORD: Password for Postgres database

3. POSTGRES_MULTIPLE_DATABASES: Database names for multiple databases in the same cluster, e.g.: "app,logto". This sets up multiple databases in the same cluster, which can be used independently for External Veramo KMS or LogTo service.

Then, make the Postgres initialisation scripts executable:

chmod +x docker/with-external-db/pg-init-scripts/create-multiple-postgresql-databases.sh

Start LogTo service

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

docker compose -f docker/with-external-db/docker-compose-with-db.yml --profile logto up --detach

Start credential-service app

Then, start the service using Docker Compose:

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

Running app or LogTo migrations

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

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

docker compose -f docker/with-external-db/docker-compose-with-db.yml --profile app-setup up --detach

Or to run LogTo migrations on an existing Postgres database:

docker compose -f docker/with-external-db/docker-compose-with-db.yml --profile logto-setup up --detach

Build using Docker

docker build --file docker/Dockerfile --target runner . --tag credential-service:local

⚠️ Before you begin...

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?

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

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.

• Standardised AI Context: Utilise the Model Context Protocol to provide structured and verifiable context for AI interactions.

• Human-in-the-loop Security: MCP's approval-based tool execution model ensures humans maintain oversight of sensitive identity operations.

• Interoperable Integration: Seamlessly connect with existing identity ecosystems through the cheqd network and Credo Toolkit.

Integration with Credo Toolkit

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

• Connection Management: Establish secure DIDComm connections between identity holders and verifiers.

• Credential Issuance: Generate and issue verifiable credentials with cryptographic proofs.

• Verification Protocols: Implement zero-knowledge proof verification for enhanced privacy.

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.

• Identity-Aware AI Systems: Build AI applications that respect privacy and understand the provenance of identity information.

• Cross-Domain Verification: Enable verification of credentials across different systems and networks through the cheqd infrastructure.

• Self-Sovereign Identity Management: Support user control over identity information while enabling AI assistance for complex operations.

Getting Started

Prerequisites

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

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

• Docker Desktop (if running using docker). This is preferred when running the ACA-Py demo.

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

• Or, for Cursor .cursor/mcp.json

• Add the following configuration:

• 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

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

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

⚠️ Before you begin...

Step 1: Start your Holder Agent

// from mcp-toolkit folder 
cd docker
docker compose --profile demo up -d

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.

Parameters and Request Body

For automated acceptance, pass the following parameters:

A simple request body is below:

{
    "alias": "Faber",
    "handshake_protocols": ["https://didcomm.org/didexchange/1.1"],
    "use_public_did": false,
    "my_label": "Invitation to Faber"
}

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.

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.

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

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?

⚠️ Before you begin...

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:

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

⚠️ Before you begin...

Step 1: Create Connection between 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

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.

{
    "anoncreds": {
        "requested_attributes": <<requestedAttributes>>,
        "requested_predicates": <<requestedPredicates>>,
        "self_attested_attributes": {}
}

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.

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.

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:

Users are also able to deactivate DID Documents to prevent further updates and to provide client applications the relevant information that the DID Document is no longer actively used.

A /did/deactivate request must be signed by all of the Verification Method keys listed in the DID Document.

Issuers may want to create identity keypairs for multiple reasons, such as for signing payloads or for creating did:key DIDs.

There is also an option to fetch an identity keypair by inputting a Key ID (kid) as a request format.

Creating a Subject DID

cheqd Studio currently supports one types of subject DIDs:

• did:key

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

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

4. Whether the Credential Status is valid

To create a cheqd DID (did:cheqd) and associated DID Document there are two ways of building the payload for the request:

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

{
  "service": [
    {
      "id": "did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#service-1",
      "type": "LinkedDomains",
      "serviceEndpoint": [
        "https://example.com"
      ]
    }
  ]
}

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:

{
  "network": "testnet",
  "identifierFormatType": "uuid",
  "assertionMethod": false
}

Or, if you have created a keypair already that you want to use, you can reference that in the request:

{
  "network": "testnet",
  "identifierFormatType": "uuid",
  "assertionMethod": false,
  "options": {
    "key": "8255ddadd75695e01f3d98fcec8ccc7861a030b317d4326b0e48a4d579ddc43a", // Pass if you have created a key separately
    "verificationMethodType": "Ed25519VerificationKey2018"
  }
}

Option 2. Publish a fully compiled DID Document body yourself

Step 1: Create a new keypair

Step 2: Utilise the DID Document template helper

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:

{
  "didDocument": {
    "id": "did:cheqd:testnet:0ff9df5d-653b-4f77-a66c-0035abc34d63",
    "controller": [
      "did:cheqd:testnet:0ff9df5d-653b-4f77-a66c-0035abc34d63"
    ],
    "verificationMethod": [
      {
        "id": "did:cheqd:testnet:0ff9df5d-653b-4f77-a66c-0035abc34d63#key-1",
        "type": "JsonWebKey2020",
        "controller": "did:cheqd:testnet:0ff9df5d-653b-4f77-a66c-0035abc34d63",
        "publicKeyJwk": {
          "crv": "Ed25519",
          "kty": "OKP",
          "x": "BFSLOxwMJgpmWRtTUuo0JAvz6VXGp4WDDcN0dFfCQKo"
        }
      }
    ],
    "authentication": [
      "did:cheqd:testnet:0ff9df5d-653b-4f77-a66c-0035abc34d63#key-1"
    ]
  }
}

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.

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:

{
  "did": "did:cheqd:mainnet:71e24492-e62c-4e55-a581-007a6e36e881",
  "service": [
      {
        "id": "did:cheqd:mainnet:71e24492-e62c-4e55-a581-007a6e36e881#website",
        "type": "LinkedDomains",
        "serviceEndpoint": [
          "https:example.com"
        ]
      }
    ]
}

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.

{
  "did": "did:cheqd:mainnet:71e24492-e62c-4e55-a581-007a6e36e881",
  "verificationMethod": [
     {
       "id":"did:cheqd:mainnet:71e24492-e62c-4e55-a581-007a6e36e881",
       "type":"Ed25519VerificationKey2018",
       "controller":"did:cheqd:mainnet:71e24492-e62c-4e55-a581-007a6e36e881",
       "publicKeyBase58":"4sjwZ3VGWupJ26ytxjhU6LhjKiPrHV5reZbaNseyHtf8"
     }
  ],
  "authentication": [
       "did:cheqd:mainnet:71e24492-e62c-4e55-a581-007a6e36e881#key-1"
  ]
}

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:

{
  "didDocument": {
    "@context": [
      "https://www.w3.org/ns/did/v1",
      "https://w3id.org/security/suites/ed25519-2018/v1"
    ],
    "id": "did:cheqd:mainnet:71e24492-e62c-4e55-a581-007a6e36e881",
    "controller": [
      "did:cheqd:mainnet:71e24492-e62c-4e55-a581-007a6e36e881"
    ],
    "verificationMethod": [
      {
        "id": "did:cheqd:mainnet:71e24492-e62c-4e55-a581-007a6e36e881#key-1",
        "type": "Ed25519VerificationKey2018",
        "controller": "did:cheqd:mainnet:71e24492-e62c-4e55-a581-007a6e36e881",
        "publicKeyBase58": "4sjwZ3VGWupJ26ytxjhU6LhjKiPrHV5reZbaNseyHtf8"
      }
    ],
    "authentication": [
      "did:cheqd:mainnet:71e24492-e62c-4e55-a581-007a6e36e881#key-1"
    ],
    "service": [
      {
        "id": "did:cheqd:mainnet:71e24492-e62c-4e55-a581-007a6e36e881#website",
        "type": "LinkedDomains",
        "serviceEndpoint": [
          "https://example.com"
        ]
      }
    ]
  }
}

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.

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.

Users are also able to suspend Verifiable Credentials. The difference between revocation and suspension is that suspended Credentials may be unsuspended at a future date; whereas, revoked credentials are permanently revoked.

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

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

Step 2: Decide whether to publish update to the ledger

When suspending a Credential, issuers can decide whether they want to publish an updated Status List on-ledger, with the suspended 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 suspend the Credential.

Unsuspend (reinstate) Verifiable Credentials

If a Credential has been suspended, and an Issuer wants to unsuspend the Credential to make it once again valid, the Issuer can reinstate a suspended Credential.

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

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

Step 2: Decide whether to publish update to the ledger

When unsuspending or reinstating a Credential, issuers can decide whether they want to publish an updated Status List on-ledger, with the unsuspended 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 unsuspend the Credential.

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

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

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

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 Authorisation for the Trust Chain

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

Authorisations 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 authorise.

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

5.1 Verifiable Authorisation for Trust Chain

Use the following request format:

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

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: