These keys may be in any format supported by the Tendermint crypto library and can be used by light-clients, full nodes, or any other application that needs to sign with a private key.
The keyring supports the following backends:
Uses the operating system's default credentials store.
Uses encrypted file-based keystore within the app's configuration directory. This keyring will request a password each time it is accessed, which may occur multiple times in a single command resulting in repeated password prompts.
Stores keys insecurely to disk. It does not prompt for a password to be unlocked and it should be use only for testing purposes.
$ rizond keys add [wallet_name] [flags]
This command returns wallet address and mnemonic. You must remember the results.
# recover from mnemonic
$ rizond keys add [wallet_name] --recover
# import from private_key
$ rizond keys import [wallet_name] [private_key_file]
Display keys details. If multiple names or addresses are provided, then an ephemeral multisig key will be created under the name "multi" consisting of all the keys provided by name and multisig threshold.
$ rizond keys show [name_or_address [name_or_address...]] [flags]
Return a list of all public keys stored by this key manager along with their associated name and address.
$ rizond keys list [flags]
You can query all relevant information from the blockchain using
If you want to know about the list of query commands, just type
$ rizond query
These are frequently used commands. For each command, you can use
--helpflag to get more information about.
Query for account by address
$ rizond query account [address] [flags]
Query the total balance of an account or of a specific denomination.
$ rizond query bank balances [address] --denom=[denom]
Get verified data for a the block at given height
$ rizond query block [height] [flags]
Query delegations for an individual delegator
$ rizond query staking delegations [delegator-addr] [flags]
Query details about an individual validator.
$ rizond query staking validator [validator-addr] [flags]
Query all rewards earned by a delegator, optionally restrict to rewards from a single validator
$ rizond query distribution rewards [delegator-addr] [validator-addr] [flags]
Query for a transaction by hash in a committed block
$ rizond query tx [hash] [flags]
Other than querying blockchain data, you also can interact with the blockchain, sending transactions containing messages.
$ rizond tx
Please check each module's tx commands to learn how generate and broadcast txs with which message parameters.
Most frequently used command of tx is
send. Through this
sendcommand, see how to use tx commands.
Send funds from one account to another.
$ rizond tx bank send [from_key_or_address] [to_address] [amount] [flags]
The tx command processes through
broadcaststeps. So the command above works internally generate unsigned transaction first, and ask password of
from_key_or_addressto sign, sign the generated transaction with key, and finally broadcast the signed transaction.
You can simulate a transaction without actually broadcasting it by appending the
--dry-runflag to the command line.
$ rizond tx bank send [from_key_or_address] [to_address] [amount] [flags] --dry-run
This returns gas estimation if success or error result when fail.
You can build a transaction with
--generate-onlyflag. This allows you to separate the creation and signing of a transaction without broadcasting.
$ rizond tx bank send [from_address] [to_address] [amount] [flags] --generate-only
from_keyis not supported in generate-only mode. You need to use
This command returns unsigned transaction as standard output. You'd better redirect the stdout to file to sign it easily.
Sign a transaction created with the
--generate-onlyflag. It will read a transaction from
[file], sign it, and print its JSON encoding.
--signature-onlyflag is set, it will output the signature parts only.
--offlineflag makes sure that the client will not reach out to full node. As a result, the account and sequence number queries will not be performed and it is required to set such parameters manually. Note, invalid values will cause the transaction to fail.
$ rizond tx sign [file] [flags]
This command also returns signed result as standard output. So you'd better redirect the stdout to file to broadcast, too.
Before broadcast signed transaction, you can validate the transaction's signatures.
This prints the addresses that must sign the transaction, those who have already signed it, and make sure that signatures are in the correct order.
The command would check whether all required signers have signed the transactions, whether the signatures were collected in the right order, and if the signature is valid over the given transaction. If the
--offlineflag is also set, signature validation over the transaction will be not be performed as that will require RPC communication with a full node.
$ rizond tx validate-signatures [file] [flags]
You can broadcast transactions created with the
--generate-onlyflag and signed with the
signcommand. This command reads the transaction from
[file]and broadcast it to a node.
$ rizond tx broadcast [file] [flags]
Create new validator initialized with a self-delegation to it
$ rizond tx staking create-validator [flags]
create-validatorcommand needs some mandatory flags.
Amount of coins to bond
The Bech32 encoded PubKey of the validator
The validator's name
The initial commission rate percentage
The maximum commission rate percentage
The maximum commission change rate percentage (per day)
The minimum self delegation required on the validator
Name or address of private key with which to sign
The network chain ID to connect
Fees (or gas-prices) to pay along with transaction
In the Cosmos based platforms,
gasis a special unit that is used to track the consumption of resources during execution.
gasis typically consumed whenever read and writes are made to the store, but it can also be consumed if expensive computation needs to be done. It serves two main purposes:
- Make sure blocks are not consuming too many resources and will be finalized. This is implemented by default in the SDK via the block gas meter.
- Prevent spam and abuse from end-user. To this end,
messageexecution is typically priced, resulting in a
fees = gas * gas-prices).
feesgenerally have to be paid by the sender of the
message. Note that the Cosmos platform does not enforce
gaspricing by default, as there may be other ways to prevent spam (e.g. bandwidth schemes). Still, most applications will implement
feemechanisms to prevent spam. This is done via the
Transactions on the network need to include a transaction fee in order to be processed. This fee pays for the gas required to run the transaction. There are three flags to set transaction fee.
gasis dependent on the transaction. Different transaction require different amount of
gas-pricesis the price of each unit of
gas. Each validator sets a
minimum-gas-pricesvalue, and will only include transactions that have a
gas-pricesgreater than their
feesare the product of
As a user, you must input
fees. The validators specify a
app.tomlfile that they use to determine whether to include a transaction, where
gas-prices >= min-gas-prices. The higher
fees, the higher chance that your transaction will get included in a block.
For setting fees, you first can use
$ rizond tx send ... --gas-prices=0.0001uatolo
You don't need to use
--gasflag every time, the
gasamount for a transaction is calculated as it is being processed automatically as default. Of course, this only gives an estimate, so it returns failures. So you can adjust this estimate with the flag
--gas-adjustmentif you want to be sure you provide enough
gasfor the transaction.
You also use
$ rizond tx send ... --fees=10000uatolo
If you use fees, validators will calculate the implied
min-gas-pricesby dividing your fee with the estimated
gasconsumption, to properly assign the right priority to your transaction.