Cronosd
Last updated
Was this helpful?
Last updated
Was this helpful?
cronosd
is an all-in-one command-line interface. It supports wallet management, funds transfers and staking operations.
You can get the latest cronosd
binary here from the ;
cronosd
cronosd
is bundled with the Crypto.org Chain code. After you have obtained the latest cronosd
binary, run
There is also a -h, --help
command available
By default, your configuration and data are stored in the folder located in the ~/.cronos
directory.
Ensure that you have backed up your wallet after creating it. Otherwise, your funds may be inaccessible in the event of an accident.
To specify the cronosd config and data storage directory; you can add a global flag --home <directory>
We can view the default config setting by using cronosd config
command:
We can make changes to the default settings upon our choices, so it allows users to set the configuration beforehand all at once, so it would be ready with the same config afterward.
For example, the chain-id
can be changed to cronostestnet_338-1
from a blank name by
Other values can be changed in the same way.
Alternatively, we can directly make the changes to the config values in one place at client.toml. It is under the path of .ethermint/config/client.toml
in the folder where we installed ethermint:
After the necessary changes are made in the client.toml
, then save. For example, if we directly change the chain-id
from ethermint0
to ethermint-test1, and output to number, it would change instantly as shown below.
A list of commonly used flags of cronosd is listed below:
--home
Directory for config and data
string
~/.cronos
--chain-id
Full Chain ID
String
---
--output
Output format
string
"text"
--keyring-backend
Select keyring's backend
os/file/test
os
A list of commonly used cronosd
commands.
keys
tx
query
You may also add the flag -h, --help
on cronosd [command]
to get more available commands and details.
cronosd keys
First of all, you will need an address to store and spend your CRO.
keys add <wallet_name>
- Create a new keyYou can create a new key with the name Default
as in the following example:
The key comes with a "mnemonic phrase", which is serialized into a human-readable 24-word mnemonic. User can recover their associated addresses with the mnemonic phrase.
It is important that you keep the mnemonic for address secure, as there is no way to recover it. You would not be able to recover and access the funds in the wallet if you forget the mnemonic phrase.
keys add <key_name> --recover
- Restore existing key by seed phraseYou can restore an existing key with the mnemonic.
keys list
- List your keysMultiple keys can be created when needed. You can list all keys saved under the storage path.
keys show <key_name>
- Retrieve key informationYou can retrieve key information by its name:
keys delete <key_name>
- Delete a keyYou can delete a key in your storage path.
Make sure you have backed up the key mnemonic before removing any of your keys, as there will be no way to recover your key without the mnemonic.
keys export <key_name>
- Export private keysYou can export and backup your key by using the export
subcommand:
--keyring-backend
optionInteracting with a node requires a public-private key pair. Keyring is the place holding the keys. The keys can be stored in different locations with specified backend type.
1. os
backendThe default os
backend stores the keys in operating system's credential sub-system, which are comfortable to most users, yet without compromising on security.
Here is a list of the corresponding password managers in different operating systems:
GNU/Linux:
2. file
backendThe file
backend stores the encrypted keys inside the app's configuration directory. A password entry is required every time a user access it, which may also occur multiple times of repeated password prompts in one single command.
3. test
backendThe test
backend is a password-less variation of the file
backend. It stores unencrypted keys inside the app's configuration directory. It should only be used in testing environments and never be used in production.
cronosd tx
tx bank send
- Transfer operationTransfer operation involves the transfer of tokens between two addresses.
tx bank send <from_key_or_address> <to_address> <amount> <network_id>
]tx staking
- Staking operationsStaking operations involve the interaction between an address and a validator. It allows you to create a validator and lock/unlocking funds for staking purposes.
tx staking delegate <validator-addr> <amount>
]To bond funds for staking, you can delegate funds to a validator by the delegate
command
tx staking unbond <validator-addr> <amount>
]On the other hand, we can create a Unbond
transaction to unbond the delegated funds
query bank balances
- Check your transferable balanceYou can check your transferable balance with the balances
command under the bank module.
To recover from an app-hash mismatch failure, it would take hours to re-run an archive node,
a faster way to do it as of cronos v1.0.2 would be to use rollback
.
After v1.0.2
nodes can now enable the custom transaction indexer to reduce disk size.
The custom tx indexer can be enabled in app.toml
by setting the json-rpc.enable-indexer
to true
. Usually, you will want to re-index previous indexed blocks by using the --backward
field, e.g.:
After running the re-index command you will notice in your .cronos/data/
directory a new file called evmindexer.db
from which you can see that the size is smaller than the original tx_index.db
. You can now safely remove the tx_index.db
file.
tx staking create-validator
- Joining the network as a validatorAnyone who wishes to become a validator can submit a create-validator
transaction by
(TODO: details of each flag )
tx slashing unjail
- Unjail a validatorValidator could be punished and jailed due to network misbehaviour, for example, if we check the validator set:
After the jailing period has passed, one can broadcast a unjail
transaction to unjail the validator and resume its normal operations by
macOS (since Mac OS 8.6):
Windows:
Only use this command if you are solely using evm-level queries as evm JSON-RPC queries will remain available after re-indexing, however cosmos-level tx will not be available anymore. For example, this will no longer be possible: