evmos · fedekunze · Mar 29, 2022 · Mar 29, 2022 · Mar 29, 2022
@@ -10,25 +10,43 @@ The keyring holds the private/public keypairs used to interact with the node. Fo
 
 ## Add keys
 
-You can use `evmosd keys` for help with the keys command and `evmosd keys [command] --help` for more information about a particular subcommand.
+You can use the following commands for help with the `keys` command and for more information about a particular subcommand, respectively:
 
-To create a new key in the keyring, run the `add` subcommand with a `<key_name>` argument. For the purpose of this tutorial, we will solely use the `test` backend, and call our new key `mykey`. This key will be used in the next section.
+```bash
+evmosd keys
+```
 
 ```bash
-evmosd keys add mykey --keyring-backend test
+evmosd 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.
+
+```bash
+evmosd keys add mykey
 
 # Put the generated address in a variable for later use.
-MY_VALIDATOR_ADDRESS=$(evmosd keys show mykey -a --keyring-backend test)
+MY_VALIDATOR_ADDRESS=$(evmosd keys show mykey -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` keypair. 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.
+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.
+
+::: warning
+**NOTE**: Cosmos `secp256k1` keys are not supported on Evmos due to compatibility issues with Ethereum transactions.
+:::
 
 ## Keyring Backends
 
 ### OS
 
+::: 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
@@ -46,10 +64,6 @@ commonly provided with [KDE Wallet Manager](https://userbase.kde.org/KDE_Wallet_
 Whilst the former is in fact a `libsecret` convenient frontend, the latter is a `kwallet`
 client.
 
-`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 recommended backends for headless environments are `file` and `pass`.
 
 ### File
@@ -81,7 +95,7 @@ operating systems as well as GNU/Linux distributions. Please refer to its manual
 information on how to download and install it.
 
 ::: tip
-**pass** uses [GnuPG](https://gnupg.org/) for encryption. `gpg` automatically invokes the `gpg-agent`
+**`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.
@@ -106,16 +120,18 @@ information.
 ### Testing
 
 The `test` backend is a password-less variation of the `file` backend. Keys are stored
-**unencrypted** on disk.
+**unencrypted** on disk. This keyring is provided for <u>testing purposes only</u>. Use at your own risk!
 
-:::danger
-Provided for testing purposes only. The `test` backend is **NOT** recommended for use in production environments.
+::: danger
+🚨 **DANGER**: <u>Never</u> create your mainnet validator keys using a `test` keying backend. Doing so might result in a loss of funds by making your funds remotely accessible via the `eth_sendTransaction` JSON-RPC endpoint.
+
+Ref: [Security Advisory: Insecurely configured geth can make funds remotely accessible](https://blog.ethereum.org/2015/08/29/security-alert-insecurely-configured-geth-can-make-funds-remotely-accessible/)
 :::
 
 ### In Memory
 
 The `memory` backend stores keys in memory. The keys are immediately deleted after the program has exited.
 
 :::danger
-Provided for testing purposes only. The `memory` backend is **NOT** recommended for use in production environments.
+**IMPORTANT**: Provided for testing purposes only. The `memory` backend is **not** recommended for use in production environments. Use at your own risk!
 :::
@@ -74,7 +74,7 @@ Close the `Settings`, go to `My Accounts` (top right circle) and select `Import
 Now you can export your private key from the terminal using the following command. Again, make sure to replace `mykey` with the name of the key that you want to export and use the correct `keyring-backend`:
 
 ```bash
-evmosd keys unsafe-export-eth-key mykey --keyring-backend test
+evmosd keys unsafe-export-eth-key mykey
 ```
 
 Go back to the browser and select the `Private Key` option. Then paste the private key exported from the `unsafe-export-eth-key` command.

@@ -15,7 +15,7 @@ You can customize the local testnet script by changing values for convenience fo
 ```bash
 # customize the name of your key, the chain-id, moniker of the node, keyring backend, and log level
 KEY="mykey"
-CHAINID="evmos_9000-2"
+CHAINID="evmos_9000-3"
 MONIKER="localtestnet"
 KEYRING="test"
 LOGLEVEL="info"
@@ -48,7 +48,7 @@ Before actually running the node, we need to initialize the chain, and most impo
 ```bash
 $MONIKER=testing
 $KEY=mykey
-$CHAINID="evmos_9000-2"
+$CHAINID="evmos_9000-3"
 
 # The argument $MONIKER is the custom username of your node, it should be human-readable.
 evmosd init $MONIKER --chain-id=$CHAINID
@@ -67,13 +67,13 @@ The command above creates all the configuration files needed for your node and v
 Before starting the chain, you need to populate the state with at least one account using the [keyring](./../keys-wallets/keyring.md#add-keys):
 
 ```bash
-evmosd keys add my_validator --keyring-backend=test
+evmosd keys add my_validator
 ```
 
 Once you have created a local account, go ahead and grant it some `aevmos` tokens in your chain's genesis file. Doing so will also make sure your chain is aware of this account's existence:
 
 ```bash
-evmosd add-genesis-account my_validator 10000000000aevmos --keyring-backend test
+evmosd add-genesis-account my_validator 10000000000aevmos
 ```
 
 Now that your account has some tokens, you need to add a validator to your chain.

@@ -80,7 +80,7 @@ evmosd status
 Import the key from the provided mnemonic:
 
 ```bash
-evmosd keys add test --recover --keyring-backend test
+evmosd keys add test --recover
 ```
 
 Check the balance of the account address:

@@ -61,11 +61,17 @@ evmosd tx staking create-validator
     --commission-max-change-rate="0.01"
     --min-self-delegation "1"
     --moniker "validator"
-    --chain-id "evmos_9000-2"
+    --chain-id "evmos_9000-3"
     --gas auto
     --node tcp://127.0.0.1:26647
 ```
 
+::: danger
+🚨 **DANGER**: <u>Never</u> create your mainnet validator keys using a [`test`](./../keys-wallets/keyring.md#testing) keying backend. Doing so might result in a loss of funds by making your funds remotely accessible via the `eth_sendTransaction` JSON-RPC endpoint.
+
+Ref: [Security Advisory: Insecurely configured geth can make funds remotely accessible](https://blog.ethereum.org/2015/08/29/security-alert-insecurely-configured-geth-can-make-funds-remotely-accessible/)
+:::
+
 Once a validator is created and registered, EVMOS holders can delegate EVMOS to it, effectively adding stake to its pool. The total stake of a validator is the sum of the EVMOS self-bonded by the validator's operator and the EVMOS bonded by external delegators.
 
 **Only the top 150 validators with the most stake are considered the active validators**, becoming **bonded validators**. If ever a validator's total stake dips below the top 150, the validator loses its validator privileges (meaning that it won't generate rewards) and no longer serves as part of the active set (i.e doesn't participate in consensus), entering **unbonding mode** and eventually becomes **unbonded**.

@@ -31,10 +31,10 @@ architecture.
 
 To run testnet nodes, you will need a machine with the following minimum hardware requirements:
 
-- 4 or more physical CPU cores
-- At least 500GB of SSD disk storage
-- At least 32GB of memory (RAM)
-- At least 100mbps network bandwidth
+* 4 or more physical CPU cores
+* At least 500GB of SSD disk storage
+* At least 32GB of memory (RAM)
+* At least 100mbps network bandwidth
 
 As the usage of the blockchain grows, the server requirements may increase as well, so you should have a plan for updating your server as well.
 
@@ -46,6 +46,12 @@ Your `evmosvalconspub` can be used to create a new validator by staking tokens.
 evmosd tendermint show-validator
 ```
 
+::: danger
+🚨 **DANGER**: <u>Never</u> create your mainnet validator keys using a [`test`](./../keys-wallets/keyring.md#testing) keying backend. Doing so might result in a loss of funds by making your funds remotely accessible via the `eth_sendTransaction` JSON-RPC endpoint.
+
+Ref: [Security Advisory: Insecurely configured geth can make funds remotely accessible](https://blog.ethereum.org/2015/08/29/security-alert-insecurely-configured-geth-can-make-funds-remotely-accessible/)
+:::
+
 To create your validator, just use the following command:
 
 ```bash
@@ -127,11 +133,11 @@ evmosd tx staking edit-validator
   --commission-rate="0.10"
 ```
 
-__Note__: The `commission-rate` value must adhere to the following invariants:
+**Note**: The `commission-rate` value must adhere to the following invariants:
 
-- Must be between 0 and the validator's `commission-max-rate`
-- Must not exceed the validator's `commission-max-change-rate` which is maximum
-  % point change rate __per day__. In other words, a validator can only change
+* Must be between 0 and the validator's `commission-max-rate`
+* Must not exceed the validator's `commission-max-change-rate` which is maximum
+  % point change rate **per day**. In other words, a validator can only change
   its commission once per day and within `commission-max-change-rate` bounds.
 
 ## View Validator Description

@@ -134,6 +134,12 @@ evmosd tx staking create-validator \
   --from=<key_name>
 ```
 
+::: danger
+🚨 **DANGER**: <u>Never</u> create your validator keys using a [`test`](./../guides/keys-wallets/keyring.md#testing) keying backend. Doing so might result in a loss of funds by making your funds remotely accessible via the `eth_sendTransaction` JSON-RPC endpoint.
+
+Ref: [Security Advisory: Insecurely configured geth can make funds remotely accessible](https://blog.ethereum.org/2015/08/29/security-alert-insecurely-configured-geth-can-make-funds-remotely-accessible/)
+:::
+
 ## Start mainnet
 
 The final step is to [start the nodes](./../quickstart/run_node#start-node). Once enough voting power (+2/3) from the genesis validators is up-and-running, the node will start producing blocks.

@@ -109,13 +109,13 @@ evmosd config
 
 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 identifier can be changed to `evmos_9000-2` from a blank name by using:
+For example, the chain identifier can be changed to `evmos_9000-3` from a blank name by using:
 
 ```bash
-evmosd config "chain-id" evmos_9000-2
+evmosd config "chain-id" evmos_9000-3
 evmosd config
 {
- "chain-id": "evmos_9000-2",
+ "chain-id": "evmos_9000-3",
  "keyring-backend": "os",
  "output": "text",
  "node": "tcp://localhost:26657",
@@ -135,7 +135,7 @@ Alternatively, we can directly make the changes to the config values in one plac
 
 # The network chain ID
 
-chain-id = "evmos_9000-2"
+chain-id = "evmos_9000-3"
 
 # The keyring's backend, where the keys are stored (os|file|kwallet|pass|test|memory)
 
@@ -171,19 +171,19 @@ evmosd config
 
 A list of commonly used flags of `evmosd` is listed below:
 
-| Option              | Description                   | Type         | Default Value   |
-|---------------------|-------------------------------|--------------|-----------------|
-| `--chain-id`        | Full Chain ID                 | String       | ---             |
-| `--home`            | Directory for config and data | string       | `~/.evmosd`     |
-| `--keyring-backend` | Select keyring's backend      | os/file/test | os              |
-| `--output`          | Output format                 | string       | "text"          |
+| Option              | Description                   | Type                                             | Default Value |
+| ------------------- | ----------------------------- | ------------------------------------------------ | ------------- |
+| `--chain-id`        | Full Chain ID                 | `string`                                         | `""`          |
+| `--home`            | Directory for config and data | `string`                                         | `~/.evmosd`   |
+| `--keyring-backend` | Select keyring's backend      | `{"os"|"file"|"kwallet"|"pass"|"test"|"memory"}` | `"os"`        |
+| `--output`          | Output format                 | `string`                                         | "text"        |
 
 ## Command list
 
 A list of commonly used `evmosd` commands. You can obtain the full list by using the `evmosd -h` command.
 
 | Command      | Description              | Subcommands (example)                                                     |
-|--------------|--------------------------|---------------------------------------------------------------------------|
+| ------------ | ------------------------ | ------------------------------------------------------------------------- |
 | `keys`       | Keys management          | `list`, `show`, `add`, `add  --recover`, `delete`                         |
 | `tx`         | Transactions subcommands | `bank send`, `ibc-transfer transfer`, `distribution withdraw-all-rewards` |
 | `query`      | Query subcommands        | `bank balance`, `staking validators`, `gov proposals`                     |