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

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.

Users are able to issue Verifiable Accreditations to determine the validity of the accreditation, as well to traverse the trust chain to a root of trust.

Step 1: Issue Accreditation

Make sure you have already created at least one Verifiable Accreditation that you are able to query in the verify API.

Step 2: Use the Verify Accreditation API

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

⚠️ Before you begin...

Make sure you have configured the .

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?

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

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 or from a Verifiable Presentation presented to the user.

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

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.

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

Get Started

Understanding Token Status List

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

The /resource/search API allows users to search for specific entries of a Resource on the cheqd Network. For example, if there are multiple Resources associated with the same DID, the search functionality allows applications to make requests only to a specified Resource.

Follow these instructions to update a did:cheqd DID from ACA-Py Agent.

⚠️ Important...

Your wallet must have the key(s) which were generated when the DID was created, without them signing will fail.

Update DID

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.

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:

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.

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.

The /credential-status/search API allows users to search for specific entries of a Status List on the cheqd network. For example, if there are multiple Status Lists associated with the same DID, the search functionality allows applications to make requests only to a specified Status List.

Step 1: Set Status List Search Filters

Users are able to filter by:

Step 2: Hit the API

Execute the filters from Step 1 on the API below:

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.

The resolveResource method in the Credo cheqd module enables you to retrieve DID-Linked Resources stored on the cheqd network. These resources can be resolved in two primary ways:

Resolution Methods

1. Resolve by Resource ID (UUID)

Use the full DID + /resources/<resourceId> format to directly resolve a known resource.

This approach is ideal when you know the exact UUID of the resource.

2. Resolve by Resource Name and Type

You can also resolve a resource using a DID URL query format with resourceName and resourceType parameters:

This method is useful when:

• You want to resolve the latest version of a known logical resource

• You don’t have or track the UUID

3. Fetch the Resource Version Closest to a Specific Time

4. Alternative parameters

For a comprehensive list and detailed explanations of these parameters, refer to .

This guide explains how to deactivate a did:cheqd using a configured Credo Agent. Deactivating a DID marks it as no longer usable but does not remove it from the ledger — the DID can still be resolved and its deactivated state will be reflected in its metadata.

Prerequisites

Before deactivating a DID, ensure that:

• The Credo agent is configured with cheqd support

• The DID you are deactivating was created and is controlled by your agent

• You have access to the signing key used to authorize DID updates

Behavior of Deactivated DIDs

• Deactivated DIDs remain resolvable

• DID resolvers will indicate that the DID is deactivated

• The DID and its associated document become immutable and non-functional

Parameters

Example: Deactivate a cheqd DID

Notes

• The optional versionId parameter allows you to assign a custom version identifier to the deactivation transaction

• Once deactivated, the DID cannot be updated, reactivated, or used for issuing credentials

• You can still resolve the DID to verify its deactivated status via the deactivated: true metadata

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:

Follow these instructions to create a new DID from ACA-Py Agent and publish the associated DID Document on cheqd ledger.

⚠️ Before you begin...

Make sure you've correctly configured the cheqd plugin's agent settings for ACA-Py.

For wallet storage, utilise a Postgres database to ensure key persistence, enabling future updates to the DID.

Create DID

Populate the various optionsand featuresin the JSON request body and call the API to create the DID.

Request Body

These are the variables that can be passed in the Body:

List DIDs associated with your wallet

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

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

Register a Credential Definition

After registering a schema, a credential definition can be registered based on the schema. The credential definition, amongst more things, binds the schema to a specific issuer. Schemas can be reused between issuers, but a credential definition is specific to an issuer. In a credential definition revocation can also be specified. This section will not go in-depth about revocation.

The request body must contain the credential_definition object with the Issuer DID and the Schema ID created in the previous steps.

To enable revocation, the options must contain the revocation flag, and the size of the revocation registry. Also, ensure that a is configured for the issuer.

Parameters

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

Understanding Bitstring Status List

Step 1. Manually create your new Status List JWT/CWT and save the file locally

Create a JWT or CWT file with the updated indices and bits for the updated Status List.

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.

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:

Overview

Our objective in building DID-Linked Resources on cheqd is to improve the way resources are stored, referenced and retrieved for our partners and the broader SSI community, in line with the existing .

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.

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)

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.

To issue Verifiable Credentials, the issuer will have to first create a Schema and then a Credential Definition.

⚠️ Before you begin...

Make sure you've correctly configured .

Import a DID (optional)

Status Lists are generally sets of indices which can be used to mathematically derive whether an issued Credential has been revoked, suspended or is still valid. Status Lists are crucial for verifier applications to determine whether to accept a credential, presented by a holder.

What options do I have for creating status lists on cheqd?

There are many different ways to create status lists 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 creating cheqd DIDs.

SD-JWT Verifiable Credentials enable selective disclosure and unlinkability, combining the compact JWT format with privacy-preserving cryptographic techniques. They are optimized for privacy, mobile compatibility, and integration with modern identity standards.

In Credo, SD-JWT credentials are issued using OpenID for Verifiable Credential Issuance (OID4VCI) and presented using OpenID for Verifiable Presentations (OID4VP)—ensuring secure, interoperable credential exchange based on open standards.

✅ This approach is fully aligned with the EU Digital Identity Wallet standards and protocols, and the developing EU Architecture and Reference Framework (ARF).

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

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 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 as a payments processor and users will need to input their card information to initiate a billing plan.

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.

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

Bug Fixes

• Add email validation in credenitals

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

• Augmented state handling + interactive management

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

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

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

A Trusted Accreditation Organisation (TAO) can delegate authority to Trusted Issuers (TIs) by issuing them Verifiable Accreditations. These accreditations grant permission to issue specific types of Verifiable Attestations — such as diplomas, licences, or professional credentials — within the boundaries of a defined governance framework.

The Verifiable Accreditation should include:

Permissions

Root TAOs can set permissions under which TAOs must abide. This creates a level of codified governance for the trust ecosystem.

Field descriptions:

Policies

The termsOfUse field contains the AccreditationPolicy, which provides governance context by linking to both the TAO’s parent accreditation and the root authorization of the trust chain.

Whereby:

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:

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.

AnonCreds is a privacy-preserving Verifiable Credential format designed for selective disclosure, non-correlatable presentations, and revocation support. In Credo, AnonCreds is fully supported using the Issue Credential v1/v2 and Present Proof v1/v2 protocols.

Credo allows users to issue, hold, and verify AnonCreds credentials using a range of supported ledgers—including full integration with the cheqd network, a modern, scalable alternative to legacy Indy-based networks.

Get started

Issue, present and revoke AnonCreds signed by cheqd Decentralized Identifiers (DIDs), using the tutorials below:

Why Use AnonCreds?

AnonCreds credentials are purpose-built for high-assurance, privacy-respecting use cases that require:

• Selective disclosure of individual claims

• Zero-knowledge proofs

• Revocation support via AnonCreds Status Lists

AnonCreds + cheqd Support

Credo now supports did:cheqd for issuing AnonCreds credentials using the cheqd AnonCreds Object Method. This removes dependency on Indy-based networks while retaining the proven AnonCreds credential exchange flow.

With Credo + cheqd, you can:

• ✅ Register did:cheqd identifiers for use in credential issuance

• ✅ Publish Schemas and Credential Definitions as DID-Linked Resources

• ✅ Issue and verify AnonCreds credentials signed with did:cheqd

✅ This allows developers to migrate off the deprecated Sovrin network or other Indy networks without changing their existing flows or protocols.

Features Supported in Credo

AnonCreds Object Method

Take a deep dive into the cheqd AnonCreds Object Method below:

The createResource method from the Credo cheqd module allows you to create a DID-Linked Resource and publish it to the cheqd network under a did:cheqd identifier.

DID-Linked Resources are uniquely identified by a UUIDv4 resource ID and persistently attached to the DID on-chain. These resources can later be resolved by ID or query parameters (e.g., resourceName, resourceType).

Required Parameters

Example

💡 The id field must be a UUIDv4. You are responsible for generating and tracking this ID.

Recommendations

• Ensure the id is a UUIDv4, generated using a reliable UUID library (e.g., uuid in Node.js)

• Keep resourceName and resourceType descriptive but concise — they are used for resolution

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.

This guide walks you through how to update an existing cheqd DID using your configured Credo Agent. Updating a DID Document lets you add or modify keys, service endpoints, or other metadata associated with the DID.

Prerequisites

Before you begin, make sure:

• ✅ Your Credo agent is already configured with cheqd support

• ✅ You have write access to the DID (i.e., the key used for DID creation or a controller key)

• ✅ You know the DID you want to update and its current document state

How DID Updates Work

To update a did:cheqd, you must:

1. Fetch the current DID Document

2. Modify the relevant fields (e.g., add keys, update service endpoints)

