# Keyring

Create, import, export and delete keys using the CLI keyring.

The keyring holds the private/public keypairs used to interact with the node. For instance, a validator key needs to be set up before running the node, so that blocks can be correctly signed. The private key can be stored in different locations, called ["backends"](#keyring-backends), such as a file or the operating system's own key storage.

tip

In case, you need a refresher on private key and key management, please reference our [Key Management](/concepts/key-management.md).

### Add keys[​](broken://pages/DNEGCMcw2QSkhPz7pDwa) <a href="#add-keys" id="add-keys"></a>

You can use the following commands for help with the `keys` command and for more information about a particular subcommand, respectively:

```
lagomd keys [command] --help
```

To create a new key in the keyring, run the `add` subcommand with a `<key_name>` argument. You will have to provide a password for the newly generated key. This key will be used in the next section.

```
lagomd keys add dev0

# Put the generated address in a variable for later use.
MY_VALIDATOR_ADDRESS=$(lagomd keys show dev0 -a)
```

This command generates a new 24-word mnemonic phrase, persists it to the relevant backend, and outputs information about the keypair. If this keypair will be used to hold value-bearing tokens, be sure to write down the mnemonic phrase somewhere safe!

By default, the keyring generates a `eth_secp256k1` key. The keyring also supports `ed25519` keys, which may be created by passing the `--algo` flag. A keyring can of course hold both types of keys simultaneously.

tip

**Note**: The Ethereum address associated with a public key can be derived by taking the full Ethereum public key of type `eth_secp256k1`, computing the `Keccak-256` hash, and truncating the first twelve bytes.

danger

**NOTE**: Cosmos `secp256k1` keys are not supported on LagomChain due to compatibility issues with Ethereum transactions.

### Keyring Backends[​](broken://pages/DNEGCMcw2QSkhPz7pDwa) <a href="#keyring-backends" id="keyring-backends"></a>

#### OS[​](broken://pages/DNEGCMcw2QSkhPz7pDwa) <a href="#os" id="os"></a>

tip

**`os`** is the default option since operating system's default credentials managers are designed to meet users' most common needs and provide them with a comfortable experience without compromising on security.

The `os` backend relies on operating system-specific defaults to handle key storage securely. Typically, an operating system's credential sub-system handles password prompts, private keys storage, and user sessions according to the user's password policies. Here is a list of the most popular operating systems and their respective passwords manager:

* macOS (since Mac OS 8.6): [Keychain](https://support.apple.com/en-gb/guide/keychain-access/welcome/mac)
* Windows: [Credentials Management API](https://docs.microsoft.com/en-us/windows/win32/secauthn/credentials-management)
* GNU/Linux:
* [libsecret](https://gitlab.gnome.org/GNOME/libsecret)
* [kwallet](https://api.kde.org/frameworks/kwallet/html/index.html)

GNU/Linux distributions that use GNOME as default desktop environment typically come with [Seahorse](https://wiki.gnome.org/Apps/Seahorse). Users of KDE based distributions are commonly provided with [KDE Wallet Manager](https://userbase.kde.org/KDE_Wallet_Manager). Whilst the former is in fact a `libsecret` convenient frontend, the latter is a `kwallet` client.

The recommended backends for headless environments are `file` and `pass`.

#### File[​](broken://pages/DNEGCMcw2QSkhPz7pDwa) <a href="#file" id="file"></a>

The `file` stores the keyring encrypted 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. If using bash scripts to execute commands using the `file` option you may want to utilize the following format for multiple prompts:

```
# assuming that KEYPASSWD is set in the environment
yes $KEYPASSWD | lagomd keys add me
yes $KEYPASSWD | lagomd keys show me
# start lagomd with keyring-backend flag
lagomd --keyring-backend=file start
```

tip

The first time you add a key to an empty keyring, you will be prompted to type the password twice.

#### Password Store[​](broken://pages/DNEGCMcw2QSkhPz7pDwa) <a href="#password-store" id="password-store"></a>

The `pass` backend uses the [pass](https://www.passwordstore.org/) utility to manage on-disk encryption of keys' sensitive data and metadata. Keys are stored inside `gpg` encrypted files within app-specific directories. `pass` is available for the most popular UNIX operating systems as well as GNU/Linux distributions. Please refer to its manual page for information on how to download and install it.

tip

**`pass`** uses [GnuPG](https://gnupg.org/) for encryption. `gpg` automatically invokes the `gpg-agent` daemon upon execution, which handles the caching of GnuPG credentials. Please refer to `gpg-agent` man page for more information on how to configure cache parameters such as credentials TTL and passphrase expiration.

The password store must be set up prior to first use:

Replace `<GPG_KEY_ID>` with your GPG key ID. You can use your personal GPG key or an alternative one you may want to use specifically to encrypt the password store.

#### KDE Wallet Manager[​](broken://pages/DNEGCMcw2QSkhPz7pDwa) <a href="#kde-wallet-manager" id="kde-wallet-manager"></a>

The `kwallet` backend uses `KDE Wallet Manager`, which comes installed by default on the GNU/Linux distributions that ships KDE as default desktop environment. Please refer to [KWallet Handbook](https://docs.kde.org/stable5/en/kwalletmanager/kwallet5/) for more information.

#### Testing[​](broken://pages/DNEGCMcw2QSkhPz7pDwa) <a href="#testing" id="testing"></a>

The `test` backend is a password-less variation of the `file` backend. Keys are stored **unencrypted** on disk. This keyring is provided for testing purposes only. Use at your own risk!

#### In Memory[​](broken://pages/DNEGCMcw2QSkhPz7pDwa) <a href="#in-memory" id="in-memory"></a>

The `memory` backend stores keys in memory. The keys are immediately deleted after the program has exited.

danger

**IMPORTANT**: Provided for testing purposes only. The `memory` backend is **not** recommended for use in production environments. Use at your own risk!


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.lagomchain.com/concepts/keyring.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
