Introduction

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

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

Get started

Features

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

Understanding the different modes and client choices

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

Option 1: Custodied by cheqd (Custodian Mode)

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

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

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

User optionality and toggles:

Within Custodian mode, we also enable clients to toggle

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

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

Architecture

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

Alternative: Use an SDK

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

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

Step 1: Get started with cheqd Studio

Head to our cheqd Studio and click Get Started.

Step 2: Create your account

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

• Email and password

• Google single sign-on

• Discord login

Click Sign In or Create Account to continue.

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

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

Step 4: Start using cheqd

Get started with our tutorials for cheqd Studio functionality.

Step 5: Select a Billing plan

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

⚠️ Before you begin...

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

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

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

What is happening under the hood?

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

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

✅ Get Started

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

Learn more about cheqd's Trust Registry model

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

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

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, Credo. Using Credo, the AI Agent imports a Credential into the identity wallet associated with itself.

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

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.

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.

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.

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.

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

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.

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.

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:

t

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:

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.

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.

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 the Credo agent with cheqd.

Import a DID (optional)

In order to register a schema and credential definition, a DID must be added to the agent first. This can be done by calling agent.dids.create(), but this does require an endorser DID to be present as the submitterDid. This is optional, if you have created a DID from the agent before as described here.

const seed = TypedArrayEncoder.fromString(`<seed>`) // Secret seed. Should be kept secure in production!
const cheqdDid = 'did:cheqd:testnet:d37eba59-513d-42d3-8f9f-d1df0548b675' // Cheqd DID to be imported

await agent.dids.import({
  did: cheqdDid,
  overwrite: true,
  privateKeys: [
    {
      privateKey: seed,
      keyType: KeyType.Ed25519,
    },
  ],
})

Register a Schema

When you have a registered (or imported) a DID on the network and in your wallet, you can register a schema. Registering a schema requires four fields: issuerId, name, version and attrNames. It is important to note that the issuerId must be the same as a DID in your wallet.

const schemaResult = await agent.modules.anoncreds.registerSchema({
  schema: {
    attrNames: ['name', 'degree', 'date'],
    issuerId: '<did>',
    name: 'Example Schema to register',
    version: '1.0.0',
  },
  options: {},
})

if (schemaResult.schemaState.state === 'failed') {
  throw new Error(`Error creating schema: ${schemaResult.schemaState.reason}`)
}

Parameters

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.

const credentialDefinitionResult = await agent.modules.anoncreds.registerCredentialDefinition({
  credentialDefinition: {
    tag: 'default',
    issuerId: '<did>',
    schemaId: schemaResult.schemaState.schemaId,
  },
  options: {
    supportRevocation: false,
  },
})

if (credentialDefinitionResult.credentialDefinitionState.state === 'failed') {
  throw new Error(
    `Error creating credential definition: ${credentialDefinitionResult.credentialDefinitionState.reason}`
  )
}

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 Tails Server is configured for the issuer.

Parameters

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

• Deactivation is permanent

Parameters

Example: Deactivate a cheqd DID

await agent.dids.deactivate({
  did: 'did:cheqd:testnet:b84817b8-43ee-4483-98c5-f03760816411',
  options: {
    versionId: '3.0', // Optional: for tracking version history or audit purposes
  },
})

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

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

• 🧍 Ideal for Holder/Subject identities – where the main role is to receive and present credentials rather than issue them

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.

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, create a new connection 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 http://localhost:4001/api/doc 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.

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

Step 4: Ask Claude to validate the Presentation Response

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

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

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

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

Step 1: Obtain Credential to Verify

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

Step 2: Configure Verification Parameters

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

Step 3: Pass the Credential to the API

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

1. Whether the Credential has been tampered

2. Whether the Credential has a valid issuance date

3. Whether the Credential has expired

4. Whether the Credential Status is valid

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

Step 1: Set up your account

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

Step 2: Create an Issuer DID

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

Step 3: Create an Encrypted Status List

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

Step 4: Specify the encrypted Status List within Credential body

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

cheqd Studio 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 credential schema 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

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 docker-compose file contains "demo" profile, which includes a Holder ACA-py Agent setup. Start the Holder Agent with the following command

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

