Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
NOTE: The tutorials below are only recommended to be used for testing purposes!
Using
cheqd-node
Cosmos CLI for real-world production environments is not recommended, since the identity keys are passed in raw form to the CLI. This is fine in development/testing usage, but is not recommend for mainnet.
Utilise our cheqd Cosmos CLI for identity for testing purposes, following the tutorials listed below:
There are plenty of other places you can go to get started creating cheqd DIDs. Simply pick the option which is best suited for your needs:
Create DIDs and DID Documents
Create W3C conformant DIDs and associated DID Documents.
Update and manage DIDs
Update and manage existing DIDs and DID Documents.
Query DIDs
Query and resolve existing DIDs to fetch DID Documents.
Deactivate DIDs
Deactivate existing DIDs and DID Documents.
Create DID-Linked Resources
Create digital resources associated and linked with DIDs.
Add new DID-Linked Resource to Collection
Create new versions of the same DID-Linked Resource within one Collection.
cheqd Studio
Our API product enables users to use cheqd's functionality with minimal complexity and easily integrate APIs into existing apps.
DID Registrar
Simple setup for building cheqd DIDs into existing applications using REST APIs, building into the Universal Registrar.
Veramo SDK Plugin
The Veramo SDK Plugin is an extension of the Veramo SDK, a JavaScript framework for Trusted Data, adding support for cheqd functionality.
Credo
Credo is an SDK which supports the European Architecture and Reference Framework (ARF) standards as well as AnonCreds with full cheqd support for DIDs.
Walt.id SSI Kit
Walt.id SSI Kit is an SDK that supports the European Architecture and Reference Framework (ARF) standards for identity, with full cheqd support.
An existing did:cheqd
entry created using any SDK/CLI. For development purposes, this can be done using the cheqd-node
Cosmos CLI.
NOTE: Use the cheqd DID Resolver for production-grade usage
Querying using the Cosmos CLI is useful for development purposes, but the DID Resolver is designed for programmatic usage. Production-grade SDKs such as Veramo SDK for cheqd also rely on the DID Resolver package.
The purpose of this document is to describe how an existing DID (and associated DIDDoc) can be deactivated using the cheqd-node
Cosmos CLI.
NOTE: The procedures below are only recommended for development purposes!
Using
cheqd-node
Cosmos CLI for real-world production usage is not recommended, since the identity keys are passed in raw form to the CLI. This is fine in development/testing usage, but is not recommend for mainnet.Developers are encouraged to use production-grade CLI tools such as Veramo SDK for cheqd or look at our developer guide on how to integrate custom applications.
Learn how to create a DID with cheqd Cosmos CLI
Query an existing DID/DIDDoc with cheqd Cosmos CLI
As in flow with creating DID-Document we need to compile payload.json
file with private key inside and pass it to the CLI. The resulting JSON in our example will look liks:
Send the updated DIDDoc to the ledger. This must be signed with the correct identity keys:
Payload_in_JSON
- previously compiled JSON.
--from
: Cosmos account key which will pay fees for the transaction to be written to ledger.
--node
: IP address or URL of node to send request to
--chain-id
: E.g., cheqd-testnet-6
--fees
: Set to 10000000000ncheq, which is the fixed fee for deactivating a DID
Note that each of cheqd's on-ledger identity transactions has a fixed fee, the pricing for cheqd DIDs and DID-Linked Resources can be found here. If your account has insufficient balance the transaction will fail.
The purpose of this document is to describe how an existing DID (and associated DIDDoc) can be updated using .
NOTE: The procedures below are only recommended for development purposes!
Using
cheqd-node
Cosmos CLI for real-world production usage is not recommended, since the identity keys are passed in raw form to the CLI. This is fine in development/testing usage, but is not recommend for mainnet.Developers are encouraged to use or look at .
Learn how to
with cheqd Cosmos CLI
Given this procedure below is intended for development/training purposes, we assume that the user stores their public/private keys safely during the DID creation process and has access to it.
Updating a DIDDoc requires the full updated DIDDoc to be sent. Only the updated/changed parts cannot be sent. This accounts for scenarios where the DIDDoc may have been updated on ledger, but the local copy is not synced with the latest changes.
Use a text editor like nano
to edit the body of the DIDDoc (the example below assumes it's saved in a file called payload.json
).
Send the updated DIDDoc to the ledger. This must be signed with the correct identity keys:
Payload_in_JSON
- previously compiled JSON.
--from
: Cosmos account key which will pay fees for the transaction to be written to ledger.
--node
: IP address or URL of node to send request to
--chain-id
: E.g., cheqd-testnet-6
--fees
: Set to 25000000000ncheq, which is the fixed fee for updating a DID
For example, we can and change the Service Endpoint from bar.example.com
to foo.example.com
:
As in flow with we need to compile payload.json
file with private key inside and pass it to the CLI. The result JSON in our example will look liks:
Note that each of cheqd's on-ledger identity transactions has a fixed fee, . If your account has insufficient balance the transaction will fail.
The purpose of this document is to outline how someone can create a Resource on the cheqd network using cheqd Cosmos CLI. The process that's followed is similar to what's described in the high-level Resource creation flow.
Install the latest stable cheqd-node CLI, either as a standalone binary or Docker container image.
Acquire test CHEQ tokens through our testnet faucet (if creating it on our testnet), or CHEQ tokens (if you plan on creating it on mainnet).
Note: If you already have a DIDDoc and corresponding keys, you can skip this step.
To create a DIDDoc, you can follow the instructions to create a DID with cheqd Cosmos CLI.
Let's assume the DID for the DIDDoc is as follows:
did:cheqd:mainnet:6h7fjuw37gbf9ioty633bnd7thf65hs1
UUIDs are used to identify Resources. On Unix systems, the uuidgen
tool can be used to generate a new UUID:
Resource content should be placed in a file and stored locally.
The fee for a resource transaction changes depending on the file type being passed to the ledger. Currently there are three different variations on the fee:
payload-file
- file with JSON formatted payload. The format and structure can be found in example
resource-data-file
- file which will be sent to the ledger as a data
. Can be a picture or an image or whatever you want.
flags
- additional parameters like, --gas
or --from
.
fees
- the specific fee for the transaction, depending on the type of resource file defined here
Example input:
where payload.json
is:
After you execute the command, you will receive "code": 0"
if the resource was successfully written to the ledger.
Otherwise, the raw_logs
field in the response can help figure out why something went wrong. For example:
Finally, to check that the resource was successfully written, we can use the following query:
<collection-id>
: The same unique identifier as that after the namespace of the corresponding DID created in step 1
<resource-id>
: Unique ID of the resource within the collection of resources associated with the DIDDoc
Example input:
Ouput:
Notice that both previous_version_id
and next_version_id
are empty now cause there is only one resource in such collection c82f2b02-bdab-4dd7-b833-3e143745d612
.
There are also 2 annother commands for getting resource from ledger depending what the actual info is needed.
Here is the command which allows to get only metadata information without getting the whole resource. The format of call is:
Parameters collection-id
and resource-id
have the same meaning as before.
Example input:
Output:
For querying all the resources but only metadata there is a special command:
As the main parameter it requires only collection-id
.
Example input:
Ouput:
Congratulations! You've successfully created a resource on cheqd ledger; hopefully, the first of many.
This is an advanced guide for those who want to develop applications that directly interact with the ledger code.
Most developers should start with our pre-built SDKs such as Veramo SDK for cheqd or the cheqd-node Cosmos CLI.
The ledger code package cheqd-node
is based on Cosmos SDK and uses the same module-based approach that is does.
There are two custom modules on cheqd ledger related to identity functionality:
cheqd
module, for everything related to Decentralized Identifiers (DIDs)
resource
module, for DID-Linked Resources
If your application is Golang-based, it's extremely easy to consume cheqd-node
as a Golang module.
Just as in Cosmos SDK, cheqd-node uses Protobufs to encode and exchange information. These can be found in the proto
directory on cheqd-node
repository.
Generated/built Protobuf for repeatable builds are also published to the cheqd
repository on Buf.build.
Types and utilities are available for re-use for each module as well. The utils
include functions for working with these custom modules, validation logic, etc.
cheqd
(DID) module
resource
module
After compiling a message (in your custom application), you can make a gRPC call to the ledger with your message.
cheqd DID Resolver is a real-world example of a Golang app built using
cheqd-node
primitivesThis allowed us to decouple DID Resolution logic from the ledger, while re-utilising existing code.
In general, the process building applications that work with cheqd in other languages follows very similar logic as described above for Golang apps.
Example 1: Veramo SDK for cheqd
Veramo SDK for cheqd combines the base NPM packages mentioned above to integrate cheqd ledger functionality into the 3rd party Veramo SDK.
The high-level steps are:
Consume Protobofs for cheqd: Our Buf.build packages for cheqd can make this take simpler for many languages. A real-world example of this is the @cheqd/ts-proto
TypeScript NPM package.
Prepare and sign the message correctly: This relies partly on understanding general Cosmos SDK message format and transaction signing, as well as any cheqd-specific bits. A real-world example of this is the @cheqd/sdk
NPM package that consumes @cheqd/ts-proto
NPM package.
Send the message to ledger using gRPC/RPC: Once a message/transaction is correctly compiled and signed, standard transport libraries can be used to target the gRPC/RPC endpoints for a cheqd-node
instance.
Example 2: Evernym VDR Tools
Evernym's VDR Tools SDK is an independent implementation written in Rust that integrates some cheqd ledger functionality.
This page describes how identity-domain transactions can be integrated in 3rd party applications such as .
Note: This cheqd SDK integration has now been deprecated and is no longer actively maintained.
Build a request Example: build_create_did_request(id, verkey, alias)
Sign the request using DID key Example: indy_crypto_sign(did, verkey)
Build a transaction with the request from previous step Example: build_tx(pool_alias, pub_key, builded_request, account_number, account_sequence, max_gas, max_coin_amount, denom, timeout_height, memo)
Sign the transaction Example: cheqd_keys_sign(wallet_handle, key_alias, tx)
.
Broadcast a signed transaction Example: broadcast_tx_commit(pool_alias, signed)
.
hash
: Transaction hash
height
: Ledger height
build_create_did_request(id, verkey, alias)
id
(base58-encoded string): Target DID as base58-encoded string for 16 or 32 byte DID value
verkey
(base58-encoded string, possibly starting with ""; optional): Target verification key. It can start with "", which means that it is an abbreviated verkey
and should be 16 bytes long when decoded. Otherwise, it's a full verkey
which should be 32 bytes long when decoded.
alias
(string; optional)
key
(string): A unique key is used to store this DID in a state
CreateDidRequest
must be signed by the DID from id
field. It means that this DID must be an owner of this DID transaction.
build_update_did_request(id, verkey, alias)
id
(base58-encoded string): Target DID as base58-encoded string for 16 or 32 byte DID value.
verkey
(base58-encoded string, possibly starting with ""; optional): Target verification key. It can start with "", which means that it is an abbreviated verkey
and should be 16 bytes long when decoded. Otherwise, it's a full verkey
which should be 32 bytes long when decoded.
alias
(string; optional).
key
(string): A unique key is used to store this DID in a state
A transaction with id
from UpdateDidRequest
must already be in a ledger created by CreateDidRequest
UpdateDidRequest
must be signed by the DID from id
field. It means that this DID must be an owner of this DID transaction.
build_query_get_did(id)
id
(base58-encoded string): Target DID as base58-encoded string for 16 or 32 byte DID value.
path
: Path for RPC endpoint for cheqd pool
data
: Query with an entity key from a state. String did:<id>
encoded to bytes
height
: Ledger height (size). None
for auto calculation
prove
: Boolean value. True
for getting state proof in a pool response