cheqd Cosmos CLI can be used manage keys on a node.Keys are closely related to accounts and on-ledger authentication.
Account addresses are on a cheqd node are an encoded version of a public key. Each account is linked with at least one public-private key pair. Multi-sig accounts can have more than one key pair associated with them.
To submit a transaction on behalf of an account, it must be signed with an account's private key.
Cosmos supports multiple keyring backends for the storage and management of keys. Each node operator is free to use the key management method they prefer.
By default, the cheqd-noded binary is configured to use the os keyring backend, as it is a safe default compared to file-based key management methods.
For test networks or local networks, this can be overridden to the test keyring backend which is less secure and uses a file-based key storage mechanism where the keys are stored un-encrypted. To use the test keyring backend, append --keyring-backend test to each command that is related to key management or usage.
Each cheqd validator node has at least two keys.
Default location is $HOME/config/node_key.json
Used for peer-to-peer communication
Default location is $HOME/config/priv_validator_key.json
Used to sign consensus messages
When a new key is created, an account address and a mnemonic backup phrase will be printed. Keep mnemonic safe. This is the only way to restore access to the account if they keyring cannot be recovered.
Allows restoring a key from a previously-created BIP39 mnemonic phrase.
Most transactions will require you to use --from <key-alias> param which is a name or address of private key with which to sign a transaction.
A cheqd-node instance can be controlled and configured using the cheqd Cosmos CLI.
This document contains the commands for reading and writing token transactions.
--node: IP address or URL of node to send the request to
--node: IP address or URL of node to send request to
--chain-id: i.e. cheqd-testnet-6
--fees: Maximum fee limit that is allowed for the transaction.
Pay attention at return status code. It should be 0 if a transaction is submitted successfully. Otherwise, an error message may be returned.
There are two command line interface (CLI) tools for interacting with a running cheqd-node instance:
cheqd Cosmos CLI: This is intended for node operators. Typically for node configuration, setup, and Cosmos keys.
Identity SDKs: Such as Veramo SDK plugin for cheqd, for identity transactions with DIDs, Verifiable Credentials, and DID-Linked Resources.
This document is focussed on providing guidance on how to use the cheqd Cosmos CLI.
A cheqd-node instance can be controlled and configured using the cheqd Cosmos CLI.
This document contains the commands for account management.
from can be either key alias or address. If it's an address, corresponding key should be in keychain.
A cheqd-node instance can be controlled and configured using the cheqd Cosmos CLI.
This document contains the commands for node operators that relate to node management, configuration, and status.
Node ID or node address is a part of peer info. It's calculated from node's pubKey as hex(address(nodePubKey)). To get node id run the following command on the node's machine:
Validator address is a function of validator's public key. To get bech32 encoded validator address run this command on node's machine:
There are several ways to get hex-encoded validator address:
Convert from bech32
Query node using CLI:
Look for "ValidatorInfo":{"Address":"..."}
Validator public key is used in create-validator transactions. To get bech32 encoded validator public key, run the following command on the node's machine:
Peer info is used to connect to peers when setting up a new node. It has the following format:
Example:
Using this information other participants will be able to join your node.