Step 2: Create Connection between Holder and Claude Desktop.

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

Open the Holder API at http://localhost:4001/api/doc 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:

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

Step 3: Claude Desktop accepts the invitation

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

Step 4: Ask Claude to issue a Credential

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

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

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

Step 5: Holder accepts and stores the Credential.

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 http://localhost:4001/api/doc 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.

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

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

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

• ✅ Import into cheqd Studio for identity operations

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

Why Identity Keys Matter

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

Without keys, you can’t:

• Create a DID

• Authenticate or prove control of an identity

• Sign or verify credentials and presentations

• Rotate or deactivate identifiers

Step 1: Choose Your Key Type

cheqd Studio supports two cryptographic key types for identity operations:

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

Step 2: Hit the API below

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

Step 3 (Alternative): Fetch Identity Key Details

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

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

• Working with shared or externally provisioned keys

• Avoiding duplicate key creation when managing identities programmatically

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.

Get started

Understanding Bitstring Status List

The Bitstring Status List supported in cheqd Studio utilise bitstrings 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 verifiable credential 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 validate algorithm as well as a bitstring expansion algorithm.

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 DID-Linked Resource versions. This has notable benefits, including the provenance, legitimacy and security of the Status List. For a full list of benefits, see the context for creating DID-Linked Resources.

⚠️ Before you begin...

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

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

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

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

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

Then present a summary of the credential:

Learn more about what's happening under the hood:

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

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

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

Get started

Alternatives

Below are a list of alternatives for creating cheqd DIDs.

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.

{
  "alg": "ES256",
  "kid": "12",
  "typ": "statuslist+jwt"
}
.
{
  "exp": 2291720170,
  "iat": 1686920170,
  "iss": "https://example.com",
  "status_list": {
    "bits": 3,
    "lst": "eNrbuRgAAhcBXQHutdpRiBFREinSjQfeTpXmdQfwefegD"
  },
  "sub": "https://example.com/statuslists/1"
}

d28453a20126106e7374617475736c6973742b637774a1044231325860a502782168
747470733a2f2f6578616d706c652e636f6d2f7374617475736c697374732f310173
68747470733a2f2f6578616d706c652e636f6d061a648c5bea041a8898dfea19fffe
56a2646269747301636c73744a78dadbb918000217015d58400f2ca3772e10b09d5d
6ed56461f7cba1a816c6234072d1bb693db277048e5db5a4e64444492a9b781d6c7a
c9714db99cc7aadb3812ec90cab7794170bab5b473

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:

$ base64 -w 0 resource.json
<path-to-the-resource-file>

Expected output:

$ base64 -w 0 resource.json
HfSynOpmBrhgfYguING

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:

{
    "data": "HfSynOpmBrhgfYguING",
    "encoding": "base64url",
    "name": "DegreeCredentialStatus",
    "type": "TokenStatusList"
}

Step 4: Populate the request inputs and hit the API

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

• Credential definitions and revocation registries anchored on-ledger

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

• ✅ Enable revocation using AnonCreds Status List Definitions and Entries, also stored on-ledger as DID-Linked Resources

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

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 W3C DID Core standard.

Contents

Read the guides below to understand the context, rationale and design decisions involved in the DID-Linked Resource (DLR) implementation on cheqd.

Architecture for DID-Linked Resources

If you are interested in diving into the full architectural decisions for DID-Linked Resources, head to our ADR and the emerging W3C specification.

As a general architectural overview for DID-Linked Resources, see the diagram below:

Support for AnonCreds using DID-Linked Resources

One of the functions of DID-Linked Resources is enabling support for AnonCreds on cheqd, where previously these were tied into the Hyperledger Indy ecosystem. Take a look at our AnonCreds documentation here:

Follow these instructions to deactivate 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.

Deactivate DID

To deactivate an active DID, pass the didid in the request body, with any additional optionsthat you may have configured.

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.

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

Get started

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

Learn more

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

Alternatives

Below are a list of alternatives for using Credential Payments.

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.

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

• 🔗 Linked to governance frameworks

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

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

• If the resource data is sensitive or large, consider encoding as a base64 string

• Use version to manage changes to the resource over time

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.

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)