3. Submit the updated DID Document using agent.dids.update(...)

Example: Add a New Service and Verification Method

Parameters Reference

DID-Linked Resources are digital files or data blobs that are permanently and verifiably linked to a specific did:cheqd identifier. Each resource is stored on the cheqd ledger and assigned a UUID, called the Resource ID, which acts as a unique, persistent reference.

Applications can retrieve these resources using either:

• A fully-qualified Resource ID (DID + /resources/<UUID>)

• Or a DID URL with query parameters like resourceName and resourceType

Common Use Cases

DID-Linked Resources enable storage of a wide variety of DID-associated metadata, including:

• Trust Registry entries

• Status Lists (e.g. credential revocation)

• Logos and brand assets

• Governance and policy documents

Get started

Alternatives

Below are a list of SDK alternatives for creating cheqd DID-Linked Resources.

Verifiable Credentials signed by a did:cheqd can be securely presented using the AnonCreds proof format and the Present Proof Protocol v2 within the Credo framework. This enables trust-minimised, selective disclosure of credential data between a Holder and a Verifier.

Prerequisites

Before presenting a credential:

• A Verifiable Credential must have been issued and accepted by the Holder

• A Credo Agent is running for both the Verifier and the Holder

• A DIDComm connection exists between Holder and Verifier (via OOB or another method)

Step 1: Create a Connection with Holder

Use any supported method to create a connection with the Holder. Automated is recommended. You can follow the same steps as described in .

Step 2: Send Proof Request

After connection is established, the Verifier can send a proof request to the Holder.

Step 3: Holder sends Presentation Proof

Holder can get the stored credentials from own wallet and format a proof to send to the Verifier.

When we want to send a proof, we have to listen to incoming proof requests and handle accordingly. In this example we do not have any user interaction, but is likely that your application would have a user-interface which would display the request.

What’s Happening Behind the Scenes?

• The Verifier sends a proof request with specific attributes and credential requirements

• The Holder uses locally stored credentials to generate a selective disclosure proof

• The proof is signed using AnonCreds and returned to the Verifier over DIDComm

Next Steps

For more tutorials and examples, visit .

Using the /credential-status/check API, users are able to query specific Credential indices within a Status List to ascertain whether the Credential is revoked, suspended or currently valid.

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

Credo provides full support for working with Verifiable Credentials (VCs) and Verifiable Presentations (VPs), based on the standards defined by the W3C and the Aries RFCs.

JSON-LD Verifiable Credentials follow the , enabling decentralized, semantically rich, and interoperable credential exchange.

In Credo, you can issue, verify, and present JSON-LD credentials over DIDComm v2, using the Issue Credential v2 and Present Proof v2 protocols—alongside support for Linked Data Proofs and various signature suites.

Get Started

Using AnonCreds and the Issue Credential v2 Protocol, you can issue Verifiable Credentials signed by a did:cheqd identifier with just a few lines of code. This guide walks through the full flow using the Credo Agent.

Prerequisites

Before you begin, make sure you have:

Verifiable Credentials signed by a did:cheqd can be securely presented using the Dif proof format and the Present Proof Protocol v2 within the Credo framework. This enables trust-minimised, selective disclosure of credential data between a Holder and a Verifier.

Prerequisites

Before presenting a credential:

Aries Cloud Agent Python (ACA-Py) is a powerful and extensible agent framework for building Verifiable Credential (VC) ecosystems. Built on the Aries RFCs and aligned with the Trust Over IP stack, ACA-Py operates at Layer 2 (Credential Exchange) and Layer 3 (Peer-to-Peer Communication).

As a project under the Open Wallet Foundation, ACA-Py supports dynamic extensions via runtime-loaded plugins, enabling flexible integration into enterprise and SSI platforms.

Using the /resource/create API, users are able to create custom DID-Linked Resources, including:

1. Schemas

2. Credential Definitions

This tutorial shows you how to create a cheqd DID using your configured Credo Agent, and how to publish the associated DID Document to the cheqd ledger.

⚠️ Prerequisites

Before you begin:

Using the OpenID4VC module, you can receive and present a OpenID compatible SD-JWT Credentials signed by a did:cheqd identifier. This guide walks through the flow of presentation using the Credo Agent.

Prerequisites

Before you being, ensure you have:

Using the OpenID4VC module, you can verify OpenID compatible SD-JWT Credentials signed by a did:cheqd identifier. This guide walks through the flow of verification using the Credo Agent.

Prerequisites

Before you being, ensure you have: