For more information on the command usage, refer to its help screen: terracli config --help
.
Here is a list of useful terracli
commands, including usage examples.
There are three types of key representations that are used:
terra
- Derived from account keys generated by
terracli keys add
- Used to receive funds
- e.g.
terra15h6vd5f0wqps26zjlwrc6chah08ryu4hzzdwhc
- Derived from account keys generated by
terravaloper
- Used to associate a validator to it's operator
- Used to invoke staking commands
- e.g.
terravaloper1carzvgq3e6y3z5kz5y6gxp3wpy3qdrv928vyah
-
terrapub
- Derived from account keys generated by
terracli keys add
- e.g.
terrapub1zcjduc3q7fu03jnlu2xpl75s2nkt7krm6grh4cc5aqth73v0zwmea25wj2hsqhlqzm
- Derived from account keys generated by
-
terravalconspub
- Generated when the node is created with
terrad init
. - Get this value with
terrad tendermint show-validator
- e.g.
terravalconspub1zcjduepq0ms2738680y72v44tfyqm3c9ppduku8fs6sr73fx7m666sjztznqzp2emf
- Generated when the node is created with
You'll need an account private and public key pair (a.k.a. sk, pk
respectively) to be able to receive funds, send txs, bond tx, etc.
To generate a new secp256k1 key:
terracli keys add <account_name>
Next, you will have to create a passphrase to protect the key on disk. The output of the above command will contain a seed phrase. It is recommended to save the seed phrase in a safe place so that in case you forget the password, you could eventually regenerate the key from the seed phrase with the following command:
terracli keys add --recover
If you check your private keys, you'll now see <account_name>
:
terracli keys show <account_name>
View the validator operator's address via:
terracli keys show <account_name> --bech=val
You can see all your available keys by typing:
terracli keys list
View the validator pubkey for your node by typing:
terrad tendermint show-validator
Note that this is the Tendermint signing key, not the operator key you will use in delegation transactions.
::: danger Warning We strongly recommend NOT using the same passphrase for multiple keys. The Terra team will not be responsible for the loss of funds. :::
You can generate and print a multisig public key by typing:
terracli keys add --multisig=name1,name2,name3[...] --multisig-threshold=K new_key_name
K
is the minimum number of private keys that must have signed the
transactions that carry the public key's address as signer.
The --multisig
flag must contain the name of public keys that will be combined into a
public key that will be generated and stored as new_key_name
in the local database.
All names supplied through --multisig
must already exist in the local database. Unless
the flag --nosort
is set, the order in which the keys are supplied on the command line
does not matter, i.e. the following commands generate two identical keys:
terracli keys add --multisig=foo,bar,baz --multisig-threshold=2 multisig_address
terracli keys add --multisig=baz,foo,bar --multisig-threshold=2 multisig_address
Multisig addresses can also be generated on-the-fly and printed through the which command:
terracli keys show --multisig-threshold K name1 name2 name3 [...]
For more information regarding how to generate, sign and broadcast transactions with a multi signature account see Multisig Transactions.
Each transaction may either supply fees or gas prices, but not both. Most users will typically provide fees as this is the cost you will end up incurring for the transaction being included in the ledger.
Validator's have a minimum gas price (multi-denom) configuration and they use
this value when when determining if they should include the transaction in a block
during CheckTx
, where gasPrices >= minGasPrices
. Note, your transaction must
supply fees that are greater than or equal to any of the denominations the validator requires.
Note: With such a mechanism in place, validators may start to prioritize
txs by gasPrice
in the mempool, so providing higher fees or gas prices may yield
higher tx priority.
e.g.
terracli tx send ... --fees=100usdr
or
terracli tx send ... --gas-prices=0.000001usdr
The best way to get tokens is from the Terra Testnet Faucet.
After receiving tokens to your address, you can view your account's balance by typing:
terracli query account <account_terra>
::: warning Note
When you query an account balance with zero tokens, you will get this error: No account with address <account_terra> was found in the state.
This can also happen if you fund the account before your node has fully synced with the chain. These are both normal.
:::
The following command could be used to send coins from one account to another:
terracli tx send <destination_terra> 10faucetToken \
--chain-id=<chain_id> \
--from=<key_name> \
::: warning Note
The --amount
flag accepts the format --amount=<value|coin_name>
.
:::
::: tip Note
You may want to cap the maximum gas that can be consumed by the transaction via the --gas
flag.
If you pass --gas=auto
, the gas supply will be automatically estimated before executing the transaction.
Gas estimate might be inaccurate as state changes could occur in between the end of the simulation and the actual execution of a transaction, thus an adjustment is applied on top of the original estimate in order to ensure the transaction is broadcasted successfully. The adjustment can be controlled via the --gas-adjustment
flag, whose default value is 1.0.
:::
Now, view the updated balances of the origin and destination accounts:
terracli query account <account_terra>
terracli query account <destination_terra>
You can also check your balance at a given block by using the --block
flag:
terracli query account <account_terra> --block=<block_height>
You can simulate a transaction without actually broadcasting it by appending the
--dry-run
flag to the command line:
terracli tx send <destination_terraaccaddr> 10faucetToken \
--chain-id=<chain_id> \
--from=<key_name> \
--dry-run
Furthermore, you can build a transaction and print its JSON format to STDOUT by
appending --generate-only
to the list of the command line arguments:
terracli tx send <destination_terraaccaddr> 10faucetToken \
--chain-id=<chain_id> \
--from=<key_name> \
--generate-only > unsignedSendTx.json
terracli tx sign \
--chain-id=<chain_id> \
--from=<key_name>
unsignedSendTx.json > signedSendTx.json
You can validate the transaction's signatures by typing the following:
terracli tx sign --validate-signatures signedSendTx.json
You can broadcast the signed transaction to a node by providing the JSON file to the following command:
terracli tx broadcast --node=<node> signedSendTx.json
You can use the transaction search command to query for transactions that match a specific set of tags
, which are added on every transaction.
Each tag is conformed by a key-value pair in the form of <tag>:<value>
. Tags can also be combined to query for a more specific result using the &
symbol.
The command for querying transactions using a tag
is the following:
terracli query txs --tags='<tag>:<value>'
And for using multiple tags
:
terracli query txs --tags='<tag1>:<value1>&<tag2>:<value2>'
The pagination is supported as well via page
and limit
:
terracli query txs --tags='<tag>:<value>' --page=1 --limit=20
::: tip Note
The action tag always equals the message type returned by the Type()
function of the relevant message.
You can find a list of available tags
on each module by looking at the /tags directory of each module.
:::
You can also query a single transaction by its hash using the following command:
terracli query tx [hash]
To unjail your jailed validator
terracli tx slashing unjail --from <validator-operator-addr>
To retrieve a validator's signing info:
terracli query slashing signing-info <validator-pubkey>
You can get the current slashing parameters via:
terracli query slashing params
Please refer to the Validator Setup section for a more complete guide on how to set up a validator-candidate.
On the upcoming mainnet, you can delegate luna
to a validator. These delegators can receive part of the validator's fee revenue.
You can query the list of all validators of a specific chain:
terracli query staking validators
If you want to get the information of a single validator you can check it with:
terracli query staking validator <account_terraval>
On the testnet, we delegate luna
. Here's how you can bond tokens to a testnet validator (i.e. delegate):
terracli tx staking delegate \
<validator address> \
10000000uluna \
--from=<key_name> \
--chain-id=<chain_id>
<validator>
is the operator address of the validator to which you intend to delegate. If you are running a local testnet, you can find this with:
terracli keys show [name] --bech val
where [name]
is the name of the key you specified when you initialized terrad
.
While tokens are bonded, they are pooled with all the other bonded tokens in the network. Validators and delegators obtain a percentage of shares that equal their stake in this pool.
::: tip Note
Don't use more luna
thank you have! You can always get more by using the Faucet!
:::
Once submitted a delegation to a validator, you can see it's information by using the following command:
terracli query staking delegation <delegator_addr> <validator_addr>
Or if you want to check all your current delegations with disctinct validators:
terracli query staking delegations <delegator_addr>
You can also get previous delegation(s) status by adding the --height
flag.
If for any reason the validator misbehaves, or you just want to unbond a certain amount of tokens, use this following command. You can unbond a specific shares-amount
(eg:12.1
) or a shares-fraction
(eg:0.25
) with the corresponding flags.
terracli tx staking unbond \
--validator=<account_terraval> \
--shares-fraction=0.5 \
--from=<key_name> \
--chain-id=<chain_id>
The unbonding will be automatically completed when the unbonding period has passed.
Once you begin an unbonding-delegation, you can see it's information by using the following command:
terracli query staking unbonding-delegation <delegator_addr> <validator_addr>
Or if you want to check all your current unbonding-delegations with disctinct validators:
terracli query staking unbonding-delegations <account_terra>
Additionally, as you can get all the unbonding-delegations from a particular validator:
terracli query staking unbonding-delegations-from <account_terraval>
To get previous unbonding-delegation(s) status on past blocks, try adding the --height
flag.
A redelegation is a type delegation that allows you to bond illiquid tokens from one validator to another:
terracli tx staking redelegate \
<src validator address> \
<dst validator address> \
<amount> \
--from=<key_name> \
--chain-id=<chain_id>
Here you can also redelegate a specific shares-amount
or a shares-fraction
with the corresponding flags.
The redelegation will be automatically completed when the unbonding period has passed.
Once you begin an redelegation, you can see it's information by using the following command:
terracli query staking redelegation <delegator_addr> <src_val_addr> <dst_val_addr>
Or if you want to check all your current unbonding-delegations with disctinct validators:
terracli query staking redelegations <account_terra>
Additionally, as you can get all the outgoing redelegations from a particular validator:
terracli query staking redelegations-from <account_terraval>
To get previous redelegation(s) status on past blocks, try adding the --height
flag.
Parameters define high level settings for staking. You can get the current values by using:
terracli query staking params
With the above command you will get the values for:
- Unbonding time
- Maximum numbers of validators
- Coin denomination for staking
All these values will be subject to updates though a governance
process by ParameterChange
proposals.
A staking Pool
defines the dynamic parameters of the current state. You can query them with the following command:
terracli query staking pool
With the pool
command you will get the values for:
- Not-bonded and bonded tokens
- Token supply
- Current annual inflation and the block in which the last inflation was processed
- Last recorded bonded shares
You can also query all of the delegations to a particular validator:
terracli query delegations-to <account_terraval>
To check the current distribution parameters, run:
terracli query distr params
To check the current outstanding (un-withdrawn) rewards, run:
terracli query distr outstanding-rewards
To check the current outstanding commission for a validator, run:
terracli query distr commission <validator_address>
To check historical slashes for a validator, run:
terracli query distr slashes <validator_address> <start_height> <end_height>
To check current rewards for a delegation (were they to be withdrawn), run:
terracli query distr rewards <delegator_address> <validator_address>
To check all current rewards for a delegation (were they to be withdrawn), run:
terracli query distr rewards <delegator_address>
Multisig transactions require signatures of multiple private keys. Thus, generating and signing a transaction from a multisig account involve cooperation among the parties involved. A multisig transaction can be initiated by any of the key holders, and at least one of them would need to import other parties' public keys into their Keybase and generate a multisig public key in order to finalize and broadcast the transaction.
For example, given a multisig key comprising the keys p1
, p2
, and p3
, each of which is held
by a distinct party, the user holding p1
would require to import both p2
and p3
in order to
generate the multisig account public key:
terracli keys add \
p2 \
--pubkey=terrapub1addwnpepqtd28uwa0yxtwal5223qqr5aqf5y57tc7kk7z8qd4zplrdlk5ez5kdnlrj4
terracli keys add \
p3 \
--pubkey=terrapub1addwnpepqgj04jpm9wrdml5qnss9kjxkmxzywuklnkj0g3a3f8l5wx9z4ennz84ym5t
terracli keys add \
p1p2p3 \
--multisig-threshold=2 \
--multisig=p1,p2,p3
A new multisig public key p1p2p3
has been stored, and its address will be
used as signer of multisig transactions:
terracli keys show --address p1p2p3
You may also view multisig threshold, pubkey constituents and respective weights
by viewing the JSON output of the key or passing the --show-multisig
flag:
terracli keys show p1p2p3 -o json
terracli keys show p1p2p3 --show-multisig
The first step to create a multisig transaction is to initiate it on behalf of the multisig address created above:
terracli tx send terra1570v2fq3twt0f0x02vhxpuzc9jc4yl30q2qned 10stake \
--from=<multisig_address> \
--generate-only > unsignedTx.json
The file unsignedTx.json
contains the unsigned transaction encoded in JSON.
p1
can now sign the transaction with its own private key:
terracli tx sign \
unsignedTx.json \
--multisig=<multisig_address> \
--from=p1 \
--output-document=p1signature.json \
Once the signature is generated, p1
transmits both unsignedTx.json
and
p1signature.json
to p2
or p3
, which in turn will generate their
respective signature:
terracli tx sign \
unsignedTx.json \
--multisig=<multisig_address> \
--from=p2 \
--output-document=p2signature.json \
p1p2p3
is a 2-of-3 multisig key, therefore one additional signature
is sufficient. Any the key holders can now generate the multisig
transaction by combining the required signature files:
terracli tx multisign \
unsignedTx.json \
p1p2p3 \
p1signature.json p2signature.json > signedTx.json
The transaction can now be sent to the node:
terracli tx broadcast signedTx.json
Completion scripts for popular UNIX shell interpreters such as Bash
and Zsh
can be generated through the completion
command, which is available for both
terrad
and terracli
.
If you want to generate Bash
completion scripts run the following command:
terrad completion > terrad_completion
terracli completion > terracli_completion
If you want to generate Zsh
completion scripts run the following command:
terrad completion --zsh > terrad_completion
terracli completion --zsh > terracli_completion
::: tip Note
On most UNIX systems, such scripts may be loaded in .bashrc
or
.bash_profile
to enable Bash autocompletion:
echo '. terrad_completion' >> ~/.bashrc
echo '. terracli_completion' >> ~/.bashrc
Refer to the user's manual of your interpreter provided by your operating system for information on how to enable shell autocompletion. :::