• Both agents are configured with:

  • @credo-ts/anoncreds

  • @credo-ts/didcomm

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

• The Verifier cryptographically validates the proof and the issuing DID (did:cheqd)

Next Steps

For more tutorials and examples, visit .

Run as standalone application using Docker Compose

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

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

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

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

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

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

Spinning up a Docker container from the pre-built cheqd Studio Docker image on Github 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: Database names for multiple databases in the same cluster, e.g.: "app,logto". This sets up multiple databases in the same cluster, which can be used independently for External Veramo KMS or LogTo service.

Then, make the Postgres initialisation scripts executable:

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

Start LogTo service

Configure the environment variables in the logto.env file 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:

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

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

Start credential-service app

Configure the environment variables in the with-db.env file 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:

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

Running app or LogTo migrations

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

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

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

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

Or to run LogTo migrations on an existing Postgres database:

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

Build using Docker

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

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

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.

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:

did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0

employmentCredentialRevocationList

10

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:

{
  "did": "string",
  "statusListName": "string",
  "index": 0,
  "makeFeePayment": false
}

Step 2: Execute the API request

Execute the API request using the API below:

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

• Credential Schemas and Definitions

Get started

Alternatives

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

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.

"credentialSubject": {
    "id": "did:cheqd:testnet:e66a9416-d03e-4ced-95e3-07af16e25bc5",
    "accreditedFor": [
      {
        "schemaId": "did:cheqd:testnet:8ea036da-f340-480d-8952-f5561ea1763c/resources/b10146d7-0d0f-41e0-8ee3-c76db64890be",
        "types": [
          "VerifiableCredential",
          "VerifiableAttestation",
          "DiplomaCredential"
        ],
        "limitJurisdiction": "https://publications.europa.eu/resource/authority/atu/FIN"
      }
    ]
  },

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 authorisation of the trust chain.

"termsOfUse": {
    "type": "AccreditationPolicy",
    "parentAccreditation": "did:cheqd:testnet:8ea036da-f340-480d-8952-f5561ea1763c/resources/18de60ec-bed1-42e5-980c-601c432bc60b",
    "rootAuthorisation": "did:cheqd:testnet:8ea036da-f340-480d-8952-f5561ea1763c/resources/18de60ec-bed1-42e5-980c-601c432bc60b"
  }

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:

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.

Credo enables users to issue, hold, present, and verify credentials in a secure and interoperable way using DIDComm messaging and OpenID for Verifiable Credential protocols. This functionality forms the foundation of any Self-Sovereign Identity (SSI) ecosystem.

Get started

Get started issuing and presenting credentials with your Credo agent, either with AnonCreds, JSON-LD or SD-JWT VC:

Get started

Credential Format Support

Credo supports multiple credential formats and exchange protocols out of the box, including:

✅ SD-JWT VC

• Alignment with the European Digital Identity Wallet initiative and standards.

• Selective disclosure baked in at credential-format level.

• Issuance and presentation support with OpenID4VCI and OpenID4VP.

✅ AnonCreds

• Ideal for privacy-preserving use cases that require zero-knowledge proofs, selective disclosure, and non-revocation proofs

• Backed by a credential definition and revocation registry stored on a supported ledger (e.g., cheqd, Indy)

• Common in enterprise and government deployments

✅ W3C Verifiable Credentials (JSON-LD)

• Standards-compliant with the W3C VC Data Model

• Extensible for cheqd DID-Linked Resources and Trust Registries

• Issuance and presentation over DIDComm v2.

• Suitable for web-native and mobile-first use cases

Alternatives

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

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:

• ✅ Ensure your Credo agent is correctly configured with the @credo-ts/cheqd module

• ✅ You’ve set up a cosmosPayerSeed for publishing to the cheqd network

• ✅ You're connected to the correct network (mainnet or testnet)

Method Overview

Credo supports two approaches to creating a DID:

Option 1 – Manually construct a full DID Document

Use when you want full control over the DID structure and already have key(s) in your wallet.

Option 2 – Auto-generate the DID Document

Use when you want Credo to create the DID Document from a key you specify in secret.

Create DID

Parameters​

1. method*: cheqd

2. secret

3. options*

4. didDocument

Option 1: Create a DID from a full DID Document

1. First, generate a key pair:

const key = await agent.wallet.createKey({
  keyType: KeyType.Ed25519,
})

const ed25519PublicKeyBase58 = key.publicKeyBase58

1. Use that key to construct and register the DID Document:

import { DidDocument } from '@credo-ts/core'

await agent.dids.create<CheqdDidCreateOptions>({
  method: 'cheqd',
  secret: {}, // No secret needed if key is already in wallet
  options: {
    network: 'testnet',
  },
  didDocument: new DidDocument({
    id: 'did:cheqd:testnet:92874297-d824-40ea-8ae5-364a1ec9237d',
    controller: ['did:cheqd:testnet:92874297-d824-40ea-8ae5-364a1ec9237d'],
    verificationMethod: [
      {
        id: 'did:cheqd:testnet:92874297-d824-40ea-8ae5-364a1ec9237d#key-1',
        type: 'Ed25519VerificationKey2018',
        controller: 'did:cheqd:testnet:92874297-d824-40ea-8ae5-364a1ec9237d',
        publicKeyBase58: ed25519PublicKeyBase58,
      },
    ],
    authentication: [
      'did:cheqd:testnet:92874297-d824-40ea-8ae5-364a1ec9237d#key-1',
    ],
  }),
})

📝 Make sure the publicKeyBase58 matches the key in your wallet. The DID will be written to the testnet unless you specify "mainnet" in options.network.

Option 2​

If you don’t want to manually build a DID Document, you can let Credo handle it based on your input key type and ID.

await agent.dids.create({
  method: 'cheqd',
  secret: {
    verificationMethod: {
      id: 'key-1', // Logical key name
      type: 'Ed25519VerificationKey2020', // Or another supported type
    },
  },
  options: {
    network: 'testnet',
    methodSpecificIdAlgo: 'uuid', // Optional: 'uuid' (default) or 'base58'
  },
})

🔐 Credo will generate the DID Document using the key referenced in secret and publish it to the network.

What’s Next?

Now that your DID is live on the cheqd network, try:

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

1. Schemas

2. Credential Definitions

3. Trust Registries

4. Status Lists

5. Logos associated with DIDs

6. Governance files

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 DID-Linked Resource, you need to create a "parent" DID which is used to link the Resource on-ledger. Use the API in the page below to create a DID:

Step 3. Create your Resource content and save the file locally

DID-Linked Resources can be any type of file or content that is below ~45kb in size.

For the purpose of an example, lets use an AnonCreds schema (JSON file) as the resource:

{
  "name": "degreeSchema",
  "version": "1.5.7",
  "attrNames": ["name", "age", "degree", "grade"]
 }

Save this file locally and call it something like resource.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:

$ base64 -w 0 resource.json
<path-to-the-resource-file>

Expected output:

$ base64 -w 0 resource.json
SGVsbG8sIHdvcmxk

Step 5: Set a consistent name and type

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.

Step 6: Populate the request inputs and hit the API

To ensure a Verifiable Credential (VC) is not only technically valid but also issued by an authorised 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 Authorisation 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 authorisation.

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

• Optionally checks DNS anchoring of the root DID for higher assurance.

• Returns a result that confirms if the issuer is trusted under the specified framework.

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.

• Compatible with all credentials that follow cheqd’s trust chain model.

"DID-Linked Resources" are identified with a with a 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:

What is TRAIN?

TRAIN (TRust mAnagement INfrastructure) is a framework, led by the team at the , for establishing and validating decentralized trust. It allows ecosystems to verify whether Verifiable Credentials (VCs) were issued by authorized and trustworthy entities through cryptographically linked trust chains.

TRAIN includes two core components:

• TRAIN Trust Validator (TTV): A service that validates the issuer of a Verifiable Credential by tracing Verifiable Accreditations up to a trusted root authority.

• TDZM (Trust-DNS Zone Manager): A DNS component that enables Root Trusted Accreditation Organisations (rTAOs) to publicly anchor their Decentralized Identifiers (DIDs) in DNS.

Together, these components allow for governance-aware, high-assurance validation of digital credentials without centralized trust registries.

How TDZM and the TRAIN Trust Validator Work Together

