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:
The purpose of this document is to outline how someone can create a Resource on the cheqd network using . The process that's followed is similar to what's described in the .
Install the latest stable cheqd-node CLI, either as a or .
Acquire test CHEQ tokens through (if creating it on our testnet), or (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 .
Let's assume the DID for the DIDDoc is as follows:
did:cheqd:mainnet:6h7fjuw37gbf9ioty633bnd7thf65hs1
. 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
.
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.
The purpose of this document is to describe how an existing DID (and associated DIDDoc) can be deactivated 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
As in flow with 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
An existing did:cheqd
entry created using any SDK/CLI. For development purposes, this can be done using .
NOTE: Use the for production-grade usage
Querying using the Cosmos CLI is useful for development purposes, but the is designed for programmatic usage. Production-grade SDKs such as also rely on the DID Resolver package.
fees
- the specific fee for the transaction, depending on the
Note that each of cheqd's on-ledger identity transactions has a fixed fee, . If your account has insufficient balance the transaction will fail.
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.
The purpose of this document is to describe how an existing DID (and associated DIDDoc) can be updated 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
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
).
For example, we can take the DIDDoc created previously and change the Service Endpoint from bar.example.com
to foo.example.com
:
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 result 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 25000000000ncheq, which is the fixed fee for updating 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 someone can create a new Resource on under an existing Collection.
This tutorial uses the cheqd Cosmos CLI, similar to the creating a new Resource tutorial.
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).
Having a Resource already created under this DIDDoc Collection
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.
Resources with the same Collection ID and name are grouped into version sets. Each resource in such a set has a link to the previous version (except the first version) and the next version (if it's not the most recent version).
To create a resource and mark it as a new version within a particular group, we need to use the same collection-id
and name
as in the previous version. Links between versions will be created automatically.
New versions have dedicated unique IDs and can be referenced and retrieved as any other resources.
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
should match the price of the speicfic resource file type defined here.
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
Notice that previous_version_id
is not empty and pointing to the previously created resource with id
: 3e6bd814-6851-4c8a-b114-c64f035ef590
.
The purpose of this document is to describe how a DID (and associated DIDDoc) can be created using the cheqd-node
Cosmos CLI.
NOTE: The guidance below is 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.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.
Access to a cheqd-node
Cosmos CLI binary. You can either get this from our Github releases, or download the cheqd-cli
Docker container image.
Understand how to use cheqd accounts and Cosmos SDK keys.
Tokens to pay for identity transactions, since all ledger transactions are metered.
For testing purposes, CHEQ test tokens can be acquired from our testnet faucet.
Mainnet CHEQ tokens can be acquired from any marketplace where the $CHEQ token is traded.
For the remainder of this tutorial, it's assumed that the DID and associated DID Document is being created on testnet. These commands can easily be modified for mainnet.
First, we'll need to generate a verification key:
The result should look like the following:
Note: Keep this key safe! It is used to create the DIDDoc, and to update it in the future. Normally, you should be careful when cat
-ing such keys as it reveals the private key as well.
Encode the identity key's public key to one of the formats below according to the verificaiton method type you selected, as this will be later required in the verificationMethod
section:
A unique-id
should only be a 16-byte encoded base58 string (Indy-style) or a uuid.
For example, we can generate uuid using uuidgen
tool:
The result for our example will be b0ca0b75-ca6a-4674-a261-45f6dd0c9c77
, so let's use it as our unique-id
in our DIDDoc.
Copy-paste the template below into your terminal into a blank file (e.g., using nano
). We will add additional required information into the blank fields <xxxxx>
in the next steps.
You'll need to replace some values (as described in the cheqd DID method):
<namespace>
: Can be testnet
or mainnet
. For this CLI, we strongly suggest using testnet
.
<unique-id>
: Unique identifier, created in step #3