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

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

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

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

What is happening under the hood?

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

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

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

• Verifying the authenticity of a DID

• Retrieving public keys for signature validation

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

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

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

⚠️ 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?

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

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

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.

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

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.

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

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.

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.

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.

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

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

Get started

Understanding Bitstring Status List

The Bitstring Status List supported in cheqd Studio utilise 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.

Figure 1: Graphic showing the Bitstring Status List bitstring

Each issued Credential correlates with a position and index on the bitstring, so that a verifier will be able to correlate 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 .

Where is the StatusList usually published?

The issuer keeps a bitstring list of all Verifiable Credentials it has issued. The Status List is usually published by the issuer in the format of its own Verifiable Credential. This Verifiable Credential is generally hosted publicly on a centralised server or domain to enable third-party read-access.

Where does cheqd store the Status List?

cheqd stores each Status List and subsequent entries on-ledger as versions. This has notable benefits, including the provenance, legitimacy and security of the Status List. For a full list of benefits, see .

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 .

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.

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.

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

Get Started

Understanding Token Status List

Token Status List is a specification from the Internet Engineering Task Force, using JSON or CBOR encoded sets of bits and wrapping these as either a JSON Web Tokens (JWTs) or CBOR Web Tokens (CWTs), to comprise a full status list.

The .

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

To update an existing DID, you must pass the did id and the complete didDocumentin the request body. The main field that is updated using this method os the service object of the 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.

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)

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 .

⚠️ Before you begin...

Make sure you have configured the .

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

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:

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.

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 for ACA-Py.

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

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.

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.

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

Introduction

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

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

Get started

Features

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

Understanding the different modes and client choices

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

Option 1: Custodied by cheqd (Custodian Mode)

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

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

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

User optionality and toggles:

Within Custodian mode, we also enable clients to toggle

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

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

Architecture

Under the hood, cheqd Studio leverages our for its identity functionality. Check out our to understand how cheqd Studio fits together with our other Open Source packages.

Alternative: Use an SDK

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

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.

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:

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

2. Compiling a DID Document body yourself using the application/json option on the Swagger UI.

Option 1. Choose from a few variables

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

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

Make Fee Payment

To automatically make a payment to an Issuer in order to verify an encrypted Status List, follow the tutorial here:

Option 2. Publish a JSON Payload

Instead of using simple parameters, users can submit a JSON payload to the same effect using the application/json option on the Swagger UI. For example:

Step 2: Execute the API request

Execute the API request using the API below:

Privacy considerations

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

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

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

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

Status List construction

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

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

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

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

The expands on these privacy considerations.

Verifier pays Issuer

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

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

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

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

Continual improvement

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

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

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

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.

Get started with cheqd Studio

There are two predominant Status List formats supported in cheqd Studio. Please choose a Status List type below to get started.

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

Get Started

Issue and present SD-JWT credentials in Credo using the tutorials below:

Why Use SD-JWT?

SD-JWT credentials are ideal for ecosystems that require:

• Privacy-preserving credential exchange Reveal only the claims you choose—no more, no less

• Unlinkability across presentations Each presentation is cryptographically unique, preventing correlation by relying parties

• Optimized for mobile and constrained environments Compact format, ideal for mobile wallets and low-bandwidth scenarios

Extensibility for cheqd Functionality

While SD-JWT focuses on minimal disclosure, it can integrate cheqd-native functionality through linked references:

🔗 DID-Linked Resources Reference schemas, legal terms, or trust frameworks hosted on the cheqd ledger via out-of-band metadata Use credential_metadata or presentation definitions to point to these resources

🏛️ Trust Registries Issuers can prove authorisation by referencing cheqd-based trust registries—linked via DID-Linked Resources or OpenID Federation metadata

🚫 Status Lists (Revocation) Revocation is supported via cheqd-compatible Bitstring Status Lists These can be referenced externally without compromising SD-JWT’s privacy guarantees

📦 These integrations maintain SD-JWT’s compact, privacy-first design while adding verifiability and governance via cheqd infrastructure.

Features Supported in Credo

Supported DID Methods

Credo supports SD-JWT credential issuance and key binding using:

• did:key

• did:web

• did:cheqd

Supported Protocols

• Issuance: OID4VCI (OpenID for Verifiable Credential Issuance)

• Presentation: OID4VP (OpenID for Verifiable Presentations)

Trust Registries enable a Relying Party to determine the authenticity and authorization of a legal entity within a digital credential ecosystem. Trust Registries are crucial to establish for production environments, because they allow relying parties to make informed decisions on whether to trust the credentials they receive.

cheqd has pioneered a industry-leading trust registry solution, allowing users to create hierarchical chains of trust, with each trust registry entry being DID-Resolvable.

cheqd’s Trust Registry Model

cheqd offers an industry-leading, decentralized trust registry solution, allowing issuers to be accredited through hierarchical chains of trust called Decentralized Trust Chains (DTCs). Each entry in the registry is:

• ✅ DID-resolvable

• 📜 Cryptographically signed and verifiable

• 🌍 Publicly discoverable using DID-Linked Resources

Learn about cheqd Trust Registries

cheqd enables you to build Decentralized Trust Chains — a powerful model for structuring trust in credential ecosystems without relying on centralized authorities or static whitelists.

Using cheqd’s flexible DID and DID-Linked Resource architecture, trust is established through a chain of cryptographically verifiable credentials:

• Root Authorizations define the governance framework and root of trust

• Verifiable Accreditations delegate authority to trusted organisations

• 🏷Verifiable Attestations (Credentials) are issued by accredited entities to end users

Each link in the chain is publicly resolvable, tamper-evident, and policy-bound — forming a complete lineage of trust from issuer to root authority.

Before you begin building, we recommend familiarising yourself with how Decentralized Trust Chains work and the role of each credential type:

Get started

Use cheqd Studio APIs to define, issue, and publish trust registry entries:

• Create and manage Root Authorizations, Accreditations, and Attestations

• Resolve trust chains in real time using standard DID resolution

• Anchor trust registries on-chain while keeping business logic off-chain

For verification, use TRAIN to validate the trust registry to determine whether an issuer DID is accredited, and what they are accredited for — by traversing the full trust chain to its root.

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.

Save this file locally and call it something like statusListTokenUPDATED.json

Step 2: Encode the updated file

Prepare a file with resource and encode it into base64, base64url or hex. On Unix systems, you can use the following command input:

Expected output:

Step 3: Set the same Resource Name and Type

To create a new version you must use the same "name" and "type" for your resource, and ensure that the new Token Status List resource is being created underneath the same DID as your initial DID. You will also need to be logged into the same cheqd Studio account that you used to create the initial Token Status List to have access to the keys to sign the update.

For Token Status Lists, the "type" MUST be: "TokenStatusList".

For example:

Step 4: Populate the request inputs and hit the API

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

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:

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

1. Schemas

2. Credential Definitions

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

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:

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.

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:

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)

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.

To ensure a Verifiable Credential (VC) is not only technically valid but also issued by an authorized and trusted party, it must include metadata that links back to its origin in a trust registry.

This is done using the termsOfUse property, where the Trusted Issuer includes an AttestationPolicy referencing:

• The Verifiable Accreditation that granted them permission

• The Root Authorization that anchors the governance framework

Why reference a trust registry?

Including a reference to a trust registry enables verifiers to:

• Validate that the issuer is accredited to issue this type of credential.

• Trace the credential’s trust lineage back to a Root Trusted Accreditation Organisation (rTAO).

• Enforce domain-specific governance or regulatory policies.

Structure of termsOfUse

The termsOfUse field uses the AttestationPolicy type and typically includes:

Example: Credential referencing its trust registry via AttestationPolicy

What this enables

This embedded trust policy allows verifiers to:

• Look up the parent accreditation and root authorization.

• Confirm that the issuer was permitted to issue the attestation type.

• Automate or enforce policy-based trust decisions.

Validating Trust Chains Using TRAIN

Once a Verifiable Credential includes an AttestationPolicy referencing the trust registry, TRAIN (TRust mAnagement INfrastructure) can be used to automatically validate the issuer’s authority against a decentralized trust chain.