When combined, they allow you to:

• Establish a cryptographically linked trust hierarchy

• Publish root DIDs (rTAOs) in DNS

• Automatically validate credentials against published governance frameworks

• Support scalable, decentralized ecosystems without compromising on assurance

Step-by-Step: Setting Up Trust and Validation

1. Deploy Trust-DNS Zone Manager (TDZM)

Run the TDZM backend and UI using:

• Docker Compose (for testing or development)

• Helm Charts in Kubernetes (for production)

TDZM includes:

• A DNS nameserver to manage your trust zone

• A backend API and UI for managing records

• Optional OIDC authentication

2. Delegate DNS Control to TDZM

In your parent DNS zone (e.g. federation1.com):

• Add an NS record pointing your trust subdomain (e.g. trust.federation1.com) to TDZM

• Add an A record to resolve the nameserver’s domain to its IP

Example:

3. Anchor the rTAO DID in DNS

Use TDZM to publish a TXT or TLSA DNS record that links your rTAO’s DID to the trust domain.

Example:

This enables the TRAIN Trust Validator to resolve and verify the rTAO’s authenticity.

4. Build the Trust Chain

• Publish a Root Authorisation for Trust Chain from the rTAO

• Issue Verifiable Accreditations from rTAO → TAOs → Trusted Issuers

• Define governance rules and credential schema policies as needed

5. Use the TRAIN Trust Validator (TTV)

Send a JSON request to TTV with the credential’s issuer, type, accreditation path, and optional DNS anchors. TTV will:

• Traverse the Verifiable Accreditation chain

• Verify structural and policy compliance

• Optionally confirm the root via DNS lookups

• Return a structured verification result

Summary

By combining DNS-based assurance with credential-level verification, the TRAIN infrastructure provides a flexible and scalable solution for decentralized trust governance.

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:

• A registered did:cheqd for the Issuer.

• A and already created and published as DID-Linked Resources.

• A configured with:

  • @credo-ts/cheqd for DID operations and resource publishing.

  • @credo-ts/anoncreds for AnonCreds credential handling.

  • @credo-ts/didcomm for DIDComm messaging

• Two agents: an Issuer and a Holder (can be separate apps or run locally)

• Secure connectivity between agents using Out-of-Band (OOB) or a supported connection method.

Step 1: Create a Connection with Holder

Use any supported method to create a connection with the Holder of the credential. Automated is recommended.

1a: Issuer Creates Connection Invite

The Issuer agent will create a new connection invite for the Holder. This is needed to securely communicate between the Issuer and the Holder agents.

1b: Holder receives invitation

The above request will have an invitation in the response. Holder will have to copy that invitation and pass URL as invitationUrl in the following code:

Step 2: Prepare and Send Credential Offer

Generate a credential offer and send to the holder, informing them about the available credential and its attributes.

Step 3: Holder accepts credential offer

When we want to accept a credential, we have to listen to incoming credentials 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 credential. When receiving a credential offer you can get the values from credentialExchangeRecord.credentialAttributes.

Summary

Get Started with Credo

Credo is a TypeScript-based framework for building Self-Sovereign Identity (SSI) agents and services. It is designed for modularity, interoperability, and compliance with the European Architecture and Reference Framework (ARF).

Previously known as Aries Framework JavaScript, Credo has recently been rebranded and transitioned from the Hyperledger Foundation to the Open Wallet Foundation, reflecting its broader mission and growing community.

Credo has evolved into a more flexible and general-purpose SSI framework. A major milestone in this evolution is the full integration with — making Credo the first framework to support AnonCreds on non-Indy ledgers.

This integration showcases Credo’s expanding support for:

• Multiple credential formats

• Diverse DID methods

• Interoperable ledger technologies

Using Credo, developers can now issue Verifiable Credentials, create Credential Schemas, and define Credential Definitions using cheqd-native AnonCreds, enabled by the cheqd AnonCreds Object Method.

Key Features

Credo may be the right choice as it has the following benefits:

• TypeScript-native — strongly typed, developer-friendly, and production-ready

• Modular and extensible — use only what you need, plug in new components

• Cross-ledger compatibility — supports Indy, cheqd, and beyond

