An account in the Cosmos SDK, consists of a pair of a public key PubKey and a private key PrivKey. The PubKey can be used to generate various Addresses, which identify users and other parties in the application and are associated with messages to identify the sender. The PrivKey is used to generate digital signatures to prove that an Address associated with the PrivKey has approved a specific message.
KIRA accounts only exist on the blockchain if they have a non-zero balance. This is a feature of the Cosmos SDK that helps prevent the creation of "spam" accounts that do not hold any value. All KIRA addresses are 44 characters long and are Bech32 encoded with a kira prefix (e.g. kira1d52rts8wf508uy2sdcx4a0qxjzvqr3dsnesm4w). These accounts are derived from BIP39 mnemonic words, which must be kept safe by the account holder at all times. Losing access to the mnemonic or revealing its contents will result in permanent and irrecoverable loss of funds.
KIRA network defines 3 types of addresses that specify a context where an account is used:
AccAddress identifies users (the sender of a message).
ValAddress identifies consensus node operators (a.k.a validators).
ConsAddress identifies consensus nodes that are participating in consensus. Consensus nodes are derived using the ed25519 curve.
Keyring
Like in every Cosmos-based network, Private/Public keys are stored and managed by using an object called a Keyring which default implementation comes from the third-party 99designs/keyring library. The private key can be stored in different "backends", such as a file or the operating system's own key storage system. The keyring allows users to manage their keys in a secure and convenient way, and can be integrated with various backend storage options to suit the needs of the user. These backends can be specified in the CLI using the --keyring-backend flag (cf. flags configuration documentation).
The os backend: This backend relies on operating system-specific defaults to handle key storage securely. It is the default option and is designed to meet users' most common needs and provide a comfortable experience without compromising on security.
The file backend: This backend stores the keyring encrypted within the app's configuration directory. It requires a password each time it is accessed, which may result in multiple prompts.
The pass backend: This backend uses the pass utility to manage on-disk encryption of keys' sensitive data and metadata. Keys are stored inside gpg encrypted files within app-specific directories.
The kwallet backend: This backend uses KDE Wallet Manager, which comes installed by default on the GNU/Linux distributions that ships KDE as default desktop environment.
The test backend: This backend is a password-less variation of the file backend and is provided for testing purposes only. It stores keys unencrypted on disk and is not recommended for use in production environments.
The memory backend: This backend stores keys in memory, which are immediately deleted after the program has exited. It is provided for testing purposes only and is not recommended for use in production environments.
CLI functions description
sekaid keys
add - Add an encrypted private key (either newly generated or recovered), encrypt it, and save to <name> file
delete - Delete the given keys
show - Retrieve key information by name or address
Syntax & examples
Each CLI command and proposal process in KIRA requires specific permissions. These permissions must be added to the account's whitelist or obtained as sudo permissions for direct changes. Refer to the 
Roles & Permissions documentation for more details. $SIGNER represents the transaction signer's account name or address. For instructions on setting common flags as environment variables, such as $FLAGS_TX and $FLAGS_QR, see the 
CLI flags configuration section
Roles & Permissions documentation for more details. $SIGNER represents the transaction signer's account name or address. For instructions on setting common flags as environment variables, such as $FLAGS_TX and $FLAGS_QR, see the CLI flags configuration sectionCreating an account
To create a new key in the keyring, use the add subcommand and provide the desired account key name as an argument. You can also specify the keyring backend to use by setting the $FLAGS_TX environment variable or by manually using the --keyring-backend flag. This is important as it determines where the private/public keypair will be stored and how it will be managed. A --multisig flag can also be provided to group multiple keys together to create a multisig key.
Bash
Copy
sekaid keys add $ACCOUNT_NAME $FLAGS_TX
Delete an account
To delete a key from the keyring, use the delete subcommand and provide the desired account key address as an argument and specify the keyring backend to delete from by setting the $FLAGS_TX environment variable or by manually using the --keyring-backend flag. --force flag can be specified to skip passphrase check and force key deletion unconditionally. NOTE: removing offline or ledger keys will remove only the public key references stored locally, i.e. private keys stored in a ledger device cannot be deleted with the CLI.
Bash
Copy
sekaid keys delete $ACCOUNT_NAME $FLAGS_TX --force --yes
Recovering account using mnemonic
To recover an account using its respective mnemonic, use the add subcommand with the —recover flag and provide the desired account key name as an argument.
Bash
Copy
yes "$ACCOUNT_MNEMONIC" | sekaid keys add $ACCOUNT_NAME $FLAGS_TX --recover
Queries
Retrieve key information by name or address
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.
Bash
Copy
sekaid keys show $ACCOUNT_KEY $FLAGS_QR | jq