What does TRAIN do?

TRAIN is a trust validator that:

• Accepts a credential (or its metadata) as input.

• Resolves the issuer’s accreditation.

• Traverses the trust chain to the root authorization.

TRAIN Validation Input

Here’s a simplified example of the request body TRAIN accepts:

TRAIN Validation Output

TRAIN returns a response like this:

Why use TRAIN?

• Automates trust validation using standardized credential metadata.

• Provides clear trust decisions for wallets, agents, and verifiers.

• Enables integration with public DNS for added assurance of root DIDs.

Users are able to create Token Status List entries on-ledger, which may be used to represent whether a Verifiable Credential is active, inactive or suspended. This implementation on cheqd is a derivation from the core spec made by cheqd to support a more decentralised and resilient approach to storing Token Status Lists.

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

Before you can create a Status List, 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 your Status List JWT/CWT and save the file locally

Token Status Lists are JWT or CWT files that reference lists of bits formatted in JSON or CBOR.

Save this file locally and call it something like statusListToken.json

Step 4: Encode the file

Prepare a file with resource and encode it into base64, base64url or hex. On Unix systems, you can use the following command input:

Expected output:

Step 5: Set the resource name and type

DID-Linked Resources are grouped by having identical names and types. This means if you want to create a new version of the same Resource, you will need to specify the same name and type in the following request.

For Token Status Lists, the "type" MUST be: "TokenStatusList".

For example:

Step 6: Populate the request inputs and hit the API

Ensure that you link this Token Status List to the DID that you created in step 3. This will sign the resource with the same verification method keys in your DID Document, ensuring cryptographic integrity and Controllership of the Status List.

As a DID-Linked Resource, the Token Status List will have a fully resolvable DID URL which can be referenced within the body of Verifiable Credentials, and queried by verification policies to establish the status of the specific credential.

Step 7: Reference the Token Status List

Owing to the design of DID-Linked Resources, following the creation of the Token Status List, users are able to reference the specific version, or create a query to always fetch the latest version of the Token Status List.

Using a DID Resolver or the search DID endpoint, users can find the DID URL and unique resourceId of the Token Status List. The unique resourceId allows users to specify this exact version of the Token Status List.

In the DID Document Metadata, users should find "linkedResourceMetadata", like the following snippet:

Specific version of the Token Status List

Here, the "resourceURI" specifies the DID URL of the specific Token Status List that was created.

Latest version of the Token Status List

In order to reference the latest version of the Token Status List, the following construction needs to be used:

did:cheqd:<namespace>:<resourceCollectionId>?resourceName=<resourceName>&resourceType=<resourceType>

For example:

did:cheqd:testnet:0a5b94d0-a417-48ed-a6f5-4abc9e95888d?resourceName=DegreeCredentialStatus&resourceType=TokenStatusList

Token Status List at specific point in time

In order to reference the Token Status List at a particular point in time, the following construction needs to be used:

did:cheqd:<namespace>:<resourceCollectionId>?resourceName=<resourceName>&resourceType=<resourceType>&resourceVerionTime=<XMLDateTime>

For example:

did:cheqd:testnet:0a5b94d0-a417-48ed-a6f5-4abc9e95888d?resourceName=DegreeCredentialStatus&resourceType=TokenStatusList&resourceVersionTime=2023-02-22T06:58:18.61Z

"DID-Linked Resources" are identified with a did:cheqd Decentralized Identifier with a Universally Unique Identifier (UUID) that acts as a permanently-accessible link to fetch the resources from the cheqd ledger. We refer to this as the "resource ID". Through the "resource ID" or a set of DID URL query parameters, applications are able to persistently access a digital resource on the cheqd network.

Get started

Alternatives

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

Partner SaaS support

cheqd DID-Linked Resources are supported in SaaS offerings from cheqd partners, making it possible to use did:cheqd DLRs across different platforms:

DID-Linked Resource Write Pricing

Read up on our identity write pricing for cheqd Mainnet below:

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

Integrate with cheqd

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

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

What functionality does cheqd offer?

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

Industry Standard DID Support

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

Get started with cheqd Studio