• Flexible credential support — AnonCreds, W3C JSON-LD, JWT

• Aligned with EU standards — interoperable with EU ARF and continuing to align with eIDAS 2.0 implementing acts

• Backed by the Open Wallet Foundation — with growing community adoption

Breaking New Ground: Credo + cheqd

Credo is now the first framework to support AnonCreds on non-Indy ledgers, thanks to a deep integration with . ACA-Py has since followed suit.

This includes:

• Issuance of Verifiable Credentials using cheqd DIDs

• Creation of Credential Schemas and Credential Definitions

• Support for the cheqd AnonCreds Object Method

• Native DID and resource support for did:cheqd

Get started

Get setup with your Credo agent and begin using cheqd's functionality below:

Supported Credential types

Credo supports the following Credential formats:

Watch our demo video

Enterprise Support for Credo

Below are a list of enterprise applications that leverage Credo with full did:cheqd support under the hood:

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.

DID and Credential Support

ACA-Py supports multiple credential formats and DID methods, including:

• AnonCreds

• W3C Verifiable Credentials (JSON-LD)

• DIDComm v1 & v2

• DID method plugins like did:peer, did:indy, and did:cheqd

ACA-Py + cheqd: Modern Verifiable Credential Issuance

ACA-Py now includes full support for the did:cheqd method, enabling seamless integration with the cheqd decentralized identity network. This allows developers to:

• Create and resolve did:cheqd identifiers

• Publish Credential Schemas and Credential Definitions to cheqd

• Issue and verify AnonCreds credentials using cheqd DIDs as signatures

• Issue and verify JSON-LD credentials using cheqd DIDs as signatures

• Replace legacy did:sov/Sovrin usage with a modern, scalable alternative

💡 AnonCreds on cheqd are enabled via the cheqd AnonCreds Object Method, maintaining compatibility with ACA-Py's credential exchange workflows.

Universal Registrar Integration

The cheqd plugin for ACA-Py supports dynamic DID registration via the Universal Registrar. This provides a streamlined interface for managing multiple DID methods.

Benefits of Using Universal Registrar:

• Unified DID Support Register multiple DID methods (e.g., did:cheqd, did:key, did:web) through a single unified API.

• Streamlined Setup Eliminate manual configuration—DIDs are created dynamically at runtime by calling the relevant driver.

• Interoperable by Design Easily switch or support multiple DID methods in the same ACA-Py deployment.

Get started

Get setup with your ACA-Py agent and begin using cheqd's functionality below:

Enterprise Support for ACA-Py

Below are a list of enterprise applications that leverage ACA-Py with full did:cheqd support under the hood:

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

• Both agents are configured with needed for JSON-LD Credential Proof.

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: Register Proof Event Listeners

Both agents need event listeners to handle the proof exchange protocol automatically.

Step 3: Send Proof Request

After the connection is established and event handlers registered, the Verifier can send a proof request to the Holder.

The Proof Acceptance and Presentation is handled automatically by the event listeners registered for both Verifier and Holder.

Next Steps

For more tutorials and examples, visit .

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:

• Basic knowledge of .

• .

Step 1: Configure the Holder Agent

Configure the holder with cheqd and OpenID4VC Modules

Step 2: Resolve and Accept Credential Offer

This method:

1. Resolves the offer.

2. Accepts it via pre-authorized code flow.

3. Selects a binding method—did:key (preferred) or JWK—for the SD-JWT, depending on issuer capabilities

Step 3: Store the Credentials

Step 4: Resolve and Accept Authorization Request

Once you have a credential in your wallet, you can present it by responding to a receive authorization request, which includes an OpenID4VP presentation request. This request can be generated either by the verifier module or an external OpenID4VC verifier. First, resolve the authorization request, then accept it to present the credential in your wallet.

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.

Get started

Alternatives

Below are a list of SDK alternatives 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).

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

• Standards-compliant Built on IETF SD-JWT, OID4VCI, and OID4VP specifications

• Interoperability with identity wallets Enables seamless interaction with both SSI wallets and federated identity providers supporting OpenID standards

• EU Wallet-ready Fully compatible with the EU Digital Identity Wallet and ARF requirements

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)

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