cheqd Studio
Low complexity
Customers can easily integrate cheqd's identity functionality into their existing applications through hitting simple REST APIs using cheqd Studio.
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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 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.
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-nodeCosmos 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
<key-alias>: A key alias for the verification method identifier, e.g., #key1
<verification-method-type>: Verification method type slected from step #2 above
<public-key-base58>, <public-key-multibase>, <public-key-jwk>: Any one of the values from the result of step #2 above
<auth-key-alias>: Alias of authentication key. Can be a reference to an existing verification method.
<service-key>: Alias for service property. This is an optional section but useful to understand the power of DIDDocs.
<URI-to-object>: A valid URI that can act as a service endpoint.
The examples below show the variation in syntax for different verification method key types in the DIDDoc contents. Note that each key type has a slightly different output.
We recommend you save this DIDDoc file (e.g., in a file called diddoc.json) for the following steps.
After assembling the DID-Document JSON file we are ready to compile the final payload file with private key inside.
The example of payload.json files with different verification methods:
Now that we have our DIDDoc prepared, we can send a create DID request to the ledger:
Where:
--from: Should be an alias of a cheqd/Cosmos key, which will be used to pay for the ledger transaction.
--fees: Should equal 50000000000ncheq, which is equivalent to 50 CHEQ, the current price for a create DID transaction on testnet and mainnet.
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.
After you execute the command, you will receive "code": 0" if the DID 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 DID was successfully written to the ledger, we can use the following query:
where:
<identifier-of-your-DIDDoc>: Fully-qualified DID with <unique-id>
For example:
Congratulations! You've created, hopefully, the first of many DIDs on cheqd!
Since upgrading to 1.x.y version, we introduced versioning feature for DID Documents. This means that it is possible to get the previous version of a DID Document using the particular versionId of the document.
For querying particular version of the DID-Document the next command can be used:
Where:
id - identifier of your DID-Document. Fully-qualified DID with <unique-id>
version-id - particular id of version you want to get
Command:
Output:
Note that the output here is in snake_case because of how the cheqd ledger represents protobufs. This output would be in spec compliant JSON if queried using our DID resolver.
For querying all the versions there is a command:
Where:
id - identifier of your DID-Document. Fully-qualified DID with <unique-id>
Output:
NOTE: The tutorials below are only recommended to be used for testing purposes!
Using
cheqd-nodeCosmos 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:
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 UpdateDidRequestmust 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
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 or the cheqd-node Cosmos CLI.
The is based on 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
If your application is Golang-based, it's extremely easy to .
Just as in Cosmos SDK, cheqd-node uses Protobufs to encode and exchange information. These can be found in the repository.
Generated/built Protobuf for repeatable builds are also published to the .
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.
This 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.
The high-level steps are:
The purpose of this document is to describe how someone can create a new Resource on under an existing Collection.
This tutorial uses the , similar to 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).
An
Having under this DIDDoc Collection
. 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.
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 an existing DID (and associated DIDDoc) can be deactivated using .
NOTE: The procedures below are only recommended for development purposes!
Using
cheqd-nodeCosmos 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
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-nodeCosmos 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
is a real-world example of a Golang app built using cheqd-node primitives
Example 1:
Veramo SDK for cheqd combines the base NPM packages mentioned above to integrate cheqd ledger functionality into the 3rd party .
Consume Protobofs for cheqd: Our can make this take simpler for many languages. A real-world example of this is the 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 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 for a cheqd-node instance.
Example 2:
is an independent implementation written in Rust that .
flags - additional parameters like, --gas or --from. --fees should match the price of 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.
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.
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.
cheqd has designed a wallet to demonstrate and test its DeFi functionality as well as its identity tooling.
CHEQ Wallet allows users to perform standard DeFi activities on Cosmos such as staking/delegating, voting on governance Proposals, and sending tokens. Crucially, the CHEQ wallet goes one step further than this, offering the ability to store and share Verifiable Credentials.
Access your CHEQ wallet account by connecting to the Keplr browser extension
Send CHEQ tokens
Delegate, undelegate and redelegate to validators
Store and share digital identity credentials
The wallet demonstrates how Verifiable Credentials and $CHEQ tokens could be held in the same place and managed with one UI. This is the kind of work that cheqd wants to approach alongside its partners in H2 2022.
We also want to use the cheqd wallet to issue the cheqd community reward Credentials, based on their engagement and loyalty to cheqd. Through gamifying engagement, we can showcase the value of Verifiable Credentials to a much larger audience than the identity ecosystem.
There are two package.json in this repository. You can use a package manager like Yarn or NPM to install dependencies.
You can build your app with Yarn or similar package managers.
The installation and build steps can be executed together using the Makefile in this repository as well by using the command below:
Serve the app by using this command:
This repo is forked from the LUM network wallet which also uses Lum Network's Javascript SDK.
cheqd Cosmos CLI
Use the Cosmos CLI to create DIDs and DID-Linked Resources for testing purposes.
Direct integration
Build a direct integration with the ledger code for the greatest flexibility.
VDR tools CLI
Build on Evernym's VDR tools (with cheqd support now outdated).
Demo wallet
Spin up a demo wallet for testing purposes, or fork our existing work.
