From e5bf42a4088742264fc630c2a20f958506ecb922 Mon Sep 17 00:00:00 2001
From: Timax <83237728+TimaxLacs@users.noreply.github.com>
Date: Wed, 31 Jan 2024 05:44:13 +0300
Subject: [PATCH 1/3] Update README.md

---
 README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.md b/README.md
index afa2f1f4..fbe8812a 100644
--- a/README.md
+++ b/README.md
@@ -1,4 +1,4 @@
-# DEEPCHAIN
+# DEEPCHAIN.
 # DEEP CYBER HACKATHON January 2024
 
 

From 2438a84ec30cc71ae70285b34fd0c580710dac3a Mon Sep 17 00:00:00 2001
From: Your Name <timshak@gmail.com>
Date: Wed, 31 Jan 2024 07:32:14 +0300
Subject: [PATCH 2/3] commit message

---
 README.md                         |   12 +-
 docs/README.md                    |   46 +-
 docs/cyber_Ledger_guide.md        |  138 +--
 docs/keystore.md                  |  232 ++---
 docs/multisig_guide.md            |  192 ++--
 docs/port_forwarding_guide.md     |  166 +--
 docs/rpc.md                       |  378 +++----
 docs/run_validator.md             |  836 +++++++--------
 docs/setup_cyber_configuration.md |  568 +++++-----
 docs/setup_dev_env.md             |  602 +++++------
 docs/supported_gpu_list.md        |   68 +-
 docs/ultimate-commands-guide.md   | 1624 ++++++++++++++---------------
 12 files changed, 2431 insertions(+), 2431 deletions(-)

diff --git a/README.md b/README.md
index fbe8812a..74ccaaf2 100644
--- a/README.md
+++ b/README.md
@@ -1,4 +1,4 @@
-# DEEPCHAIN.
+# DEEPCHAIN
 # DEEP CYBER HACKATHON January 2024
 
 
@@ -115,7 +115,7 @@ Genesis: [QmYubyVNfghD4xCrTFj26zBwrF9s5GJhi1TmxvrwmJCipr](http://cloudflare-ipfs
 
 Build: ```make install```
 
-Run: ```cyber start ```
+Run: ```deepchain start ```
 
 To use as CLI with remote node:
 ```
@@ -158,19 +158,19 @@ _________________________________________________________
 
 ### Follow Hero and get HYDROGEN:
 ```
-cyber tx staking delegate bostromvaloper1hmkqhy8ygl6tnl5g8tc503rwrmmrkjcqf92r73 1000000000boot --from <name> --chain-id bostrom --gas 200000 --gas-prices 0.01boot --yes --node https://rpc.bostrom.cybernode.ai:443   
+deepchain tx staking delegate bostromvaloper1hmkqhy8ygl6tnl5g8tc503rwrmmrkjcqf92r73 1000000000boot --from <name> --chain-id deep --gas 200000 --gas-prices 0.01boot --yes --node https://rpc.bostrom.cybernode.ai:443   
 ```
 
 ### Investmint HYDROGEN to get resources:
 ```
-cyber tx resources investmint 1000000000hydrogen millivolt 86400 --from <name> --chain-id bostrom --gas 200000 --gas-prices 0.01boot --yes --node https://rpc.bostrom.cybernode.ai:443
+deepchain tx resources investmint 1000000000hydrogen millivolt 86400 --from <name> --chain-id deep --gas 200000 --gas-prices 0.01boot --yes --node https://rpc.bostrom.cybernode.ai:443
 
-cyber tx resources investmint 1000000000hydrogen milliampere 86400 --from <name> --chain-id bostrom --gas 200000 --gas-prices 0.01boot --yes --node https://rpc.bostrom.cybernode.ai:443
+deepchain tx resources investmint 1000000000hydrogen milliampere 86400 --from <name> --chain-id deep --gas 200000 --gas-prices 0.01boot --yes --node https://rpc.bostrom.cybernode.ai:443
 ```
 
 ### Cyberlink and Search:
 ```
-cyber tx graph cyberlink QmdVWtX17m7UvF8FcvNLTJxcpxv2fSJd7Z3VBoYxxW9Qpu Qmb9xPYYwHt1F3bQysKCZzXRzAT8QLvAyMe5DyPy4rene8 --from <name> --chain-id bostrom --yes --node https://rpc.bostrom.cybernode.ai:443
+deepchain tx graph cyberlink QmdVWtX17m7UvF8FcvNLTJxcpxv2fSJd7Z3VBoYxxW9Qpu Qmb9xPYYwHt1F3bQysKCZzXRzAT8QLvAyMe5DyPy4rene8 --from <name> --chain-id deep --yes --node https://rpc.bostrom.cybernode.ai:443
 
 curl https://lcd.bostrom.cybernode.ai/rank/search?cid=QmdVWtX17m7UvF8FcvNLTJxcpxv2fSJd7Z3VBoYxxW9Qpu
 ```
diff --git a/docs/README.md b/docs/README.md
index e66f7c30..812bf010 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -1,24 +1,24 @@
-# Documentation [WIP]
-
-## Contents
-
-1. **[Run validator guide](run_validator.md)**
-2. **[Use CLI guide](ultimate-commands-guide.md)**
-3. **[Setup daemon config guide](setup_cyber_configuration.md)**
-4. **[Setup local dev environment guide](setup_dev_env.md)**
-5. **Deploy contract guide**
-6. **Create proposal guide**
-7. **[Supported GPUs list](supported_gpu_list.md)**
-8. **Network upgrade guide**
-9. **[Keystore guide](keystore.md)**
-10. **[Multisig guide](multisig_guide.md)**
-11. **[Ledger guide](cyber_Ledger_guide.md)**
-12. **Tendermint KMS guide**
-13. **Modules documentation**
-    - **graph**
-    - **rank**
-    - **[bandwidth](../x/bandwidth/spec/README.md)**
-    - **[cyberbank](../x/cyberbank/spec/README.md)**
-    - **[resources](../x/resources/spec/README.md)**
-    - **dmn**
+# Documentation [WIP]
+
+## Contents
+
+1. **[Run validator guide](run_validator.md)**
+2. **[Use CLI guide](ultimate-commands-guide.md)**
+3. **[Setup daemon config guide](setup_cyber_configuration.md)**
+4. **[Setup local dev environment guide](setup_dev_env.md)**
+5. **Deploy contract guide**
+6. **Create proposal guide**
+7. **[Supported GPUs list](supported_gpu_list.md)**
+8. **Network upgrade guide**
+9. **[Keystore guide](keystore.md)**
+10. **[Multisig guide](multisig_guide.md)**
+11. **[Ledger guide](cyber_Ledger_guide.md)**
+12. **Tendermint KMS guide**
+13. **Modules documentation**
+    - **graph**
+    - **rank**
+    - **[bandwidth](../x/bandwidth/spec/README.md)**
+    - **[cyberbank](../x/cyberbank/spec/README.md)**
+    - **[resources](../x/resources/spec/README.md)**
+    - **dmn**
     - **staking**
\ No newline at end of file
diff --git a/docs/cyber_Ledger_guide.md b/docs/cyber_Ledger_guide.md
index b287422b..22835ce3 100644
--- a/docs/cyber_Ledger_guide.md
+++ b/docs/cyber_Ledger_guide.md
@@ -1,69 +1,69 @@
-# Ledger nano Support
-
-It is possible to use your Ledger device with cyber to store keys and sign transactions.
-
-## Cyberd CLI & Ledger Nano
-
-How to get started. First of all, you'll need a couple of things to be done:
-
-+ A running and synced cyber node (how to: [here](https://github.com/cybercongress/go-cyber/blob/bostrom-dev/docs/run_validator.md) and [here](https://github.com/cybercongress/go-cyber/blob/main/docs/ultimate-commands-guide.md))
-
-+ [Setup](https://support.ledger.com/hc/en-us/articles/360000613793-Set-up-as-new-device) your Ledger device and [install Cosmos app on it](https://github.com/cosmos/ledger-cosmos/blob/master/README.md#installing) (the latest firmware for Ledger and Cosmos app required)
-
-It is necessary to verify that cyber is built with netgo and Ledger tags. To check that, we can run: `cyber version --long`.
-
-## Add your Ledger key
-
-If you have set up your Ledger device on a different machine then the one running cyber, it is necessary to make sure that the Ledger device is generally working on this machine. A great way to do so is installing [Ledger Live](https://shop.ledger.com/pages/ledger-live) on the machine and trying to connect your Ledger device to it. This will show possible issues and error codes to work with ([Fix connection issues](https://support.ledger.com/hc/en-us/articles/115005165269-Fix-connection-issues) guide from Ledger).
-When you made sure that your Ledger device is successfully interacting with your machine do the following:
-
-+ Connect and unlock your Ledger device
-+ Open the Cosmos app on your Ledger
-+ Create an account in cyber from your Ledger key
-
-For account creation run:
-
-``` js
-cyber keys add <your_key_name> --ledger
-```
-
-After submitting this command your Ledger device should show a generated address and will wait for confirmation. Hit confirm the button and in the console, you'll see the following output:
-
-``` js
-- name: <your_key_name>
-  type: ledger
-  address: cyber1gw5kdey7fs9wvh05w66s034s24tjdvxcp5fhkz
-  pubkey: cyberpub1addwnpepq0lfpdumac47nyel06u95czd4026ahzmjr8stsx4h65kw3dhh60py0m7k6r
-  mnemonic: ""
-  threshold: 0
-  pubkeys: []
-  ```
-
-By default, the `...keys add` command with account and index set to 0 of [bip44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) derivation path is used. To add more than one key account and/or index it must be specified separately in the following way:
-
-``` js
-cyber keys add <your_key2_name> --ledger --account 1 --index 1
-```
-
-You don't need to remember which numbers for account and index you've used, it will be matched to <your_key_name> automatically.
-
-## Confirm your address
-
-To make sure you have added everything correctly just run:
-
-``` js
-cyber keys show <key_name> -d
-```
-
-It's necessary to confirm that the key on your Ledger matches the one shown in the console.
-
-## Signing transactions
-
-You are now ready to sign and send transactions. This could be done by using the `tx bank send` command. Your Ledger device should be connected and unlocked at this step. Run the following to send some CYB tokens:
-
-``` js
-cyber tx bank send <from_key_name> <destination_address> <ammount>cyb --chain-id <current_chain_id>
-```
-
-`<from_key_name>` is your ledger key name, `<destination_address>` is the address of the recipient in the following format: `cyber1wq7p5qfygxr37vqqufhj5fzwlg55zmm4w0p8sw`.
-When prompted with `confirm transaction before signing`, answer Y. Your Ledger will ask to approve the transaction. Make sure you'll inspect the transaction JSON before signing it. When the transaction is signed on the Ledger, usually, the output will show up in the console.
+# Ledger nano Support
+
+It is possible to use your Ledger device with cyber to store keys and sign transactions.
+
+## Cyberd CLI & Ledger Nano
+
+How to get started. First of all, you'll need a couple of things to be done:
+
++ A running and synced cyber node (how to: [here](https://github.com/cybercongress/go-cyber/blob/bostrom-dev/docs/run_validator.md) and [here](https://github.com/cybercongress/go-cyber/blob/main/docs/ultimate-commands-guide.md))
+
++ [Setup](https://support.ledger.com/hc/en-us/articles/360000613793-Set-up-as-new-device) your Ledger device and [install Cosmos app on it](https://github.com/cosmos/ledger-cosmos/blob/master/README.md#installing) (the latest firmware for Ledger and Cosmos app required)
+
+It is necessary to verify that cyber is built with netgo and Ledger tags. To check that, we can run: `cyber version --long`.
+
+## Add your Ledger key
+
+If you have set up your Ledger device on a different machine then the one running cyber, it is necessary to make sure that the Ledger device is generally working on this machine. A great way to do so is installing [Ledger Live](https://shop.ledger.com/pages/ledger-live) on the machine and trying to connect your Ledger device to it. This will show possible issues and error codes to work with ([Fix connection issues](https://support.ledger.com/hc/en-us/articles/115005165269-Fix-connection-issues) guide from Ledger).
+When you made sure that your Ledger device is successfully interacting with your machine do the following:
+
++ Connect and unlock your Ledger device
++ Open the Cosmos app on your Ledger
++ Create an account in cyber from your Ledger key
+
+For account creation run:
+
+``` js
+cyber keys add <your_key_name> --ledger
+```
+
+After submitting this command your Ledger device should show a generated address and will wait for confirmation. Hit confirm the button and in the console, you'll see the following output:
+
+``` js
+- name: <your_key_name>
+  type: ledger
+  address: cyber1gw5kdey7fs9wvh05w66s034s24tjdvxcp5fhkz
+  pubkey: cyberpub1addwnpepq0lfpdumac47nyel06u95czd4026ahzmjr8stsx4h65kw3dhh60py0m7k6r
+  mnemonic: ""
+  threshold: 0
+  pubkeys: []
+  ```
+
+By default, the `...keys add` command with account and index set to 0 of [bip44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) derivation path is used. To add more than one key account and/or index it must be specified separately in the following way:
+
+``` js
+cyber keys add <your_key2_name> --ledger --account 1 --index 1
+```
+
+You don't need to remember which numbers for account and index you've used, it will be matched to <your_key_name> automatically.
+
+## Confirm your address
+
+To make sure you have added everything correctly just run:
+
+``` js
+cyber keys show <key_name> -d
+```
+
+It's necessary to confirm that the key on your Ledger matches the one shown in the console.
+
+## Signing transactions
+
+You are now ready to sign and send transactions. This could be done by using the `tx bank send` command. Your Ledger device should be connected and unlocked at this step. Run the following to send some CYB tokens:
+
+``` js
+cyber tx bank send <from_key_name> <destination_address> <ammount>cyb --chain-id <current_chain_id>
+```
+
+`<from_key_name>` is your ledger key name, `<destination_address>` is the address of the recipient in the following format: `cyber1wq7p5qfygxr37vqqufhj5fzwlg55zmm4w0p8sw`.
+When prompted with `confirm transaction before signing`, answer Y. Your Ledger will ask to approve the transaction. Make sure you'll inspect the transaction JSON before signing it. When the transaction is signed on the Ledger, usually, the output will show up in the console.
diff --git a/docs/keystore.md b/docs/keystore.md
index 8675f763..2f450c2c 100644
--- a/docs/keystore.md
+++ b/docs/keystore.md
@@ -1,116 +1,116 @@
-# Keystore management
-
-## Key types
-
-Key types can be conditionally divided into two groups: **agents** and **validators**.
-
-**Agents** keys are used for linking content, sending liquid tokens, delegating, redelegating, and undelegating tokens to validators. Also, withdrawing rewards, voting and creating multisig accounts.
-
-- `bostrom` a.k.a. address. Cyber application key.
-  - Derived from account mnemonic phrase, generated by `cyber keys add`
-  - e.g. `bostrom 15h6vd5f0wqps26zjlwrc6chah08ryu4hzzdwhc`
-
-- `bostrom pub` the public key of an account address. It is used for generating multisig addresses.  
-  - Derived from account mnemonic phrase, generated by `cyber keys add`
-  - e.g. `bostrom pub1zcjduc3q7fu03jnlu2xpl75s2nkt7krm6grh4cc5aqth73v0zwmea25wj2hsqhlqzm`
-
-All agents keypairs are stored locally in the `PATH_TO_CYBER/keys` folder. 
-
-**Validators** are actors on the network committing new blocks by submitting their votes. This refers to the node itself, not a single person or a single account. Therefore, the public key here is referring to the nodes public key, not the public key of the agent address.
-
-- `bostrom valoper` validator application-level address. It is associated with a public key `bostrom valconspub`. This is the address used to identify your validator publicly. The private key associated with this address is used to delegate, unbond, claim rewards, and participate in governance. Generated by cyber on the application level. Application keys are associated with a public key prefixed by `bostrom pub` and an address prefixed by cyber  network. Both are derived from account keys generated by cyber keys add. 
-  - e.g. `bostrom valoper1carzvgq3e6y3z5kz5y6gxp3wpy3qdrv928vyah`
-
--  the public key of node/validator address has been recently migrated to protobuf look. The private key associated with this Tendermint PubKey is used to sign prevotes and precommits.
-  - Generated when the node is created
-  - Get this value with `cyber tendermint show-validator`
-  - e.g. `{"@type":"/cosmos.crypto.ed25519.PubKey","key":"YxN/kkQlXBwKNF4Cgi6tiqMh2ae8+tpo9VxENmFUhv8="}`
-
-> Note: A validator's operator key is directly tied to an application key, but uses reserved prefixes solely for this purpose: `bostrom valoper`.
-
-A nodes keypair is stored in `node_key.json` and `priv_validator_key.json` at `$HOME/.cyber/config` folder. You can delete them and restart `cyber ` if you want to change this keypair. The new pair will be created automatically.
-
-## Generate keys
-
-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:
-
-```bash
-cyber keys add <account_name>
-```
-
-Next, you will have to create a passphrase to protect the key on disk. The output of the above
-the 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:
-
-```bash
-cyber keys add <account_name> --recover
-```
-
-Also, you can import your Cosmos account to `cyber cli` using seed phrase:
-
-```bash
-cyber keys add <account_name> --recover 
-```
-
-cyber provides compatibility of Cosmos with Cyber addresses.
-
-You can check your application account details by account name:
-
-```bash
-cyber keys show <account_name>
-```
-
-You can see all of your available keys by typing:
-
-```bash
-cyber keys list
-```
-
-View the validator pubkey for your node by typing:
-
-```bash
-cyber tendermint show-validator
-```
-
-Note that this is the Tendermint signing key, _not_ the operator key you will use in delegation transactions.
-
-
-**Important note**: Starting with v.38 cosmos-SDK uses os-native keyring to store all your keys. We've noticed that in certain cases this does not work well by default (for example if you don't have any GUI installed on your machine). If during the execution of the `cyber keys add` command you get this type of error:
-
-```bash
-panic: No such interface 'org.freedesktop.DBus.Properties' on object at path /
-
-goroutine 1 [running]:
-github.com/cosmos/cosmos-sdk/crypto/keys.keyringKeybase.writeInfo(0x1307a18, 0x1307a10, 0xc000b37160, 0x1, 0x1, 0xc000b37170, 0x1, 0x1, 0x147a6c0, 0xc000f1c780, ...)
-    /root/go/pkg/mod/github.com/cosmos/cosmos-sdk@v0.38.1/crypto/keys/keyring.go:479 +0x38c
-github.com/cosmos/cosmos-sdk/crypto/keys.keyringKeybase.writeLocalKey(0x1307a18, 0x1307a10, 0xc000b37160, 0x1, 0x1, 0xc000b37170, 0x1, 0x1, 0x147a6c0, 0xc000f1c780, ...)
-    /root/go/pkg/mod/github.com/cosmos/cosmos-sdk@v0.38.1/crypto/keys/keyring.go:465 +0x189
-github.com/cosmos/cosmos-sdk/crypto/keys.baseKeybase.CreateAccount(0x1307a18, 0x1307a10, 0xc000b37160, 0x1, 0x1, 0xc000b37170, 0x1, 0x1, 0x146aa00, 0xc000b15630, ...)
-    /root/go/pkg/mod/github.com/cosmos/cosmos-sdk@v0.38.1/crypto/keys/keybase_base.go:171 +0x192
-github.com/cosmos/cosmos-sdk/crypto/keys.keyringKeybase.CreateAccount(...)
-    /root/go/pkg/mod/github.com/cosmos/cosmos-sdk@v0.38.1/crypto/keys/keyring.go:107
-github.com/cosmos/cosmos-sdk/client/keys.RunAddCmd(0xc000f0b400, 0xc000f125f0, 0x1, 0x1, 0x148dcc0, 0xc000aca550, 0xc000ea75c0, 0xc000ae1c08, 0x5e93b7)
-    /root/go/pkg/mod/github.com/cosmos/cosmos-sdk@v0.38.1/client/keys/add.go:273 +0xa8b
-... etc
-```
-
-You will have to use another keyring backend to keep your keys. Here are 2 options: store the files within the cli folder or a `pass` manager.
-
-Using the keyring backend as a **local file**:
-
-Execute:
-
-```bash
-cyber keys add <key_name> keyring-backend file
-```
-
-This means that you've saved your keyring-backend to a local file. *Note*, in this case, all the keys in your keyring will be encrypted using the same password. If you would like to set up a unique password for each key, you should set a unique `--home` folder for each key. To do that, just use `--home=/<unique_path_to_key_folder>/` with setup keyring backend and at all interactions with keys when using cyber cli:
-
-```bash
-cyber config keyring-backend file --home=/<unique_path_to_key_folder>/
-cyber keys add <your_second_key_name> --home=/<unique_path_to_key_folder>/
-cyber keys list --home=/<unique_path_to_key_folder>/
-```
+# Keystore management
+
+## Key types
+
+Key types can be conditionally divided into two groups: **agents** and **validators**.
+
+**Agents** keys are used for linking content, sending liquid tokens, delegating, redelegating, and undelegating tokens to validators. Also, withdrawing rewards, voting and creating multisig accounts.
+
+- `bostrom` a.k.a. address. Cyber application key.
+  - Derived from account mnemonic phrase, generated by `cyber keys add`
+  - e.g. `bostrom 15h6vd5f0wqps26zjlwrc6chah08ryu4hzzdwhc`
+
+- `bostrom pub` the public key of an account address. It is used for generating multisig addresses.  
+  - Derived from account mnemonic phrase, generated by `cyber keys add`
+  - e.g. `bostrom pub1zcjduc3q7fu03jnlu2xpl75s2nkt7krm6grh4cc5aqth73v0zwmea25wj2hsqhlqzm`
+
+All agents keypairs are stored locally in the `PATH_TO_CYBER/keys` folder. 
+
+**Validators** are actors on the network committing new blocks by submitting their votes. This refers to the node itself, not a single person or a single account. Therefore, the public key here is referring to the nodes public key, not the public key of the agent address.
+
+- `bostrom valoper` validator application-level address. It is associated with a public key `bostrom valconspub`. This is the address used to identify your validator publicly. The private key associated with this address is used to delegate, unbond, claim rewards, and participate in governance. Generated by cyber on the application level. Application keys are associated with a public key prefixed by `bostrom pub` and an address prefixed by cyber  network. Both are derived from account keys generated by cyber keys add. 
+  - e.g. `bostrom valoper1carzvgq3e6y3z5kz5y6gxp3wpy3qdrv928vyah`
+
+-  the public key of node/validator address has been recently migrated to protobuf look. The private key associated with this Tendermint PubKey is used to sign prevotes and precommits.
+  - Generated when the node is created
+  - Get this value with `cyber tendermint show-validator`
+  - e.g. `{"@type":"/cosmos.crypto.ed25519.PubKey","key":"YxN/kkQlXBwKNF4Cgi6tiqMh2ae8+tpo9VxENmFUhv8="}`
+
+> Note: A validator's operator key is directly tied to an application key, but uses reserved prefixes solely for this purpose: `bostrom valoper`.
+
+A nodes keypair is stored in `node_key.json` and `priv_validator_key.json` at `$HOME/.cyber/config` folder. You can delete them and restart `cyber ` if you want to change this keypair. The new pair will be created automatically.
+
+## Generate keys
+
+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:
+
+```bash
+cyber keys add <account_name>
+```
+
+Next, you will have to create a passphrase to protect the key on disk. The output of the above
+the 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:
+
+```bash
+cyber keys add <account_name> --recover
+```
+
+Also, you can import your Cosmos account to `cyber cli` using seed phrase:
+
+```bash
+cyber keys add <account_name> --recover 
+```
+
+cyber provides compatibility of Cosmos with Cyber addresses.
+
+You can check your application account details by account name:
+
+```bash
+cyber keys show <account_name>
+```
+
+You can see all of your available keys by typing:
+
+```bash
+cyber keys list
+```
+
+View the validator pubkey for your node by typing:
+
+```bash
+cyber tendermint show-validator
+```
+
+Note that this is the Tendermint signing key, _not_ the operator key you will use in delegation transactions.
+
+
+**Important note**: Starting with v.38 cosmos-SDK uses os-native keyring to store all your keys. We've noticed that in certain cases this does not work well by default (for example if you don't have any GUI installed on your machine). If during the execution of the `cyber keys add` command you get this type of error:
+
+```bash
+panic: No such interface 'org.freedesktop.DBus.Properties' on object at path /
+
+goroutine 1 [running]:
+github.com/cosmos/cosmos-sdk/crypto/keys.keyringKeybase.writeInfo(0x1307a18, 0x1307a10, 0xc000b37160, 0x1, 0x1, 0xc000b37170, 0x1, 0x1, 0x147a6c0, 0xc000f1c780, ...)
+    /root/go/pkg/mod/github.com/cosmos/cosmos-sdk@v0.38.1/crypto/keys/keyring.go:479 +0x38c
+github.com/cosmos/cosmos-sdk/crypto/keys.keyringKeybase.writeLocalKey(0x1307a18, 0x1307a10, 0xc000b37160, 0x1, 0x1, 0xc000b37170, 0x1, 0x1, 0x147a6c0, 0xc000f1c780, ...)
+    /root/go/pkg/mod/github.com/cosmos/cosmos-sdk@v0.38.1/crypto/keys/keyring.go:465 +0x189
+github.com/cosmos/cosmos-sdk/crypto/keys.baseKeybase.CreateAccount(0x1307a18, 0x1307a10, 0xc000b37160, 0x1, 0x1, 0xc000b37170, 0x1, 0x1, 0x146aa00, 0xc000b15630, ...)
+    /root/go/pkg/mod/github.com/cosmos/cosmos-sdk@v0.38.1/crypto/keys/keybase_base.go:171 +0x192
+github.com/cosmos/cosmos-sdk/crypto/keys.keyringKeybase.CreateAccount(...)
+    /root/go/pkg/mod/github.com/cosmos/cosmos-sdk@v0.38.1/crypto/keys/keyring.go:107
+github.com/cosmos/cosmos-sdk/client/keys.RunAddCmd(0xc000f0b400, 0xc000f125f0, 0x1, 0x1, 0x148dcc0, 0xc000aca550, 0xc000ea75c0, 0xc000ae1c08, 0x5e93b7)
+    /root/go/pkg/mod/github.com/cosmos/cosmos-sdk@v0.38.1/client/keys/add.go:273 +0xa8b
+... etc
+```
+
+You will have to use another keyring backend to keep your keys. Here are 2 options: store the files within the cli folder or a `pass` manager.
+
+Using the keyring backend as a **local file**:
+
+Execute:
+
+```bash
+cyber keys add <key_name> keyring-backend file
+```
+
+This means that you've saved your keyring-backend to a local file. *Note*, in this case, all the keys in your keyring will be encrypted using the same password. If you would like to set up a unique password for each key, you should set a unique `--home` folder for each key. To do that, just use `--home=/<unique_path_to_key_folder>/` with setup keyring backend and at all interactions with keys when using cyber cli:
+
+```bash
+cyber config keyring-backend file --home=/<unique_path_to_key_folder>/
+cyber keys add <your_second_key_name> --home=/<unique_path_to_key_folder>/
+cyber keys list --home=/<unique_path_to_key_folder>/
+```
diff --git a/docs/multisig_guide.md b/docs/multisig_guide.md
index 0b30df18..df5bf7fc 100644
--- a/docs/multisig_guide.md
+++ b/docs/multisig_guide.md
@@ -1,96 +1,96 @@
-# A guide for creating a 2 of 3 multisig account and sending transactions
-
-To follow this guide you'll need `cyber` installed and connected to any cyber node (refer to our cli [guide](https://github.com/cybercongress/go-cyber/blob/main/docs/ultimate-commands-guide.md)).
-A reminder: this guide covers all types of transactions, not only send transactions. This guide is also relevant for Cosmos Hub Gaiacli users, except for the bandwidth params, in Cosmos we pay a fee using tokens.
-
-Do not forget about the `--chain-id` flag in `cyber`, and in the `Cosmos Hub` networks.
-You can always get the current `<chain-id>` in the master branch of the [repository](https://github.com/cybercongress/go-cyber).
-
-## Creating a multisig
-
-The multisig account creation and sending transactions are simple and clear but can be a little long.
-
-1. Import or create a thresholder accounts for multisig:
-
-```bash
-cyber keys add test1
-cyber keys add test2
-```
-
-2. Add pubkeys of remote thresholder accounts:
-
-```bash
-cyber keys add test3 --pubkey=<thresholder_pub_key>
-```
-
-We now have 3 accounts for multisig account generating:
-`test1` and `test2` on a local machine that we have access to.
-`test3` from a remote thresholder that we do not have access to.
-All the created and imported accounts can be checked with:
-
-```bash
-cyber keys list
-```
-
-3. Now, we can create and test the 2-of-3 multisig account, named for example: `multitest1` with keys `test1`,`test2` on a local machine and `test3` on a remote thresholder:
-
-```bash
-cyber keys add multitest1 --multisig=test1,test2,test3 --multisig-threshold=2
-```
-
-4. You should top up the balance of your multisig account. Make sure that you have enough bandwidth to execute transactions later.
-
-## Spending out of a multisig account
-
-5. Create an unsigned transaction from the multisig account and store it in the `unsigned.json` file:
-
-```bash
-cyber tx send <recipient_address> <amount>boot \
---from=<multisig_address> \
---chain-id=<chain_id> \
---generate-only > unsigned.json
-```
-
-6. Sign this transaction with the following command and then store the signed file in `sign1.json`:
-
-```bash
-cyber tx sign unsigned.json --multisig=<multisig_address> \
---from=<your_account_name> \
---output-document=sign1.json \
---chain-id=<chain_id>
-```
-
-7. You need to send the obtained file to a remote thresholders for signing. You can see the content of the file containing the transaction with:
-
- ```bash
-cat unsigned.json
-```
-
-You may now copy the content that is convenient to your `.json` file and send it.
-
-8. You should also sign the remote thresholder, just like you did two steps above, and send your signed file back.
-For example `sign2.json`
-
-9. Copy the signed file from the remote thresholder into your cli home directory with the following command:
-
-```bash
-cp sign2.json $HOME/.cyber
-```
-
-Your cli-home folder should content 3 `.json` files:
-`unsigned.json`, `sign1.json`, and `sign2.json` (at least). Those are the necessary and sufficient conditions, because we've set up a 2-out-of 3 multisig account.
-
-10. Generate a multisig transaction with all signatures:
-
-```bash
-cyber tx multisign unsigned.json multitest1 sign1.json sign2.json \
---chain-id=<chain_id> > signed.json
-```
-
-11. Finally, we need to broadcast this transaction to the network:
-
-```bash
-cyber tx broadcast signed.json --chain-id=<chain_id>
-```
-
-If the multisig account has enough bandwidth, the transaction should be broadcasted to the network.
+# A guide for creating a 2 of 3 multisig account and sending transactions
+
+To follow this guide you'll need `cyber` installed and connected to any cyber node (refer to our cli [guide](https://github.com/cybercongress/go-cyber/blob/main/docs/ultimate-commands-guide.md)).
+A reminder: this guide covers all types of transactions, not only send transactions. This guide is also relevant for Cosmos Hub Gaiacli users, except for the bandwidth params, in Cosmos we pay a fee using tokens.
+
+Do not forget about the `--chain-id` flag in `cyber`, and in the `Cosmos Hub` networks.
+You can always get the current `<chain-id>` in the master branch of the [repository](https://github.com/cybercongress/go-cyber).
+
+## Creating a multisig
+
+The multisig account creation and sending transactions are simple and clear but can be a little long.
+
+1. Import or create a thresholder accounts for multisig:
+
+```bash
+cyber keys add test1
+cyber keys add test2
+```
+
+2. Add pubkeys of remote thresholder accounts:
+
+```bash
+cyber keys add test3 --pubkey=<thresholder_pub_key>
+```
+
+We now have 3 accounts for multisig account generating:
+`test1` and `test2` on a local machine that we have access to.
+`test3` from a remote thresholder that we do not have access to.
+All the created and imported accounts can be checked with:
+
+```bash
+cyber keys list
+```
+
+3. Now, we can create and test the 2-of-3 multisig account, named for example: `multitest1` with keys `test1`,`test2` on a local machine and `test3` on a remote thresholder:
+
+```bash
+cyber keys add multitest1 --multisig=test1,test2,test3 --multisig-threshold=2
+```
+
+4. You should top up the balance of your multisig account. Make sure that you have enough bandwidth to execute transactions later.
+
+## Spending out of a multisig account
+
+5. Create an unsigned transaction from the multisig account and store it in the `unsigned.json` file:
+
+```bash
+cyber tx send <recipient_address> <amount>boot \
+--from=<multisig_address> \
+--chain-id=<chain_id> \
+--generate-only > unsigned.json
+```
+
+6. Sign this transaction with the following command and then store the signed file in `sign1.json`:
+
+```bash
+cyber tx sign unsigned.json --multisig=<multisig_address> \
+--from=<your_account_name> \
+--output-document=sign1.json \
+--chain-id=<chain_id>
+```
+
+7. You need to send the obtained file to a remote thresholders for signing. You can see the content of the file containing the transaction with:
+
+ ```bash
+cat unsigned.json
+```
+
+You may now copy the content that is convenient to your `.json` file and send it.
+
+8. You should also sign the remote thresholder, just like you did two steps above, and send your signed file back.
+For example `sign2.json`
+
+9. Copy the signed file from the remote thresholder into your cli home directory with the following command:
+
+```bash
+cp sign2.json $HOME/.cyber
+```
+
+Your cli-home folder should content 3 `.json` files:
+`unsigned.json`, `sign1.json`, and `sign2.json` (at least). Those are the necessary and sufficient conditions, because we've set up a 2-out-of 3 multisig account.
+
+10. Generate a multisig transaction with all signatures:
+
+```bash
+cyber tx multisign unsigned.json multitest1 sign1.json sign2.json \
+--chain-id=<chain_id> > signed.json
+```
+
+11. Finally, we need to broadcast this transaction to the network:
+
+```bash
+cyber tx broadcast signed.json --chain-id=<chain_id>
+```
+
+If the multisig account has enough bandwidth, the transaction should be broadcasted to the network.
diff --git a/docs/port_forwarding_guide.md b/docs/port_forwarding_guide.md
index ba025f4e..4d419606 100644
--- a/docs/port_forwarding_guide.md
+++ b/docs/port_forwarding_guide.md
@@ -1,83 +1,83 @@
-# Decentralization must be decentralized
-
-January 3, 2019, we've launched first public testnet Euler-3. Since this time we have 3 relaunches and there will be some in the future. With help from our testers and validators we are finding and fixing new bugs every day. But now one fundamental and critical bug is not fixed yet.
-
-An obvious problem of decentralization is that no entity has a global vision of the system, and there is no central authority to direct nodes in making optimal decisions with regard to software updates, routing, or solving consensus. This makes the availability of a decentralized network more difficult to maintain, a factor significant enough to contribute to the failure of a system.
-
-By the way, a huge part of disconnections and, as result, validators jailing happens by this reason.
-
-Cyberd cli can’t automatically configure your router to open port `26656`, so you will need to manually configure your router.
-
-Enabling inbound connections requires two steps:
-
-1. Giving your computer a static (unchanging) internal IP address by configuring the Dynamic Host Configuration Protocol (DHCP) on your router.
-
-2. Forwarding inbound connections from the Internet through your router to your computer where cyber container can process them.
-
-3. Editing cyber configuration file.  
-
-## Configuring DHCP
-
-In order for your router to direct incoming port `26656` connections to your computer, it needs to know your computer’s internal IP address. However, routers usually give computers dynamic IP addresses that change frequently, so we need to ensure your router always gives your computer the same internal IP address.
-
-Start by logging into your router’s administration interface. Most routers can be configured using one of the following URLs, so keep clicking links until you find one that works. If none work, consult your router’s manual.
-
-```py
-    http://192.168.0.1 (some Linksys/Cisco models)
-    http://192.168.1.1 (some D-Link/Netgear models)
-    http://192.168.2.1 (some Belkin/SMC models)
-    http://192.168.123.254 (some US Robotics models)
-    http://10.0.1.1 (some Apple models)
-```
-
-Upon connecting, you will probably be prompted for a username and password. If you configured a password, enter it now. If not, the Router Passwords site provides a database of known default username and password pairs.
-
-After logging in, you want to search your router’s menus for options related to DHCP, the Dynamic Host Configuration Protocol. These options may also be called Address Reservation.
-
-In the reservation configuration, some routers will display a list of computers and devices currently connected to your network, and then let you select a device to make its current IP address permanent.
-
-If that’s the case, find the computer running cyber container in the list, select it, and add it to the list of reserved addresses. Make a note of its current IP address—we’ll use the address in the next section.
-
-Other routers require a more manual configuration. For these routers, you will need to look up the fixed address (MAC address) for your computer’s network card and add it to the list.
-
-Open a terminal and type ifconfig. Find the result that best matches your connection—a result starting with wlan indicates a wireless connection. Find the field that starts with HWaddr and copy the immediately following field that looks like `01:23:45:67:89:ab`. Use that value in the instructions below.
-
-Once you have the MAC address, you can fill it into to your router’s manual DHCP assignment table. Also, choose an IP address and make a note of it for the instructions in the next subsection. After entering this information, click the Add or Save button.
-
-Then reboot your computer to ensure it gets assigned the address you selected and proceed to the Port Forwarding instructions below.
-
-## Port Forwarding
-
-An easiest way to find some detailed instructions for you router is check [here](https://portforward.com/router.htm) or [here](https://setuprouter.com/).
-
-Here we'll provide you general idea of what has to be done.
-
-You need to know the local IP address of the computer running cyber container. You should have this information from configuring the DHCP assignment table in the subsection above.
-
-Login to your router using the same steps described near the top of the DHCP subsection. Look for an option called Port Forwarding, Port Assignment, or anything with “Port” in its name. On some routers, this option is buried in an Applications & Gaming menu.
-
-The port forwarding settings should allow you to map an external port on your router to the “internal port” of a device on your network.
-
-Both the external port and the internal port should be `26656` for cyber container.
-
-Make sure the IP address you enter is the same one you configured in the previous subsection.
-
-After filling in the details for the mapping, save the entry. You should not need to restart anything.
-
-If you still can’t connect and you use a firewall, you probably need to change your firewall settings. Ubuntu comes with its firewall disabled by default, but if you have enabled it, see the Ubuntu [wiki page](https://help.ubuntu.com/community/Gufw) for information about adding port forwarding rules.
-
-If something else went wrong, it’s probably a problem with your router configuration. Re-read the instructions above to see if you missed anything, try to look for some port-forwarding instructions [here](https://portforward.com/router.htm) or [here](https://setuprouter.com/).
-
-## Configuring cyber
-
-Go to cyber daemon folder, then go to `config` folder and open `config.toml` file for editing.
-
-Find `peer to peer configuration options` section and edit `external_address` variable with your IP address and port `26656`
-
-![peer_to_peer_config](https://ipfs.io/ipfs/QmQRqM4PbPt8cbDN49nAktT23XWfCixbfzfyUEkSyDUWYP)
-
-Restart cyber service.
-
----
-
-We call to you, validators, with a proposal to open port `26656` and make you validator-nodes available to the incoming connection.
+# Decentralization must be decentralized
+
+January 3, 2019, we've launched first public testnet Euler-3. Since this time we have 3 relaunches and there will be some in the future. With help from our testers and validators we are finding and fixing new bugs every day. But now one fundamental and critical bug is not fixed yet.
+
+An obvious problem of decentralization is that no entity has a global vision of the system, and there is no central authority to direct nodes in making optimal decisions with regard to software updates, routing, or solving consensus. This makes the availability of a decentralized network more difficult to maintain, a factor significant enough to contribute to the failure of a system.
+
+By the way, a huge part of disconnections and, as result, validators jailing happens by this reason.
+
+Cyberd cli can’t automatically configure your router to open port `26656`, so you will need to manually configure your router.
+
+Enabling inbound connections requires two steps:
+
+1. Giving your computer a static (unchanging) internal IP address by configuring the Dynamic Host Configuration Protocol (DHCP) on your router.
+
+2. Forwarding inbound connections from the Internet through your router to your computer where cyber container can process them.
+
+3. Editing cyber configuration file.  
+
+## Configuring DHCP
+
+In order for your router to direct incoming port `26656` connections to your computer, it needs to know your computer’s internal IP address. However, routers usually give computers dynamic IP addresses that change frequently, so we need to ensure your router always gives your computer the same internal IP address.
+
+Start by logging into your router’s administration interface. Most routers can be configured using one of the following URLs, so keep clicking links until you find one that works. If none work, consult your router’s manual.
+
+```py
+    http://192.168.0.1 (some Linksys/Cisco models)
+    http://192.168.1.1 (some D-Link/Netgear models)
+    http://192.168.2.1 (some Belkin/SMC models)
+    http://192.168.123.254 (some US Robotics models)
+    http://10.0.1.1 (some Apple models)
+```
+
+Upon connecting, you will probably be prompted for a username and password. If you configured a password, enter it now. If not, the Router Passwords site provides a database of known default username and password pairs.
+
+After logging in, you want to search your router’s menus for options related to DHCP, the Dynamic Host Configuration Protocol. These options may also be called Address Reservation.
+
+In the reservation configuration, some routers will display a list of computers and devices currently connected to your network, and then let you select a device to make its current IP address permanent.
+
+If that’s the case, find the computer running cyber container in the list, select it, and add it to the list of reserved addresses. Make a note of its current IP address—we’ll use the address in the next section.
+
+Other routers require a more manual configuration. For these routers, you will need to look up the fixed address (MAC address) for your computer’s network card and add it to the list.
+
+Open a terminal and type ifconfig. Find the result that best matches your connection—a result starting with wlan indicates a wireless connection. Find the field that starts with HWaddr and copy the immediately following field that looks like `01:23:45:67:89:ab`. Use that value in the instructions below.
+
+Once you have the MAC address, you can fill it into to your router’s manual DHCP assignment table. Also, choose an IP address and make a note of it for the instructions in the next subsection. After entering this information, click the Add or Save button.
+
+Then reboot your computer to ensure it gets assigned the address you selected and proceed to the Port Forwarding instructions below.
+
+## Port Forwarding
+
+An easiest way to find some detailed instructions for you router is check [here](https://portforward.com/router.htm) or [here](https://setuprouter.com/).
+
+Here we'll provide you general idea of what has to be done.
+
+You need to know the local IP address of the computer running cyber container. You should have this information from configuring the DHCP assignment table in the subsection above.
+
+Login to your router using the same steps described near the top of the DHCP subsection. Look for an option called Port Forwarding, Port Assignment, or anything with “Port” in its name. On some routers, this option is buried in an Applications & Gaming menu.
+
+The port forwarding settings should allow you to map an external port on your router to the “internal port” of a device on your network.
+
+Both the external port and the internal port should be `26656` for cyber container.
+
+Make sure the IP address you enter is the same one you configured in the previous subsection.
+
+After filling in the details for the mapping, save the entry. You should not need to restart anything.
+
+If you still can’t connect and you use a firewall, you probably need to change your firewall settings. Ubuntu comes with its firewall disabled by default, but if you have enabled it, see the Ubuntu [wiki page](https://help.ubuntu.com/community/Gufw) for information about adding port forwarding rules.
+
+If something else went wrong, it’s probably a problem with your router configuration. Re-read the instructions above to see if you missed anything, try to look for some port-forwarding instructions [here](https://portforward.com/router.htm) or [here](https://setuprouter.com/).
+
+## Configuring cyber
+
+Go to cyber daemon folder, then go to `config` folder and open `config.toml` file for editing.
+
+Find `peer to peer configuration options` section and edit `external_address` variable with your IP address and port `26656`
+
+![peer_to_peer_config](https://ipfs.io/ipfs/QmQRqM4PbPt8cbDN49nAktT23XWfCixbfzfyUEkSyDUWYP)
+
+Restart cyber service.
+
+---
+
+We call to you, validators, with a proposal to open port `26656` and make you validator-nodes available to the incoming connection.
diff --git a/docs/rpc.md b/docs/rpc.md
index 13bf6396..7f2dc4d1 100644
--- a/docs/rpc.md
+++ b/docs/rpc.md
@@ -1,189 +1,189 @@
-# API reference
-
-** TODO upgrade for bostrom network **
-
-Cyberd provides a [JSON-RPC](http://json-rpc.org/wiki/specification) type API. The HTTP endpoint is served under
- `localhost:20657`. WebSockets are the preferred transport for cyberd RPC and are used by applications, such as cyb.
- The default WebSocket connection endpoint for cyberd is `ws://localhost:26657/websocket`. There are test endpoints
- available at `https://titan.cybernode.ai/api/` and `ws://titan.cybernode.ai/websocket`.
-
-<br />
-
-## Standard Methods
-
-### Query Example
-
-Query the HTTP endpoint using curl:
-
-```bash
-curl --data '{"method":"status","params":[],"id":"1","jsonrpc":"2.0"}' \
--H "Content-Type: application/json" -X POST earth.cybernode.ai:34657
-```
-
-Query ws endpoint from JS:
-
-```js
-let websocket = new WebSocket("ws://earth.cybernode.ai:34657/websocket");
-websocket.send(JSON.stringify({
-  "method":"status",
-  "params":[],
-  "id":"1",
-  "jsonrpc":"2.0"
-}));
-```
-
-### Method Overview
-
-The following is an overview of the RPC methods and their current status.  Click
-the method name for further detail, such as parameter, and this will return information.
-
-|#|Method|Description|
-|---|------|-----------|
-|1|[status](#status)|Get node info, pubkey, latest block hash, app hash, block height and time.|
-|2|[account](#account)|Get account nonce, pubkey, number, and coins.|
-|3|[account_bandwidth](#account-bandwidth)|Get account bandwidth info for current height.|
-|4|[is_link_exist](#link-exist)|Return true, if given link exist.|
-|5|[current_bandwidth_price](#current-bandwidth-price)|Returns current bandwidth credit price.|
-|6|[index_stats](#index-stats)|Returns current index entities count.|
-
-### Method Details
-
-***
-<a name="status"/>
-
-|   |   |
-|---|---|
-|Method|status|
-|Parameters|None|
-|Description|Get node info, pubkey, latest block hash, app hash, block height and time.|
-|[Return to Overview](#method-overview)<br />
-
-<a name="account"/>
-
-|   |   |
-|---|---|
-|Method|account|
-|Parameters|1. address (string, required)<br />|
-|Description|Get account nonce, pubkey, number, and coins.|
-|[Return to Overview](#method-overview)<br />
-
-<a name="account-bandwidth"/>
-
-|   |   |
-|---|---|
-|Method|account_bandwidth|
-|Parameters|1. address (string, required)<br />|
-|Description|Get account bandwidth info for current height.|
-|[Return to Overview](#method-overview)<br />
-
-<a name="link-exist"/>
-
-|   |   |
-|---|---|
-|Method|is_link_exist|
-|Parameters|1. from (cid, required)<br />2. to (cid, required)<br />3. address (string, required)<br />|
-|Description|Return true, if given link exist.|
-|[Return to Overview](#method-overview)<br />
-
-<a name="current-bandwidth-price"/>
-
-|   |   |
-|---|---|
-|Method|current_bandwidth_price|
-|Parameters|None|
-|Description|Returns current bandwidth credit price.|
-|[Return to Overview](#method-overview)<br />
-
-<a name="index-stats"/>
-
-|   |   |
-|---|---|
-|Method|index_stats|
-|Parameters|None|
-|Description|Returns current index entities count.|
-|[Return to Overview](#method-overview)<br />
-
-***
-<br />
-<br />
-
-## Notifications (WebSocket-specific)
-
-Cyberd uses standard JSON-RPC notifications to notify clients of changes rather than requiring clients to poll cyberd
- for updates. JSON-RPC notifications are a subset of requests, but do not contain an ID. The notification type 
- is categorized by the `query` params field.
-
-### Subscribe Example 
-
-Subscribe for new block headers from JS:
-
- ```js
- let websocket = new WebSocket("ws://earth.cybernode.ai:34657/websocket");
- websocket.send(JSON.stringify({
-   "method": "subscribe",
-   "params": ["tm.event='NewBlockHeader'"],
-   "id": "1",
-   "jsonrpc": "2.0"
- }));
- ```
-
-### Events Overview
-
-|#|Event|Description|
-|---|------|-----------|
-|1|[NewBlockHeader](#NewBlockHeader)|Sends a block header notification when a new block is committed.|
-|2|[CoinsReceived](#CoinsReceived)|Sends a notification when new coinc arrive to a given address.|
-|3|[CoinsSend](#CoinsSend)|Sends a notification when new coins are sent from a given address.|
-|4|[СidsLinked](#СidsLinked)|Notification of links created by a given address.|
-|5|[SignedTxCommitted](#SignedTxCommitted)|Notify when any tx for a given signer is committed.|
-
-### Events Details
-
-#### NewBlockHeader
-
-|   |   |
-|---|---|
-|Event|NewBlockHeader|
-|Description|Sends block header notification when a new block is committed.|
-|Query|`tm.event='NewBlockHeader'`|
-|[Return to Overview](#events-overview)<br />
-
-#### CoinsReceived
-
-|   |   |
-|---|---|
-|Event|CoinsReceived|
-|Description|Sends a notification when new coins have arrived to a given address.|
-|Query|`tm.event='EventTx' AND recipient='cbd1sk3uvpacpjm2t3389caqk4gd9n9gkzq2054yds'`|
-|[Return to Overview](#events-overview)<br />
-
-#### CoinsSend
-
-|   |   |
-|---|---|
-|Event|CoinsSend|
-|Description|Sends a notification when new coins are sent from a given address.|
-|Query|`tm.event='EventTx' AND sender='cbd1sk3uvpacpjm2t3389caqk4gd9n9gkzq2054yds'`|
-|[Return to Overview](#events-overview)<br />
-
-#### СidsLinked
-|   |   |
-|---|---|
-|Event|СidsLinked|
-|Description|Notification of links created by a given address.|
-|Query|`tm.event='EventTx' AND signer='cbd1sk3uvpacpjm2t3389caqk4gd9n9gkzq2054yds' AND action='link'`|
-|[Return to Overview](#events-overview)<br />
-
-#### SignedTxCommitted
-
-|   |   |
-|---|---|
-|Event|SignedTxCommitted|
-|Description|Notify when any tx for a given signer is committed.|
-|Query|`tm.event='EventTx' AND signer='cbd1sk3uvpacpjm2t3389caqk4gd9n9gkzq2054yds'`|
-|[Return to Overview](#events-overview)<br />
-
-
-
-
-
+# API reference
+
+** TODO upgrade for bostrom network **
+
+Cyberd provides a [JSON-RPC](http://json-rpc.org/wiki/specification) type API. The HTTP endpoint is served under
+ `localhost:20657`. WebSockets are the preferred transport for cyberd RPC and are used by applications, such as cyb.
+ The default WebSocket connection endpoint for cyberd is `ws://localhost:26657/websocket`. There are test endpoints
+ available at `https://titan.cybernode.ai/api/` and `ws://titan.cybernode.ai/websocket`.
+
+<br />
+
+## Standard Methods
+
+### Query Example
+
+Query the HTTP endpoint using curl:
+
+```bash
+curl --data '{"method":"status","params":[],"id":"1","jsonrpc":"2.0"}' \
+-H "Content-Type: application/json" -X POST earth.cybernode.ai:34657
+```
+
+Query ws endpoint from JS:
+
+```js
+let websocket = new WebSocket("ws://earth.cybernode.ai:34657/websocket");
+websocket.send(JSON.stringify({
+  "method":"status",
+  "params":[],
+  "id":"1",
+  "jsonrpc":"2.0"
+}));
+```
+
+### Method Overview
+
+The following is an overview of the RPC methods and their current status.  Click
+the method name for further detail, such as parameter, and this will return information.
+
+|#|Method|Description|
+|---|------|-----------|
+|1|[status](#status)|Get node info, pubkey, latest block hash, app hash, block height and time.|
+|2|[account](#account)|Get account nonce, pubkey, number, and coins.|
+|3|[account_bandwidth](#account-bandwidth)|Get account bandwidth info for current height.|
+|4|[is_link_exist](#link-exist)|Return true, if given link exist.|
+|5|[current_bandwidth_price](#current-bandwidth-price)|Returns current bandwidth credit price.|
+|6|[index_stats](#index-stats)|Returns current index entities count.|
+
+### Method Details
+
+***
+<a name="status"/>
+
+|   |   |
+|---|---|
+|Method|status|
+|Parameters|None|
+|Description|Get node info, pubkey, latest block hash, app hash, block height and time.|
+|[Return to Overview](#method-overview)<br />
+
+<a name="account"/>
+
+|   |   |
+|---|---|
+|Method|account|
+|Parameters|1. address (string, required)<br />|
+|Description|Get account nonce, pubkey, number, and coins.|
+|[Return to Overview](#method-overview)<br />
+
+<a name="account-bandwidth"/>
+
+|   |   |
+|---|---|
+|Method|account_bandwidth|
+|Parameters|1. address (string, required)<br />|
+|Description|Get account bandwidth info for current height.|
+|[Return to Overview](#method-overview)<br />
+
+<a name="link-exist"/>
+
+|   |   |
+|---|---|
+|Method|is_link_exist|
+|Parameters|1. from (cid, required)<br />2. to (cid, required)<br />3. address (string, required)<br />|
+|Description|Return true, if given link exist.|
+|[Return to Overview](#method-overview)<br />
+
+<a name="current-bandwidth-price"/>
+
+|   |   |
+|---|---|
+|Method|current_bandwidth_price|
+|Parameters|None|
+|Description|Returns current bandwidth credit price.|
+|[Return to Overview](#method-overview)<br />
+
+<a name="index-stats"/>
+
+|   |   |
+|---|---|
+|Method|index_stats|
+|Parameters|None|
+|Description|Returns current index entities count.|
+|[Return to Overview](#method-overview)<br />
+
+***
+<br />
+<br />
+
+## Notifications (WebSocket-specific)
+
+Cyberd uses standard JSON-RPC notifications to notify clients of changes rather than requiring clients to poll cyberd
+ for updates. JSON-RPC notifications are a subset of requests, but do not contain an ID. The notification type 
+ is categorized by the `query` params field.
+
+### Subscribe Example 
+
+Subscribe for new block headers from JS:
+
+ ```js
+ let websocket = new WebSocket("ws://earth.cybernode.ai:34657/websocket");
+ websocket.send(JSON.stringify({
+   "method": "subscribe",
+   "params": ["tm.event='NewBlockHeader'"],
+   "id": "1",
+   "jsonrpc": "2.0"
+ }));
+ ```
+
+### Events Overview
+
+|#|Event|Description|
+|---|------|-----------|
+|1|[NewBlockHeader](#NewBlockHeader)|Sends a block header notification when a new block is committed.|
+|2|[CoinsReceived](#CoinsReceived)|Sends a notification when new coinc arrive to a given address.|
+|3|[CoinsSend](#CoinsSend)|Sends a notification when new coins are sent from a given address.|
+|4|[СidsLinked](#СidsLinked)|Notification of links created by a given address.|
+|5|[SignedTxCommitted](#SignedTxCommitted)|Notify when any tx for a given signer is committed.|
+
+### Events Details
+
+#### NewBlockHeader
+
+|   |   |
+|---|---|
+|Event|NewBlockHeader|
+|Description|Sends block header notification when a new block is committed.|
+|Query|`tm.event='NewBlockHeader'`|
+|[Return to Overview](#events-overview)<br />
+
+#### CoinsReceived
+
+|   |   |
+|---|---|
+|Event|CoinsReceived|
+|Description|Sends a notification when new coins have arrived to a given address.|
+|Query|`tm.event='EventTx' AND recipient='cbd1sk3uvpacpjm2t3389caqk4gd9n9gkzq2054yds'`|
+|[Return to Overview](#events-overview)<br />
+
+#### CoinsSend
+
+|   |   |
+|---|---|
+|Event|CoinsSend|
+|Description|Sends a notification when new coins are sent from a given address.|
+|Query|`tm.event='EventTx' AND sender='cbd1sk3uvpacpjm2t3389caqk4gd9n9gkzq2054yds'`|
+|[Return to Overview](#events-overview)<br />
+
+#### СidsLinked
+|   |   |
+|---|---|
+|Event|СidsLinked|
+|Description|Notification of links created by a given address.|
+|Query|`tm.event='EventTx' AND signer='cbd1sk3uvpacpjm2t3389caqk4gd9n9gkzq2054yds' AND action='link'`|
+|[Return to Overview](#events-overview)<br />
+
+#### SignedTxCommitted
+
+|   |   |
+|---|---|
+|Event|SignedTxCommitted|
+|Description|Notify when any tx for a given signer is committed.|
+|Query|`tm.event='EventTx' AND signer='cbd1sk3uvpacpjm2t3389caqk4gd9n9gkzq2054yds'`|
+|[Return to Overview](#events-overview)<br />
+
+
+
+
+
diff --git a/docs/run_validator.md b/docs/run_validator.md
index 96fa9e91..909bb6ca 100644
--- a/docs/run_validator.md
+++ b/docs/run_validator.md
@@ -1,418 +1,418 @@
-
-# Join cyber as a Validator
-
-## Prepare your server
-
-First, you should set up a server.
-Your node should be online constantly. This means that you will need a reliable server.
-You may also consider using any cloud service with a dedicated GPU, like Hetzner, Cherryservers etc. (or use a local machine). Whatever you choose, in order to achieve better stability and consistency we recommend you use a dedicated server for each validator node.
-
-Cyber is based on Cosmos-SDK and is written in Go.
-It should work on any platform which can compile and run programs in Go.
-We strongly recommend running the validator node on a Linux-based server.
-
-Cyber-rank computations are performed on GPU, so it is required to have it (GPU) on-board your node.
-
-Recommended hardware setup:
-
-```js
-CPU: 6 cores
-RAM: 32 GB
-SSD: 1 TB
-Connection: 50+Mbps, Stable and low-latency connection
-GPU: Nvidia GeForce (or Tesla/Titan/Quadro) with CUDA-cores; 4+ Gb of video memory*
-Software: Ubuntu 18.04 LTS / 20.04 LTS
-```
-
-*Cyber runs well on consumer-grade cards like Geforce GTX 1070, but we expect load growth and advise you use Error Correction compatible cards from Tesla or Quadro families. Also, make sure your card is compatible with >= v.410 of NVIDIA driver.*
-
-Of course the hardware is your own choice and technically it might be possible to run the node on *"even - 1 CUDA core GPU"*, but you should be aware of performance drop and rank calculation speed decline.
-
-## Node setup
-
-*To avoid possible misconfiguration issues and simplify the setup of `$ENV`, we recommend to perform all the commands as `root` (here root - is literally root, not just a user with root priveliges). For the case of a dedicated server for cybernode it should be concidered as ok from the security side.*
-
-### Third-party software
-
-The main distribution unit for Cyber is a [docker](https://www.docker.com/) container. All images are located in the default [Dockerhub registry](https://hub.docker.com/r/cyberd/cyber). In order to access the GPU from the container, Nvidia driver version **410+** and [Nvidia docker runtime](https://github.com/NVIDIA/nvidia-docker) should be installed on the host system.
-
-All commands below suppose `amd64` architecture, as the different architectures commands may differ accordingly.
-
-### Docker installation
-
-Simply copy the commands below and paste into CLI.
-
-1. Update the `apt` package index:
-
-```bash
-sudo apt-get update
-```
-
-2. Install packages to allow apt to use a repository over HTTPS:
-
-```bash
-sudo apt install -y \
-     apt-transport-https \
-     ca-certificates \
-     curl \
-     gnupg-agent \
-     software-properties-common
-```
-
-3. Add Docker’s official GPG key:
-
-```bash
-curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
-```
-
-```bash
-sudo add-apt-repository \
-   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
-   $(lsb_release -cs) \
-   stable"
-```
-
-4. Update the apt package index:
-
-```bash
-sudo apt update
-```
-
-5. Install the latest version of Docker CE and containerd:
-
-```bash
-sudo apt-get install docker-ce docker-ce-cli containerd.io
-```
-
-### Installing Nvidia drivers
-
-1. To proceed, first add the `ppa:graphics-drivers/ppa` repository:
-
-```bash
-sudo add-apt-repository ppa:graphics-drivers/ppa
-```
-
-```bash
-sudo apt update
-```
-
-2. Install Ubuntu-drivers:
-
-```bash
-sudo apt install -y ubuntu-drivers-common
-```
-
-3. Next check what are recommended drivers for your card:
-
-```bash
-ubuntu-drivers devices
-```
-
-You should see something similar to this:
-
-```bash
-== /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0 ==
-modalias : pci:v000010DEd00001BA1sv00001462sd000011E4bc03sc00i00
-vendor   : NVIDIA Corporation
-model    : GP104M [GeForce GTX 1070 Mobile]
-driver   : nvidia-driver-418 - third-party free
-driver   : nvidia-driver-430 - third-party free
-driver   : nvidia-driver-440 - third-party free
-driver   : nvidia-driver-460 - third-party free recommended
-driver   : xserver-xorg-video-nouveau - distro free builtin
-```
-
-4. We need the **410+** drivers release. As you can see the v460 is recommended. The command below will install the recommended version of the drivers:
-
-```bash
-sudo ubuntu-drivers autoinstall
-```
-
-To install specific version of a driver use `sudo apt install nvidia-driver-460`
-
-
-The driver installation takes approximately 10 minutes.
-
-```bash
-DKMS: install completed.
-Setting up libxdamage1:i386 (1:1.1.4-3) ...
-Setting up libxext6:i386 (2:1.3.3-1) ...
-Setting up libxfixes3:i386 (1:5.0.3-1) ...
-Setting up libnvidia-decode-415:i386 (460.84-0ubuntu0~gpu18.04.1) ...
-Setting up build-essential (12.4ubuntu1) ...
-Setting up libnvidia-gl-415:i386 (460.84-0ubuntu0~gpu18.04.1) ...
-Setting up libnvidia-encode-415:i386 (460.84-0ubuntu0~gpu18.04.1) ...
-Setting up nvidia-driver-415 (460.84-0ubuntu0~gpu18.04.1) ...
-Setting up libxxf86vm1:i386 (1:1.1.4-1) ...
-Setting up libglx-mesa0:i386 (18.0.5-0ubuntu0~18.04.1) ...
-Setting up libglx0:i386 (1.0.0-2ubuntu2.2) ...
-Setting up libgl1:i386 (1.0.0-2ubuntu2.2) ...
-Setting up libnvidia-ifr1-415:i386 (460.84-0ubuntu0~gpu18.04.1) ...
-Setting up libnvidia-fbc1-415:i386 (460.84-0ubuntu0~gpu18.04.1) ...
-Processing triggers for libc-bin (2.27-3ubuntu1) ...
-Processing triggers for initramfs-tools (0.130ubuntu3.1) ...
-update-initramfs: Generating /boot/initrd.img-4.15.0-45-generic
-```
-
-5. **Reboot** the system for the changes to take effect.
-
-```bash
-sudo reboot
-```
-
-6. Check the installed drivers:
-
-```bash
-nvidia-smi
-```
-
-You should see this:
-(Some version/driver numbers might differ. You might also have some processes already running)
-
-```bash
-+-----------------------------------------------------------------------------+
-| NVIDIA-SMI 460.84       Driver Version: 460.84       CUDA Version: 11.2     |
-|-------------------------------+----------------------+----------------------+
-| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
-| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
-|===============================+======================+======================|
-|   0  GeForce GTX 1070    Off  | 00000000:01:00.0 Off |                  N/A |
-| 26%   36C    P5    26W / 180W |      0MiB /  8119MiB |      2%      Default |
-+-------------------------------+----------------------+----------------------+
-
-+-----------------------------------------------------------------------------+
-| Processes:                                                       GPU Memory |
-|  GPU       PID   Type   Process name                             Usage      |
-|=============================================================================|
-|  No running processes found                                                 |
-+-----------------------------------------------------------------------------+
-```
-
-#### Install Nvidia container runtime for docker
-
-1. Add package repositories:
-
-```bash
-distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
-```
-
-```bash
-curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add -
-```
-
-```bash
-curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list
-```
-
-You should see something like this:
-
-```bash
-deb https://nvidia.github.io/libnvidia-container/ubuntu20.04/$(ARCH) /
-deb https://nvidia.github.io/nvidia-container-runtime/ubuntu20.04/$(ARCH) /
-deb https://nvidia.github.io/nvidia-docker/ubuntu20.04/$(ARCH) /
-```
-
-2. Install nvidia-container toolkit and reload the Docker daemon configuration
-
-```bash
-sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
-```
-
-```bash
-sudo systemctl restart docker
-```
-
-3. Test nvidia-smi with the latest official CUDA image
-
-```bash
-docker run --gpus all nvidia/cuda:11.4.0-base nvidia-smi
-```
-
-Output logs should coincide as earlier:
-
-```bash
-Unable to find image 'nvidia/cuda:11.4.0-base' locally
-11.1-base: Pulling from nvidia/cuda
-54ee1f796a1e: Pull complete 
-f7bfea53ad12: Pull complete 
-46d371e02073: Pull complete 
-b66c17bbf772: Pull complete 
-3642f1a6dfb3: Pull complete 
-e5ce55b8b4b9: Pull complete 
-155bc0332b0a: Pull complete 
-Digest: sha256:774ca3d612de15213102c2dbbba55df44dc5cf9870ca2be6c6e9c627fa63d67a
-Status: Downloaded newer image for nvidia/cuda:11.1-base
-Mon Jun 21 14:07:52 2021 
-+------------------------------------------------------------------------+
-|NVIDIA-SMI 460.84      Driver Version:460.84      CUDA Version: 11.4    |
-|-----------------------------+--------------------+---------------------+
-|GPU  Name       Persistence-M| Bus-Id       Disp.A| Volatile Uncorr. ECC|
-|Fan  Temp  Perf Pwr:Usage/Cap|        Memory-Usage| GPU-Util  Compute M.|
-|                             |                    |               MIG M.|
-|=============================+====================+=====================|
-|  0  GeForce GTX165...  Off  |00000000:01:00.0 Off|                  N/A|
-|N/A   47C    P0   16W /  N/A |      0MB /  3914MiB|      0%      Default|
-|                             |                    |                  N/A|
-+-----------------------------+--------------------+---------------------+
-                                                                       
-+------------------------------------------------------------------------+
-|Processes:                                                              |
-| GPU   GI   CI       PID   Type   Process name                GPU Memory|
-|       ID   ID                                                Usage     |
-|========================================================================|
-| No running processes found                                             |
-+------------------------------------------------------------------------+
-```
-
-Your machine is ready to launch the node.
-
-
-### Launching cyber fullnode
-
-Make a directory tree for storing your daemon:
-
-```bash
-mkdir $HOME/.cyber
-mkdir $HOME/.cyber/data
-mkdir $HOME/.cyber/config
-```
-
-
-2. Run the full node:
-(This will pull and extract the image from cyberd/cyber)
-
-```bash
-docker run -d --gpus all --name=bostrom --restart always -p 26656:26656 -p 26657:26657 -p 1317:1317 -e ALLOW_SEARCH=true -v $HOME/.cyber:/root/.cyber  cyberd/bostrom:dragonberry-cuda11.4
-```
-
-Docker image already contain all binaries to either sync from 0 or start form snapshot.
-
-3. Setup some peers to `persistent_peers` and `seeds` to $HOME/.cyber/config/config.toml line 184:
-
-
-```bash
-# Comma separated list of seed nodes to connect to
-seeds = ""
-
-# Comma separated list of nodes to keep persistent connections to
-persistent_peers = ""
-```
-
-For peers addresses please refer to appropriate section of the [networks](https://github.com/cybercongress/networks) repo.
-When done, please restart container using:
-
-4. To apply config changes restart the container:
-
-```bash
-docker restart bostrom
-```
-
-5. Then check the status of your node:
-
-```bash
-docker exec bostrom cyber status
-```
-
-A possible output may look like this:
-
-```bash
-{"NodeInfo":{"protocol_version":{"p2p":"8","block":"11","app":"0"},"id":"808a3773d8adabc78bca6ef8d6b2ee20456bfbcb","listen_addr":"tcp://86.57.207.105:26656","network":"bostrom","version":"","channels":"40202122233038606100","moniker":"node1234","other":
-{"tx_index":"on","rpc_address":"tcp://0.0.0.0:26657"}},"SyncInfo":{"latest_block_hash":"241BA3E744A9024A2D04BDF4CE7CF4985D7922054B38AF258712027D0854E930","latest_app_hash":"5BF4B64508A95984F017BD6C29012FE5E66ADCB367D06345EE1EB2ED18314437","latest_block_height":"521",
-"latest_block_time":"2021-06-21T14:21:41.817756021Z","earliest_block_hash":"98DD3065543108F5EBEBC45FAAAEA868B3C84426572BE9FDA2E3F1C49A2C0CE8","earliest_app_hash":"E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855","earliest_block_height":"1",
-"earliest_block_time":"2021-06-10T00:00:00Z","catching_up":false},"ValidatorInfo":{"Address":"611C9F3568E7341155DBF0546795BF673FD84EB1","PubKey":{"type":"tendermint/PubKeyEd25519","value":"0iGriT3gyRJXQXR/98c+2MTAhChIo5F5v7FfPmOAH5o="},"VotingPower":"0"}}
-
-```
-
-To check container logs use:
-
-```bash
-docker logs bostrom -f --tail 10
-```
-
-## Validator start
-
-After your node has successfully synced, you can run a validator.
-
-### Prepare the staking address
-
-1. To proceed further you need to add your existing address to the node or generate one and fund it. 
-
-To **create** a new one use:
-
-```bash
-docker exec -ti bostrom cyber keys add <your_key_name>
-```
-
-The above command returns the address, the public key and the seed phrase, which you can use to
-recover your account if you forget your password later.
-
-**Keep you seed phrase safe. Your keys are only your responsibility!**
-
-To **import** existing address use: 
-
-```bash
-docker exec -ti bostrom cyber keys add <your_key_name> --recover
-```
-
-You can use your **ledger** device with the Cosmos app installed on it to sign transactions. Add address from Ledger:
-
-```bash
-docker exec -ti bostrom cyber keys add <your_key_name> --ledger
-```
-
-**<your_key_name>** is any name you pick to represent this key pair.
-You have to refer to that name later when you use cli to sign transactions.
-
-### Send the create validator transaction
-
-Validators are actors on the network committing new blocks by submitting their votes.
-This refers to the node itself, not a single person or a single account.
-
-The next step is to to declare a validator candidate.
-To declare a validator candidate, run the following command adjusting the stake amount and the other fields:
-
-```bash
-docker exec -ti bostrom cyber tx staking create-validator \
-  --amount=10000000boot \
-  --min-self-delegation "1000000" \
-  --pubkey=$(docker exec -ti bostrom cyber tendermint show-validator) \
-  --moniker=<your_node_nickname> \
-  --from=<your_key_name> \
-  --commission-rate="0.10" \
-  --commission-max-rate="0.20" \
-  --commission-max-change-rate="0.01" \
-  --chain-id=bostrom \
-  --gas-prices=0.01boot \
-  --gas=600000
-```
-
-### Verify that you are validating
-
-```bash
-docker exec -ti bostrom cyber query staking validators
-```
-
-If you see your `<your_node_nickname>` with the status `Bonded` and Jailed `false` everything is good.
-You are validating the network.
-
-## Maintenance of the validator
-
-### Jailing
-
-If your validator got under slashing conditions, it will be jailed.
-After such an event an operator must unjail the validator manually:
-
-```bash
-docker exec -ti bostrom cyber tx slashing unjail --from=<your_key_name> --chain-id=bostrom --gas-prices=0.01boot --gas=300000
-```
-
-### Back-up validator keys (!)
-
-Your identity as a validator consists of two things: 
-
-- your account (to sign transactions)
-- your validator private key (to sign stuff on the chain consensus layer)
-
-Please back up `$HOME/.cyber/config/priv_validator_key.json` along with your seed phrase. In case of occasional node loss you would be able to restore your validator operation with this file and another full node.
-
-Finally, in case you want to keep your cyber node ID consistent during networks please backup `$HOME/.cyber/config/node_key.json`.
+
+# Join cyber as a Validator
+
+## Prepare your server
+
+First, you should set up a server.
+Your node should be online constantly. This means that you will need a reliable server.
+You may also consider using any cloud service with a dedicated GPU, like Hetzner, Cherryservers etc. (or use a local machine). Whatever you choose, in order to achieve better stability and consistency we recommend you use a dedicated server for each validator node.
+
+Cyber is based on Cosmos-SDK and is written in Go.
+It should work on any platform which can compile and run programs in Go.
+We strongly recommend running the validator node on a Linux-based server.
+
+Cyber-rank computations are performed on GPU, so it is required to have it (GPU) on-board your node.
+
+Recommended hardware setup:
+
+```js
+CPU: 6 cores
+RAM: 32 GB
+SSD: 1 TB
+Connection: 50+Mbps, Stable and low-latency connection
+GPU: Nvidia GeForce (or Tesla/Titan/Quadro) with CUDA-cores; 4+ Gb of video memory*
+Software: Ubuntu 18.04 LTS / 20.04 LTS
+```
+
+*Cyber runs well on consumer-grade cards like Geforce GTX 1070, but we expect load growth and advise you use Error Correction compatible cards from Tesla or Quadro families. Also, make sure your card is compatible with >= v.410 of NVIDIA driver.*
+
+Of course the hardware is your own choice and technically it might be possible to run the node on *"even - 1 CUDA core GPU"*, but you should be aware of performance drop and rank calculation speed decline.
+
+## Node setup
+
+*To avoid possible misconfiguration issues and simplify the setup of `$ENV`, we recommend to perform all the commands as `root` (here root - is literally root, not just a user with root priveliges). For the case of a dedicated server for cybernode it should be concidered as ok from the security side.*
+
+### Third-party software
+
+The main distribution unit for Cyber is a [docker](https://www.docker.com/) container. All images are located in the default [Dockerhub registry](https://hub.docker.com/r/cyberd/cyber). In order to access the GPU from the container, Nvidia driver version **410+** and [Nvidia docker runtime](https://github.com/NVIDIA/nvidia-docker) should be installed on the host system.
+
+All commands below suppose `amd64` architecture, as the different architectures commands may differ accordingly.
+
+### Docker installation
+
+Simply copy the commands below and paste into CLI.
+
+1. Update the `apt` package index:
+
+```bash
+sudo apt-get update
+```
+
+2. Install packages to allow apt to use a repository over HTTPS:
+
+```bash
+sudo apt install -y \
+     apt-transport-https \
+     ca-certificates \
+     curl \
+     gnupg-agent \
+     software-properties-common
+```
+
+3. Add Docker’s official GPG key:
+
+```bash
+curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
+```
+
+```bash
+sudo add-apt-repository \
+   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
+   $(lsb_release -cs) \
+   stable"
+```
+
+4. Update the apt package index:
+
+```bash
+sudo apt update
+```
+
+5. Install the latest version of Docker CE and containerd:
+
+```bash
+sudo apt-get install docker-ce docker-ce-cli containerd.io
+```
+
+### Installing Nvidia drivers
+
+1. To proceed, first add the `ppa:graphics-drivers/ppa` repository:
+
+```bash
+sudo add-apt-repository ppa:graphics-drivers/ppa
+```
+
+```bash
+sudo apt update
+```
+
+2. Install Ubuntu-drivers:
+
+```bash
+sudo apt install -y ubuntu-drivers-common
+```
+
+3. Next check what are recommended drivers for your card:
+
+```bash
+ubuntu-drivers devices
+```
+
+You should see something similar to this:
+
+```bash
+== /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0 ==
+modalias : pci:v000010DEd00001BA1sv00001462sd000011E4bc03sc00i00
+vendor   : NVIDIA Corporation
+model    : GP104M [GeForce GTX 1070 Mobile]
+driver   : nvidia-driver-418 - third-party free
+driver   : nvidia-driver-430 - third-party free
+driver   : nvidia-driver-440 - third-party free
+driver   : nvidia-driver-460 - third-party free recommended
+driver   : xserver-xorg-video-nouveau - distro free builtin
+```
+
+4. We need the **410+** drivers release. As you can see the v460 is recommended. The command below will install the recommended version of the drivers:
+
+```bash
+sudo ubuntu-drivers autoinstall
+```
+
+To install specific version of a driver use `sudo apt install nvidia-driver-460`
+
+
+The driver installation takes approximately 10 minutes.
+
+```bash
+DKMS: install completed.
+Setting up libxdamage1:i386 (1:1.1.4-3) ...
+Setting up libxext6:i386 (2:1.3.3-1) ...
+Setting up libxfixes3:i386 (1:5.0.3-1) ...
+Setting up libnvidia-decode-415:i386 (460.84-0ubuntu0~gpu18.04.1) ...
+Setting up build-essential (12.4ubuntu1) ...
+Setting up libnvidia-gl-415:i386 (460.84-0ubuntu0~gpu18.04.1) ...
+Setting up libnvidia-encode-415:i386 (460.84-0ubuntu0~gpu18.04.1) ...
+Setting up nvidia-driver-415 (460.84-0ubuntu0~gpu18.04.1) ...
+Setting up libxxf86vm1:i386 (1:1.1.4-1) ...
+Setting up libglx-mesa0:i386 (18.0.5-0ubuntu0~18.04.1) ...
+Setting up libglx0:i386 (1.0.0-2ubuntu2.2) ...
+Setting up libgl1:i386 (1.0.0-2ubuntu2.2) ...
+Setting up libnvidia-ifr1-415:i386 (460.84-0ubuntu0~gpu18.04.1) ...
+Setting up libnvidia-fbc1-415:i386 (460.84-0ubuntu0~gpu18.04.1) ...
+Processing triggers for libc-bin (2.27-3ubuntu1) ...
+Processing triggers for initramfs-tools (0.130ubuntu3.1) ...
+update-initramfs: Generating /boot/initrd.img-4.15.0-45-generic
+```
+
+5. **Reboot** the system for the changes to take effect.
+
+```bash
+sudo reboot
+```
+
+6. Check the installed drivers:
+
+```bash
+nvidia-smi
+```
+
+You should see this:
+(Some version/driver numbers might differ. You might also have some processes already running)
+
+```bash
++-----------------------------------------------------------------------------+
+| NVIDIA-SMI 460.84       Driver Version: 460.84       CUDA Version: 11.2     |
+|-------------------------------+----------------------+----------------------+
+| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
+| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
+|===============================+======================+======================|
+|   0  GeForce GTX 1070    Off  | 00000000:01:00.0 Off |                  N/A |
+| 26%   36C    P5    26W / 180W |      0MiB /  8119MiB |      2%      Default |
++-------------------------------+----------------------+----------------------+
+
++-----------------------------------------------------------------------------+
+| Processes:                                                       GPU Memory |
+|  GPU       PID   Type   Process name                             Usage      |
+|=============================================================================|
+|  No running processes found                                                 |
++-----------------------------------------------------------------------------+
+```
+
+#### Install Nvidia container runtime for docker
+
+1. Add package repositories:
+
+```bash
+distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
+```
+
+```bash
+curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add -
+```
+
+```bash
+curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list
+```
+
+You should see something like this:
+
+```bash
+deb https://nvidia.github.io/libnvidia-container/ubuntu20.04/$(ARCH) /
+deb https://nvidia.github.io/nvidia-container-runtime/ubuntu20.04/$(ARCH) /
+deb https://nvidia.github.io/nvidia-docker/ubuntu20.04/$(ARCH) /
+```
+
+2. Install nvidia-container toolkit and reload the Docker daemon configuration
+
+```bash
+sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
+```
+
+```bash
+sudo systemctl restart docker
+```
+
+3. Test nvidia-smi with the latest official CUDA image
+
+```bash
+docker run --gpus all nvidia/cuda:11.4.0-base nvidia-smi
+```
+
+Output logs should coincide as earlier:
+
+```bash
+Unable to find image 'nvidia/cuda:11.4.0-base' locally
+11.1-base: Pulling from nvidia/cuda
+54ee1f796a1e: Pull complete 
+f7bfea53ad12: Pull complete 
+46d371e02073: Pull complete 
+b66c17bbf772: Pull complete 
+3642f1a6dfb3: Pull complete 
+e5ce55b8b4b9: Pull complete 
+155bc0332b0a: Pull complete 
+Digest: sha256:774ca3d612de15213102c2dbbba55df44dc5cf9870ca2be6c6e9c627fa63d67a
+Status: Downloaded newer image for nvidia/cuda:11.1-base
+Mon Jun 21 14:07:52 2021 
++------------------------------------------------------------------------+
+|NVIDIA-SMI 460.84      Driver Version:460.84      CUDA Version: 11.4    |
+|-----------------------------+--------------------+---------------------+
+|GPU  Name       Persistence-M| Bus-Id       Disp.A| Volatile Uncorr. ECC|
+|Fan  Temp  Perf Pwr:Usage/Cap|        Memory-Usage| GPU-Util  Compute M.|
+|                             |                    |               MIG M.|
+|=============================+====================+=====================|
+|  0  GeForce GTX165...  Off  |00000000:01:00.0 Off|                  N/A|
+|N/A   47C    P0   16W /  N/A |      0MB /  3914MiB|      0%      Default|
+|                             |                    |                  N/A|
++-----------------------------+--------------------+---------------------+
+                                                                       
++------------------------------------------------------------------------+
+|Processes:                                                              |
+| GPU   GI   CI       PID   Type   Process name                GPU Memory|
+|       ID   ID                                                Usage     |
+|========================================================================|
+| No running processes found                                             |
++------------------------------------------------------------------------+
+```
+
+Your machine is ready to launch the node.
+
+
+### Launching cyber fullnode
+
+Make a directory tree for storing your daemon:
+
+```bash
+mkdir $HOME/.cyber
+mkdir $HOME/.cyber/data
+mkdir $HOME/.cyber/config
+```
+
+
+2. Run the full node:
+(This will pull and extract the image from cyberd/cyber)
+
+```bash
+docker run -d --gpus all --name=bostrom --restart always -p 26656:26656 -p 26657:26657 -p 1317:1317 -e ALLOW_SEARCH=true -v $HOME/.cyber:/root/.cyber  cyberd/bostrom:dragonberry-cuda11.4
+```
+
+Docker image already contain all binaries to either sync from 0 or start form snapshot.
+
+3. Setup some peers to `persistent_peers` and `seeds` to $HOME/.cyber/config/config.toml line 184:
+
+
+```bash
+# Comma separated list of seed nodes to connect to
+seeds = ""
+
+# Comma separated list of nodes to keep persistent connections to
+persistent_peers = ""
+```
+
+For peers addresses please refer to appropriate section of the [networks](https://github.com/cybercongress/networks) repo.
+When done, please restart container using:
+
+4. To apply config changes restart the container:
+
+```bash
+docker restart bostrom
+```
+
+5. Then check the status of your node:
+
+```bash
+docker exec bostrom cyber status
+```
+
+A possible output may look like this:
+
+```bash
+{"NodeInfo":{"protocol_version":{"p2p":"8","block":"11","app":"0"},"id":"808a3773d8adabc78bca6ef8d6b2ee20456bfbcb","listen_addr":"tcp://86.57.207.105:26656","network":"bostrom","version":"","channels":"40202122233038606100","moniker":"node1234","other":
+{"tx_index":"on","rpc_address":"tcp://0.0.0.0:26657"}},"SyncInfo":{"latest_block_hash":"241BA3E744A9024A2D04BDF4CE7CF4985D7922054B38AF258712027D0854E930","latest_app_hash":"5BF4B64508A95984F017BD6C29012FE5E66ADCB367D06345EE1EB2ED18314437","latest_block_height":"521",
+"latest_block_time":"2021-06-21T14:21:41.817756021Z","earliest_block_hash":"98DD3065543108F5EBEBC45FAAAEA868B3C84426572BE9FDA2E3F1C49A2C0CE8","earliest_app_hash":"E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855","earliest_block_height":"1",
+"earliest_block_time":"2021-06-10T00:00:00Z","catching_up":false},"ValidatorInfo":{"Address":"611C9F3568E7341155DBF0546795BF673FD84EB1","PubKey":{"type":"tendermint/PubKeyEd25519","value":"0iGriT3gyRJXQXR/98c+2MTAhChIo5F5v7FfPmOAH5o="},"VotingPower":"0"}}
+
+```
+
+To check container logs use:
+
+```bash
+docker logs bostrom -f --tail 10
+```
+
+## Validator start
+
+After your node has successfully synced, you can run a validator.
+
+### Prepare the staking address
+
+1. To proceed further you need to add your existing address to the node or generate one and fund it. 
+
+To **create** a new one use:
+
+```bash
+docker exec -ti bostrom cyber keys add <your_key_name>
+```
+
+The above command returns the address, the public key and the seed phrase, which you can use to
+recover your account if you forget your password later.
+
+**Keep you seed phrase safe. Your keys are only your responsibility!**
+
+To **import** existing address use: 
+
+```bash
+docker exec -ti bostrom cyber keys add <your_key_name> --recover
+```
+
+You can use your **ledger** device with the Cosmos app installed on it to sign transactions. Add address from Ledger:
+
+```bash
+docker exec -ti bostrom cyber keys add <your_key_name> --ledger
+```
+
+**<your_key_name>** is any name you pick to represent this key pair.
+You have to refer to that name later when you use cli to sign transactions.
+
+### Send the create validator transaction
+
+Validators are actors on the network committing new blocks by submitting their votes.
+This refers to the node itself, not a single person or a single account.
+
+The next step is to to declare a validator candidate.
+To declare a validator candidate, run the following command adjusting the stake amount and the other fields:
+
+```bash
+docker exec -ti bostrom cyber tx staking create-validator \
+  --amount=10000000boot \
+  --min-self-delegation "1000000" \
+  --pubkey=$(docker exec -ti bostrom cyber tendermint show-validator) \
+  --moniker=<your_node_nickname> \
+  --from=<your_key_name> \
+  --commission-rate="0.10" \
+  --commission-max-rate="0.20" \
+  --commission-max-change-rate="0.01" \
+  --chain-id=bostrom \
+  --gas-prices=0.01boot \
+  --gas=600000
+```
+
+### Verify that you are validating
+
+```bash
+docker exec -ti bostrom cyber query staking validators
+```
+
+If you see your `<your_node_nickname>` with the status `Bonded` and Jailed `false` everything is good.
+You are validating the network.
+
+## Maintenance of the validator
+
+### Jailing
+
+If your validator got under slashing conditions, it will be jailed.
+After such an event an operator must unjail the validator manually:
+
+```bash
+docker exec -ti bostrom cyber tx slashing unjail --from=<your_key_name> --chain-id=bostrom --gas-prices=0.01boot --gas=300000
+```
+
+### Back-up validator keys (!)
+
+Your identity as a validator consists of two things: 
+
+- your account (to sign transactions)
+- your validator private key (to sign stuff on the chain consensus layer)
+
+Please back up `$HOME/.cyber/config/priv_validator_key.json` along with your seed phrase. In case of occasional node loss you would be able to restore your validator operation with this file and another full node.
+
+Finally, in case you want to keep your cyber node ID consistent during networks please backup `$HOME/.cyber/config/node_key.json`.
diff --git a/docs/setup_cyber_configuration.md b/docs/setup_cyber_configuration.md
index 2c2ccb0c..1ea6fd3a 100644
--- a/docs/setup_cyber_configuration.md
+++ b/docs/setup_cyber_configuration.md
@@ -1,284 +1,284 @@
-# Setup config.toml
-
-Correct configuration is one of the main keys to consistent and proper functioning of your node no matter if it is a validator or a sentinel/service node.
-
-Throughout this document, we will check all the key points of the `config.toml` file and explain how to configure them for all use-cases.
-
-We will operate a basic configuration file (according to the number of the line in the actual file), generated after the initialization of cyber daemon and typically located inside `$HOME/.cyber/config directory`.
-
-> All changes made to the `config.toml` file, require to restart cyber to take effect!
-
-## Port / Address configuration
-
-### RPC port
-
-First of all, let's look through the ports cyber uses to communicate with the outside world. On *line 84* the specified port is used for an RPC server (TCP and UNIX websocket connections):
-
-```bash
-# TCP or UNIX socket address for the RPC server to listen on
-laddr = "tcp://127.0.0.1:26657"
-```
-
-After the node starts the RPC server provides endpoints to check chain/node parameters, accepts $POST transactions and so on. It can be opened locally using your favourite browser via: `http://localhost:26657`.
-
-- We do not recommend a validator node to open this port to the outside world, as it may allow anyone to produce transactions using your node and allows DOS attacks (you don't want your validator attacked, right?). So let's leave it like this:
-
-```bash
-laddr = "tcp://127.0.0.1:26657"
-```
-
-- For Sentinel nodes this should be kept the same as for validators:
-
-```bash
-laddr = "tcp://127.0.0.1:26657"
-```
-
-- For Service nodes, when use cases include remote access to the RPC for yourself or for your great service, it is allowable to expose it to the outside by using the following values:
-
-```bash
-laddr = "tcp://0.0.0.0:26657"
-```
-
-If you would like to make the RPC server respond on a different port, you may change this value to whatever you'd like (just make sure it will not cross with any of the other services), for example, to change it to `9588` use:
-
-```bash
-# TCP or UNIX socket address for the RPC server to listen on
-laddr = "tcp://0.0.0.0:9588"
-```
-
-### Cyberd communication port
-
-On *line 163* we can find the following:
-
-```bash
-# Address to listen for incoming connections
-laddr = "tcp://0.0.0.0:26656"
-```
-
-This is the way the node communicates with other nodes in the chain. For all possible cases(**Validator, Sentinel, Service**) leave it as default, bound to  `0.0.0.0`. And if you need to change the port number to something different like `35622` just use:
-
-```bash
-laddr = "tcp://0.0.0.0:35622"
-```
-
-If changed, your node peer address would be changed accordingly: `75e8f44072b0dd598dfa95aaf9b5f2c60f956819@your_external_ip:35622`.
-
-### Prometheus collectors port
-
-On *line 325* the port for Prometheus monitoring service is located: 
-
-```bash
-# Address to listen for Prometheus collector(s) connections
-prometheus_listen_addr = ":26660"
-```
-
-It is useful if you want to monitor remotely the condition of your node using the [Prometheus](https://prometheus.io/) metrics collector service and could be changed to whatever you like `23456`:
-
-```bash
-prometheus_listen_addr = ":23456"
-```
-
-Don't forget to enable Prometheus metrics by changing to `true` on *line 322*, if needed:
-
-```bash
-# When true, Prometheus metrics are served under /metrics on
-# PrometheusListenAddr.
-# Check out the documentation for the list of available metrics.
-prometheus = true
-```
-
-### External address
-
-On *line 169* you should find the following:
-
-```bash
-# Address to advertise to peers for them to dial
-# If empty, will use the same port as the laddr,
-# and will introspect on the listener or use UPnP
-# to figure out the address.
-external_address = ""
-```
-
-This line implies specifying your external IP address, which means the presence of a static external address at your network connection. If you don't have one, just skip it.
-
-- For Validator nodes, you may skip it, until you have **enough private peers** to get synced with. Otherwise, you have to specify your external static IP to improve peer discovery for your node. Also, don't forget to change the port according to *line [163](#cyber-communication-port)*:
-
-```bash
-external_address = "tcp://<your_external_static_ip>:26656"
-```
-
-- For Sentinel nodes it is a good idea to specify the IP for better peer discovery:
-
-```bash
-external_address = "tcp://<your_external_static_ip>:26656"
-```
-
-- For Servie nodes this setting can be the same as for Sentinel nodes:
-
-```bash
-external_address = "tcp://<your_external_static_ip>:26656"
-```
-
-And again, all of the above settings apply to the cases when **STATIC EXTERNAL IP** is available.
-
-### Allow duplicated IP's
-
-*Line 224* of the config.toml holds the following:
-
-```bash
-# Toggle to disable guard against peers connecting from the same ip.
-allow_duplicate_ip = false
-```
-
-This variable configures the possibility for different peers to be connected from the same IP. Lets imagine a situation where you run 2 nodes (lets say that the node ID of the first one is: `75e8f44072b0dd598dfa95aaf9b5f2c60f956819` and the second one is: `d0518ce9881a4b0c5872e5e9b7c4ea8d760dad3f`) on one internet provider, with an external IP of 92.23.45.123. In this case, all other nodes in the network with `allow_duplicate_ip = false` will see attempts to connect from peers `d0518ce9881a4b0c5872e5e9b7c4ea8d760dad3f@92.23.45.123:26656` and `75e8f44072b0dd598dfa95aaf9b5f2c60f956819@92.23.45.123:36656` and will block the one which comes last because the originating IP address is the same for both nodes. If this case applies to you, change this setting to the following:
-
-```bash
-# Toggle to disable guard against peers connecting from the same ip.
-allow_duplicate_ip = true
-```
-
-## P2P configuration
-
-### Seed nodes
-
-On *line 172* of the config.toml we see the following:
-
-```bash
-# Comma separated list of seed nodes to connect to
-seeds = ""
-```
-
-This line is dedicated to the list of seed nodes you want to establish a connection with. To get some seed and peers addresses take a look at networks [repository](https://github.com/cybercongress/networks).
-
-- For validators with sentinel nodes or with a decent quantity of peers connected it is not required to fill it out:
-
-```bash
-seeds = ""
-```
-
-- For Sentinel nodes and Service nodes it's a good idea to fill it out with a couple of seed node addresses, separated with commas: 
-
-```bash
-seeds = "<seed_node1_ID>@<seed_node1_ip>:<port>,<seed_node2_ID>@<seed_node2_ip>:<port>"
-```
-
-### Persistent peers
-
-The place to add persistent peers is located on *line 175.* Presence of persistent peers is very important for the correct functioning of the node:
-
-```bash
-# Comma separated list of nodes to keep persistent connections to
-persistent_peers = ""
-```
-
-- For Validator nodes you have to fill out this line with a decent amount of peers you **trust**, otherwise, your validator node address will be exposed. In the perfect case scenario, you should add to this section only the addresses of your sentinel nodes:
-
-```bash
-persistent_peers ="<sentinel_node1_ID>@<sentinel_node1_ip>:<port>,<sentinel_node2_ID>@<sentinel_node2_ip>:<port>"
-```
-
-- For Sentinel nodes and Service nodes add as many peers as possible to keep a persistent connection and network stability, but **DO NOT** put here you'r validator nodes ID's:
-
-```bash
-persistent_peers ="<node1_ID>@<node1_ip>:<port>,<node2_ID>@<node2_ip>:<port>,...,<node_n_ID>@<node_n_ip>:<port>"
-```
-
-### Peer Exchange Reactor
-
-*Line 212* shows by default:
-
-```bash
-# Set true to enable the peer-exchange reactor
-pex = true
-```
-
-This is a peer exchange module, which is responsible for exchanging node IDs across the network.
-
-- For Validator nodes with Sentinel architecture set this to be disabled:
-
-```bash
-pex = false
-```
-
-- For Sentinel nodes and Service nodes leave as default:
-
-```bash
-pex = true
-```
-
-### Private peers ID's
-
-On *line 221* we see:
-
-```bash
-# Comma separated list of peer IDs to keep private (will not be gossiped to other peers)
-private_peer_ids = ""
-```
-
-This is the list of peers which IDs should not gossip to others.
-
-- For Validator nodes, leave as default:
-
-```bash
-private_peer_ids = ""
-```
-
-- For Sentinel nodes, add your validator/s address  here:
-
-```bash
-private_peer_ids = "<validator_node_ID>@<validator_node_ip>:<port>"
-```
-
-- For Service nodes leave blank:
-
-```bash
-private_peer_ids = ""
-```
-
-## Node Index, Naming
-
-### Indexed tags
-
-A node can index and store a decent amount of keys and values with regards to transactions, accounts etc. *Lines 306 and 304* are responsible for this:
-
-```bash
-# You can also index transactions by height by adding "tx.height" key here.
-#
-# It's recommended to index only a subset of keys due to possible memory
-# bloat. This is, of course, depends on the indexer's DB and the volume of
-# transactions.
-index_keys = ""
-
-# When set to true, tells indexer to index all compositeKeys (predefined keys:
-# "tx.hash", "tx.height" and all keys from DeliverTx responses).
-#
-# Note this may be not desirable (see the comment above). IndexKeys has a
-# precedence over IndexAllKeys (i.e. when given both, IndexKeys will be
-# indexed).
-index_all_keys = false
-```
-
-- For Validator and Sentinel nodes this is not necessary, so leave as default: 
-
-```bash
-index_keys = ""
-
-index_all_keys = false
-```
-
-- For Service nodes, you should specify a subset of keys you want to index:
-
-```bash
-index_keys = "tx.hash,tx.height,...etc.."
-
-index_all_keys = true
-```
-
-### Naming
-
-To setup up your node moniker please refer to *line 16* and type in whatever you want to have as moniker:
-
-```bash
-# A custom human readable name for this node
-moniker = "rocket_node"
-```
+# Setup config.toml
+
+Correct configuration is one of the main keys to consistent and proper functioning of your node no matter if it is a validator or a sentinel/service node.
+
+Throughout this document, we will check all the key points of the `config.toml` file and explain how to configure them for all use-cases.
+
+We will operate a basic configuration file (according to the number of the line in the actual file), generated after the initialization of cyber daemon and typically located inside `$HOME/.cyber/config directory`.
+
+> All changes made to the `config.toml` file, require to restart cyber to take effect!
+
+## Port / Address configuration
+
+### RPC port
+
+First of all, let's look through the ports cyber uses to communicate with the outside world. On *line 84* the specified port is used for an RPC server (TCP and UNIX websocket connections):
+
+```bash
+# TCP or UNIX socket address for the RPC server to listen on
+laddr = "tcp://127.0.0.1:26657"
+```
+
+After the node starts the RPC server provides endpoints to check chain/node parameters, accepts $POST transactions and so on. It can be opened locally using your favourite browser via: `http://localhost:26657`.
+
+- We do not recommend a validator node to open this port to the outside world, as it may allow anyone to produce transactions using your node and allows DOS attacks (you don't want your validator attacked, right?). So let's leave it like this:
+
+```bash
+laddr = "tcp://127.0.0.1:26657"
+```
+
+- For Sentinel nodes this should be kept the same as for validators:
+
+```bash
+laddr = "tcp://127.0.0.1:26657"
+```
+
+- For Service nodes, when use cases include remote access to the RPC for yourself or for your great service, it is allowable to expose it to the outside by using the following values:
+
+```bash
+laddr = "tcp://0.0.0.0:26657"
+```
+
+If you would like to make the RPC server respond on a different port, you may change this value to whatever you'd like (just make sure it will not cross with any of the other services), for example, to change it to `9588` use:
+
+```bash
+# TCP or UNIX socket address for the RPC server to listen on
+laddr = "tcp://0.0.0.0:9588"
+```
+
+### Cyberd communication port
+
+On *line 163* we can find the following:
+
+```bash
+# Address to listen for incoming connections
+laddr = "tcp://0.0.0.0:26656"
+```
+
+This is the way the node communicates with other nodes in the chain. For all possible cases(**Validator, Sentinel, Service**) leave it as default, bound to  `0.0.0.0`. And if you need to change the port number to something different like `35622` just use:
+
+```bash
+laddr = "tcp://0.0.0.0:35622"
+```
+
+If changed, your node peer address would be changed accordingly: `75e8f44072b0dd598dfa95aaf9b5f2c60f956819@your_external_ip:35622`.
+
+### Prometheus collectors port
+
+On *line 325* the port for Prometheus monitoring service is located: 
+
+```bash
+# Address to listen for Prometheus collector(s) connections
+prometheus_listen_addr = ":26660"
+```
+
+It is useful if you want to monitor remotely the condition of your node using the [Prometheus](https://prometheus.io/) metrics collector service and could be changed to whatever you like `23456`:
+
+```bash
+prometheus_listen_addr = ":23456"
+```
+
+Don't forget to enable Prometheus metrics by changing to `true` on *line 322*, if needed:
+
+```bash
+# When true, Prometheus metrics are served under /metrics on
+# PrometheusListenAddr.
+# Check out the documentation for the list of available metrics.
+prometheus = true
+```
+
+### External address
+
+On *line 169* you should find the following:
+
+```bash
+# Address to advertise to peers for them to dial
+# If empty, will use the same port as the laddr,
+# and will introspect on the listener or use UPnP
+# to figure out the address.
+external_address = ""
+```
+
+This line implies specifying your external IP address, which means the presence of a static external address at your network connection. If you don't have one, just skip it.
+
+- For Validator nodes, you may skip it, until you have **enough private peers** to get synced with. Otherwise, you have to specify your external static IP to improve peer discovery for your node. Also, don't forget to change the port according to *line [163](#cyber-communication-port)*:
+
+```bash
+external_address = "tcp://<your_external_static_ip>:26656"
+```
+
+- For Sentinel nodes it is a good idea to specify the IP for better peer discovery:
+
+```bash
+external_address = "tcp://<your_external_static_ip>:26656"
+```
+
+- For Servie nodes this setting can be the same as for Sentinel nodes:
+
+```bash
+external_address = "tcp://<your_external_static_ip>:26656"
+```
+
+And again, all of the above settings apply to the cases when **STATIC EXTERNAL IP** is available.
+
+### Allow duplicated IP's
+
+*Line 224* of the config.toml holds the following:
+
+```bash
+# Toggle to disable guard against peers connecting from the same ip.
+allow_duplicate_ip = false
+```
+
+This variable configures the possibility for different peers to be connected from the same IP. Lets imagine a situation where you run 2 nodes (lets say that the node ID of the first one is: `75e8f44072b0dd598dfa95aaf9b5f2c60f956819` and the second one is: `d0518ce9881a4b0c5872e5e9b7c4ea8d760dad3f`) on one internet provider, with an external IP of 92.23.45.123. In this case, all other nodes in the network with `allow_duplicate_ip = false` will see attempts to connect from peers `d0518ce9881a4b0c5872e5e9b7c4ea8d760dad3f@92.23.45.123:26656` and `75e8f44072b0dd598dfa95aaf9b5f2c60f956819@92.23.45.123:36656` and will block the one which comes last because the originating IP address is the same for both nodes. If this case applies to you, change this setting to the following:
+
+```bash
+# Toggle to disable guard against peers connecting from the same ip.
+allow_duplicate_ip = true
+```
+
+## P2P configuration
+
+### Seed nodes
+
+On *line 172* of the config.toml we see the following:
+
+```bash
+# Comma separated list of seed nodes to connect to
+seeds = ""
+```
+
+This line is dedicated to the list of seed nodes you want to establish a connection with. To get some seed and peers addresses take a look at networks [repository](https://github.com/cybercongress/networks).
+
+- For validators with sentinel nodes or with a decent quantity of peers connected it is not required to fill it out:
+
+```bash
+seeds = ""
+```
+
+- For Sentinel nodes and Service nodes it's a good idea to fill it out with a couple of seed node addresses, separated with commas: 
+
+```bash
+seeds = "<seed_node1_ID>@<seed_node1_ip>:<port>,<seed_node2_ID>@<seed_node2_ip>:<port>"
+```
+
+### Persistent peers
+
+The place to add persistent peers is located on *line 175.* Presence of persistent peers is very important for the correct functioning of the node:
+
+```bash
+# Comma separated list of nodes to keep persistent connections to
+persistent_peers = ""
+```
+
+- For Validator nodes you have to fill out this line with a decent amount of peers you **trust**, otherwise, your validator node address will be exposed. In the perfect case scenario, you should add to this section only the addresses of your sentinel nodes:
+
+```bash
+persistent_peers ="<sentinel_node1_ID>@<sentinel_node1_ip>:<port>,<sentinel_node2_ID>@<sentinel_node2_ip>:<port>"
+```
+
+- For Sentinel nodes and Service nodes add as many peers as possible to keep a persistent connection and network stability, but **DO NOT** put here you'r validator nodes ID's:
+
+```bash
+persistent_peers ="<node1_ID>@<node1_ip>:<port>,<node2_ID>@<node2_ip>:<port>,...,<node_n_ID>@<node_n_ip>:<port>"
+```
+
+### Peer Exchange Reactor
+
+*Line 212* shows by default:
+
+```bash
+# Set true to enable the peer-exchange reactor
+pex = true
+```
+
+This is a peer exchange module, which is responsible for exchanging node IDs across the network.
+
+- For Validator nodes with Sentinel architecture set this to be disabled:
+
+```bash
+pex = false
+```
+
+- For Sentinel nodes and Service nodes leave as default:
+
+```bash
+pex = true
+```
+
+### Private peers ID's
+
+On *line 221* we see:
+
+```bash
+# Comma separated list of peer IDs to keep private (will not be gossiped to other peers)
+private_peer_ids = ""
+```
+
+This is the list of peers which IDs should not gossip to others.
+
+- For Validator nodes, leave as default:
+
+```bash
+private_peer_ids = ""
+```
+
+- For Sentinel nodes, add your validator/s address  here:
+
+```bash
+private_peer_ids = "<validator_node_ID>@<validator_node_ip>:<port>"
+```
+
+- For Service nodes leave blank:
+
+```bash
+private_peer_ids = ""
+```
+
+## Node Index, Naming
+
+### Indexed tags
+
+A node can index and store a decent amount of keys and values with regards to transactions, accounts etc. *Lines 306 and 304* are responsible for this:
+
+```bash
+# You can also index transactions by height by adding "tx.height" key here.
+#
+# It's recommended to index only a subset of keys due to possible memory
+# bloat. This is, of course, depends on the indexer's DB and the volume of
+# transactions.
+index_keys = ""
+
+# When set to true, tells indexer to index all compositeKeys (predefined keys:
+# "tx.hash", "tx.height" and all keys from DeliverTx responses).
+#
+# Note this may be not desirable (see the comment above). IndexKeys has a
+# precedence over IndexAllKeys (i.e. when given both, IndexKeys will be
+# indexed).
+index_all_keys = false
+```
+
+- For Validator and Sentinel nodes this is not necessary, so leave as default: 
+
+```bash
+index_keys = ""
+
+index_all_keys = false
+```
+
+- For Service nodes, you should specify a subset of keys you want to index:
+
+```bash
+index_keys = "tx.hash,tx.height,...etc.."
+
+index_all_keys = true
+```
+
+### Naming
+
+To setup up your node moniker please refer to *line 16* and type in whatever you want to have as moniker:
+
+```bash
+# A custom human readable name for this node
+moniker = "rocket_node"
+```
diff --git a/docs/setup_dev_env.md b/docs/setup_dev_env.md
index b6563a7e..882479c3 100644
--- a/docs/setup_dev_env.md
+++ b/docs/setup_dev_env.md
@@ -1,301 +1,301 @@
-# Setup development environment
-
-## Prestart
-* Install [Golang 1.11+](https://golang.org/doc/install)
-* Install [GoLand IDE](https://www.jetbrains.com/go/)
-
-## Import project to GoLand
-Open Project in GoLand by selecting: Open Project -> selecting cloned repository root folder
-![Open project](https://ipfs.io/ipfs/QmYQxSKzQkkpCofuHmbJZqYoTo4cuvHQuUNYkJRBKgSduL)
-
-Enable **go mod** package management
-![Enable go mod](https://ipfs.io/ipfs/Qmaz3o7LjAG9bNhE8VkHSUokM8EqgfcVXT9R5qB3XxLZSe)
-Wait for dependency downloading and indexation
-
-## Add Run Configurations
-###Add testnet configuration
-![Generate testnet](./img/generate-testnet.png)
-
-### Add run configuration with GPU
-![Run node](./img/run-node.png)
-
-#### Notes about GPU dev environment
-
-```
-TO DO
-```
-
-### Add run configuration with CPU
-![Run node CPU](./img/run-node-cpu.png)
-
-```
-start --allow-search=true --compute-rank-on-gpu=false --home=./mytestnet/node0/cyberd
-```
-
-### Add reset configuration
-![Reset node data](./img/reset-node-data.png)
-
-
-## Running Node
-### Generate testnet
-Before node running, setup testnet with run configuration **D TESTNET**. 
-- Folder **/mytestnet** will be added to the project root.
-- In **/node0** subfolder you can find daemon and cli folders.
-- Daemon folder will contain validator node data.
-- In **/cyberdcli** folder you can find initial validator seed.
-
-```
-mytestnet
-├── gentxs
-│   └── node0.json
-└── node0
-    ├── cyberd
-    │   ├── config
-    │   │   ├── config.toml
-    │   │   ├── genesis.json
-    │   │   ├── node_key.json
-    │   │   └── priv_validator_key.json
-    │   └── data
-    │       ├── priv_validator_state.json
-    └── cyberdcli
-        └── key_seed.json
-```
-
-### Run with GPU or CPU
-After, just run **RUN** node configuration.
-
-
-```
-I[2019-05-15|15:06:56.735] Starting ABCI with Tendermint                module=main 
-I[2019-05-15|15:06:56.789] Loading mem state                            module=main 
-I[2019-05-15|15:06:56.789] App loaded                                   module=main time=118.743µs
-I[2019-05-15|15:06:56.793] Search index loaded!                         module=main time=3.416449ms
-I[2019-05-15|15:06:56.793] Search index starting listen new links       module=main 
-I[2019-05-15|15:06:56.793] Search index starting listen new rank        module=main 
-I[2019-05-15|15:06:56.910] Applying genesis                             module=main 
-I[2019-05-15|15:06:56.914] File with links not found. Empty set will be used module=main 
-I[2019-05-15|15:06:56.914] Genesis applied                              module=main time=3.420262ms
-E[2019-05-15|15:06:56.947] Couldn't connect to any seeds                module=p2p 
-I[2019-05-15|15:07:02.014] Executed block                               module=state height=1 validTxs=0 invalidTxs=0
-I[2019-05-15|15:07:02.014] Rank calculated                              module=main time=2.069µs links=0 cids=0 hash=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
-I[2019-05-15|15:07:02.047] Committed state                              module=state height=1 txs=0 appHash=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
-I[2019-05-15|15:07:07.078] Executed block                               module=state height=2 validTxs=0 invalidTxs=0
-I[2019-05-15|15:07:07.107] Committed state                              module=state height=2 txs=0 appHash=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
-I[2019-05-15|15:07:12.113] Executed block                               module=state height=3 validTxs=0 invalidTxs=0
-I[2019-05-15|15:07:12.144] Committed state                              module=state height=3 txs=0 appHash=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
-I[2019-05-15|15:07:17.168] Executed block                               module=state height=4 validTxs=0 invalidTxs=0
-I[2019-05-15|15:07:17.207] Committed state                              module=state height=4 txs=0 appHash=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
-```
-
-### You may stop, and RUN again
-```
-I[2019-05-15|14:48:58.191] Starting ABCI with Tendermint                module=main 
-I[2019-05-15|14:48:58.343] Loading mem state                            module=main 
-I[2019-05-15|14:48:58.344] App loaded                                   module=main time=929.472µs
-I[2019-05-15|14:48:58.399] Search index loaded!                         module=main time=16.928556ms
-I[2019-05-15|14:48:58.399] Search index starting listen new links       module=main 
-I[2019-05-15|14:48:58.399] Search index starting listen new rank        module=main 
-E[2019-05-15|14:48:58.638] Couldn't connect to any seeds                module=p2p 
-I[2019-05-15|14:49:03.716] Executed block                               module=state height=2032 validTxs=0 invalidTxs=0
-I[2019-05-15|14:49:03.755] Committed state                              module=state height=2032 txs=0 appHash=1BAA91AD6FD9742B7B094204037F80A8174673BA0FF304D3FF5DFEEAF8FF7DDC
-I[2019-05-15|14:49:08.759] Executed block                               module=state height=2033 validTxs=0 invalidTxs=0
-I[2019-05-15|14:49:08.793] Committed state                              module=state height=2033 txs=0 appHash=1BAA91AD6FD9742B7B094204037F80A8174673BA0FF304D3FF5DFEEAF8FF7DDC
-I[2019-05-15|14:49:13.826] Executed block                               module=state height=2034 validTxs=0 invalidTxs=0
-I[2019-05-15|14:49:13.860] Committed state                              module=state height=2034 txs=0 appHash=1BAA91AD6FD9742B7B094204037F80A8174673BA0FF304D3FF5DFEEAF8FF7DDC
-```
-
-### Reset
-You can reset chains data to genesis at any time by executing **RESET** run configuration
-```
-I[2019-05-15|15:09:43.338] Removed existing address book                module=main file=mytestnet/node0/cyberd/config/addrbook.json
-I[2019-05-15|15:09:43.345] Removed all blockchain history               module=main dir=mytestnet/node0/cyberd/data
-I[2019-05-15|15:09:43.347] Reset private validator file to genesis state module=main keyFile=mytestnet/node0/cyberd/config/priv_validator_key.json stateFile=mytestnet/node0/cyberd/data/priv_validator_state.json
-```
-
-## Exploring
-
-Guide to all commands you may to research here: [Ultimate cyberd CLI guide](https://github.com/cybercongress/cyberd/blob/master/docs/help/ultimate-commands-guide_v2.md)
-
-### Before, build cyberd cli:
-```
-go build -o cyberdcli ./cli
-```
-You will get cyberdcli into you project root
-
-### Add keys:
-```
-./cyberdcli keys add validator --recover
-```
-Enter and you protection password-passphrase and mnemocic from file **mytestnet/node0/cyberdcli/key_seed.json**
-```
-
-Enter a passphrase to encrypt your key to disk:
-Repeat the passphrase:
-> Enter your bip39 mnemonic
-inhale enforce brand fever core smart draft ceiling among cluster orbit robust tonight elephant below twice goat update uncover employ spider brass consider shiver
-
-NAME:   TYPE:   ADDRESS:                                        PUBKEY:
-validator       local   cyber18l4v00ar4xsgzc4rr40tfctcjgyp7ppwysdcns    cyberpub1addwnpepq0zm06twxtf7ezv4nj9dhud9ds0fnhkks6qw4g8pdwxzh3evggpvvksh60l
-
-```
-
-### Query status:
-```
-./cyberdcli status --indent
-```
-
-```
-{
-  "node_info": {
-    "protocol_version": {
-      "p2p": "7",
-      "block": "10",
-      "app": "0"
-    },
-    "id": "b99f3254757310d1f470f5cd0331b766f2a843f9",
-    "listen_addr": "tcp://0.0.0.0:26656",
-    "network": "chain-K6U4uZ",
-    "version": "0.30.1",
-    "channels": "4020212223303800",
-    "moniker": "node0",
-    "other": {
-      "tx_index": "on",
-      "rpc_address": "tcp://0.0.0.0:26657"
-    }
-  },
-  "sync_info": {
-    "latest_block_hash": "8059683636349AF9237FABFD147BAD89C7188571E37E8F09356B1837A88337BA",
-    "latest_app_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855",
-    "latest_block_height": "134",
-    "latest_block_time": "2019-05-15T09:04:31.768026Z",
-    "catching_up": false
-  },
-  "validator_info": {
-    "address": "9C2C13F2B6608BF00BADF501A04E728AC5FF7ADC",
-    "pub_key": {
-      "type": "tendermint/PubKeyEd25519",
-      "value": "or7X/1BYcGE1cVX5e3vG9G76JPfXZDKTDg8YL3vtKzo="
-    },
-    "voting_power": "10000000000"
-  }
-}
-
-```
-
-### Query balance:
-```
-./cyberdcli query account cyber18l4v00ar4xsgzc4rr40tfctcjgyp7ppwysdcns 
-```
-
-```
-Account:
-  Address:       cyber18l4v00ar4xsgzc4rr40tfctcjgyp7ppwysdcns
-  Pubkey:        cyberpub1addwnpepq0zm06twxtf7ezv4nj9dhud9ds0fnhkks6qw4g8pdwxzh3evggpvvksh60l
-  Coins:         10000000000000000cyb
-  AccountNumber: 0
-  Sequence:      1
-```
-
-### Query validators:
-```
-./cyberdcli query staking validators  
-```
-
-```
-Validator
-  Operator Address:           cybervaloper18l4v00ar4xsgzc4rr40tfctcjgyp7ppwy3lgak
-  Validator Consensus Pubkey: cybervalconspub1zcjduepq52ld0l6stpcxzdt32huhk77x73h05f8h6ajr9ycwpuvz77ld9vaq6ka2zl
-  Jailed:                     false
-  Status:                     Bonded
-  Tokens:                     10000000000000000
-  Delegator Shares:           10000000000000000.000000000000000000
-  Description:                {node0 tst com.com det}
-  Unbonding Height:           0
-  Unbonding Completion Time:  1970-01-01 00:00:00 +0000 UTC
-  Minimum Self Delegation:    1
-  Commission:                 rate: 0.000000000000000000, maxRate: 0.000000000000000000, maxChangeRate: 0.000000000000000000, updateTime: 2019-05-15 08:52:36.324624 +0000 UTC
-
-```
-
-### Add links
-```
-./cyberdcli link --from=validator --cid-from=QmbTARMsUw9X2ZEbBaFXRu9JEqNN2g4VZ6DPgtgZH1opy9 --cid-to=QmNWkR2v4ZEzT43xiNKJcFPkFQioGbhqsWcE5qayWQHXAo --chain-id=chain-K6U4uZ
-./cyberdcli link --from=validator --cid-from=QmbTARMsUw9X2ZEbBaFXRu9JEqNN2g4VZ6DPgtgZH1opy9 --cid-to=Qmd7AaekFAxXedSQx3B3h8Wc5aeYPYRiYF83Vjb4tVLkMM --chain-id=chain-K6U4uZ
-./cyberdcli link --from=validator --cid-from=QmbTARMsUw9X2ZEbBaFXRu9JEqNN2g4VZ6DPgtgZH1opy9 --cid-to=QmfSh5obPXmkaTd9aaNCYWxnKHZTH6EYeEh7Hq7xgGnRVy --chain-id=chain-K6U4uZ
-```
-
-```
-{"chain_id":"chain-K6U4uZ","account_number":"0","sequence":"1","fee":{"amount":null,"gas":"200000"},"msgs":[{"type":"cyberd/Link","value":{"address":"cyber18l4v00ar4xsgzc4rr40tfctcjgyp7ppwysdcns","links":[{"from":"QmbTARMsUw9X2ZEbBaFXRu9JEqNN2g4VZ6DPgtgZH1opy9","to":"QmNWkR2v4ZEzT43xiNKJcFPkFQioGbhqsWcE5qayWQHXAo"}]}}],"memo":""}
-
-confirm transaction before signing and broadcasting [Y/n]: Y
-Password to sign with 'validator':
-Response:
-  Height: 1720
-  TxHash: 68C4F6389D36747A6A609CCDD9D44027A5234850FF065C78D1B1AB3FAC421541
-  Logs: [{"msg_index":0,"success":true,"log":""}]
-  GasUsed: 31368
-  Tags: 
-    - action = link
-```
-
-### Search and get links with rank:
-```
-curl -X GET 'localhost:26657/search?cid="QmbTARMsUw9X2ZEbBaFXRu9JEqNN2g4VZ6DPgtgZH1opy9"'
-```
-
-#### Links added, rank for them will be computed at next round:
-```
-{
-  "jsonrpc": "2.0",
-  "id": "",
-  "result": {
-    "cids": [
-      {
-        "cid": "QmNWkR2v4ZEzT43xiNKJcFPkFQioGbhqsWcE5qayWQHXAo",
-        "rank": 0
-      },
-      {
-        "cid": "Qmd7AaekFAxXedSQx3B3h8Wc5aeYPYRiYF83Vjb4tVLkMM",
-        "rank": 0
-      },
-      {
-        "cid": "QmfSh5obPXmkaTd9aaNCYWxnKHZTH6EYeEh7Hq7xgGnRVy",
-        "rank": 0
-      }
-    ],
-    "total": "3",
-    "page": "0",
-    "perPage": "100"
-  }
-}%   
-```
-
-#### When rank computed:
-```
-{
-  "jsonrpc": "2.0",
-  "id": "",
-  "result": {
-    "cids": [
-      {
-        "cid": "QmNWkR2v4ZEzT43xiNKJcFPkFQioGbhqsWcE5qayWQHXAo",
-        "rank": 0.056093750000000005
-      },
-      {
-        "cid": "Qmd7AaekFAxXedSQx3B3h8Wc5aeYPYRiYF83Vjb4tVLkMM",
-        "rank": 0.056093750000000005
-      },
-      {
-        "cid": "QmfSh5obPXmkaTd9aaNCYWxnKHZTH6EYeEh7Hq7xgGnRVy",
-        "rank": 0.056093750000000005
-      }
-    ],
-    "total": "3",
-    "page": "0",
-    "perPage": "100"
-  }
-}   
-```
-
-# #fuckgoogle
-
+# Setup development environment
+
+## Prestart
+* Install [Golang 1.11+](https://golang.org/doc/install)
+* Install [GoLand IDE](https://www.jetbrains.com/go/)
+
+## Import project to GoLand
+Open Project in GoLand by selecting: Open Project -> selecting cloned repository root folder
+![Open project](https://ipfs.io/ipfs/QmYQxSKzQkkpCofuHmbJZqYoTo4cuvHQuUNYkJRBKgSduL)
+
+Enable **go mod** package management
+![Enable go mod](https://ipfs.io/ipfs/Qmaz3o7LjAG9bNhE8VkHSUokM8EqgfcVXT9R5qB3XxLZSe)
+Wait for dependency downloading and indexation
+
+## Add Run Configurations
+###Add testnet configuration
+![Generate testnet](./img/generate-testnet.png)
+
+### Add run configuration with GPU
+![Run node](./img/run-node.png)
+
+#### Notes about GPU dev environment
+
+```
+TO DO
+```
+
+### Add run configuration with CPU
+![Run node CPU](./img/run-node-cpu.png)
+
+```
+start --allow-search=true --compute-rank-on-gpu=false --home=./mytestnet/node0/cyberd
+```
+
+### Add reset configuration
+![Reset node data](./img/reset-node-data.png)
+
+
+## Running Node
+### Generate testnet
+Before node running, setup testnet with run configuration **D TESTNET**. 
+- Folder **/mytestnet** will be added to the project root.
+- In **/node0** subfolder you can find daemon and cli folders.
+- Daemon folder will contain validator node data.
+- In **/cyberdcli** folder you can find initial validator seed.
+
+```
+mytestnet
+├── gentxs
+│   └── node0.json
+└── node0
+    ├── cyberd
+    │   ├── config
+    │   │   ├── config.toml
+    │   │   ├── genesis.json
+    │   │   ├── node_key.json
+    │   │   └── priv_validator_key.json
+    │   └── data
+    │       ├── priv_validator_state.json
+    └── cyberdcli
+        └── key_seed.json
+```
+
+### Run with GPU or CPU
+After, just run **RUN** node configuration.
+
+
+```
+I[2019-05-15|15:06:56.735] Starting ABCI with Tendermint                module=main 
+I[2019-05-15|15:06:56.789] Loading mem state                            module=main 
+I[2019-05-15|15:06:56.789] App loaded                                   module=main time=118.743µs
+I[2019-05-15|15:06:56.793] Search index loaded!                         module=main time=3.416449ms
+I[2019-05-15|15:06:56.793] Search index starting listen new links       module=main 
+I[2019-05-15|15:06:56.793] Search index starting listen new rank        module=main 
+I[2019-05-15|15:06:56.910] Applying genesis                             module=main 
+I[2019-05-15|15:06:56.914] File with links not found. Empty set will be used module=main 
+I[2019-05-15|15:06:56.914] Genesis applied                              module=main time=3.420262ms
+E[2019-05-15|15:06:56.947] Couldn't connect to any seeds                module=p2p 
+I[2019-05-15|15:07:02.014] Executed block                               module=state height=1 validTxs=0 invalidTxs=0
+I[2019-05-15|15:07:02.014] Rank calculated                              module=main time=2.069µs links=0 cids=0 hash=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
+I[2019-05-15|15:07:02.047] Committed state                              module=state height=1 txs=0 appHash=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
+I[2019-05-15|15:07:07.078] Executed block                               module=state height=2 validTxs=0 invalidTxs=0
+I[2019-05-15|15:07:07.107] Committed state                              module=state height=2 txs=0 appHash=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
+I[2019-05-15|15:07:12.113] Executed block                               module=state height=3 validTxs=0 invalidTxs=0
+I[2019-05-15|15:07:12.144] Committed state                              module=state height=3 txs=0 appHash=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
+I[2019-05-15|15:07:17.168] Executed block                               module=state height=4 validTxs=0 invalidTxs=0
+I[2019-05-15|15:07:17.207] Committed state                              module=state height=4 txs=0 appHash=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
+```
+
+### You may stop, and RUN again
+```
+I[2019-05-15|14:48:58.191] Starting ABCI with Tendermint                module=main 
+I[2019-05-15|14:48:58.343] Loading mem state                            module=main 
+I[2019-05-15|14:48:58.344] App loaded                                   module=main time=929.472µs
+I[2019-05-15|14:48:58.399] Search index loaded!                         module=main time=16.928556ms
+I[2019-05-15|14:48:58.399] Search index starting listen new links       module=main 
+I[2019-05-15|14:48:58.399] Search index starting listen new rank        module=main 
+E[2019-05-15|14:48:58.638] Couldn't connect to any seeds                module=p2p 
+I[2019-05-15|14:49:03.716] Executed block                               module=state height=2032 validTxs=0 invalidTxs=0
+I[2019-05-15|14:49:03.755] Committed state                              module=state height=2032 txs=0 appHash=1BAA91AD6FD9742B7B094204037F80A8174673BA0FF304D3FF5DFEEAF8FF7DDC
+I[2019-05-15|14:49:08.759] Executed block                               module=state height=2033 validTxs=0 invalidTxs=0
+I[2019-05-15|14:49:08.793] Committed state                              module=state height=2033 txs=0 appHash=1BAA91AD6FD9742B7B094204037F80A8174673BA0FF304D3FF5DFEEAF8FF7DDC
+I[2019-05-15|14:49:13.826] Executed block                               module=state height=2034 validTxs=0 invalidTxs=0
+I[2019-05-15|14:49:13.860] Committed state                              module=state height=2034 txs=0 appHash=1BAA91AD6FD9742B7B094204037F80A8174673BA0FF304D3FF5DFEEAF8FF7DDC
+```
+
+### Reset
+You can reset chains data to genesis at any time by executing **RESET** run configuration
+```
+I[2019-05-15|15:09:43.338] Removed existing address book                module=main file=mytestnet/node0/cyberd/config/addrbook.json
+I[2019-05-15|15:09:43.345] Removed all blockchain history               module=main dir=mytestnet/node0/cyberd/data
+I[2019-05-15|15:09:43.347] Reset private validator file to genesis state module=main keyFile=mytestnet/node0/cyberd/config/priv_validator_key.json stateFile=mytestnet/node0/cyberd/data/priv_validator_state.json
+```
+
+## Exploring
+
+Guide to all commands you may to research here: [Ultimate cyberd CLI guide](https://github.com/cybercongress/cyberd/blob/master/docs/help/ultimate-commands-guide_v2.md)
+
+### Before, build cyberd cli:
+```
+go build -o cyberdcli ./cli
+```
+You will get cyberdcli into you project root
+
+### Add keys:
+```
+./cyberdcli keys add validator --recover
+```
+Enter and you protection password-passphrase and mnemocic from file **mytestnet/node0/cyberdcli/key_seed.json**
+```
+
+Enter a passphrase to encrypt your key to disk:
+Repeat the passphrase:
+> Enter your bip39 mnemonic
+inhale enforce brand fever core smart draft ceiling among cluster orbit robust tonight elephant below twice goat update uncover employ spider brass consider shiver
+
+NAME:   TYPE:   ADDRESS:                                        PUBKEY:
+validator       local   cyber18l4v00ar4xsgzc4rr40tfctcjgyp7ppwysdcns    cyberpub1addwnpepq0zm06twxtf7ezv4nj9dhud9ds0fnhkks6qw4g8pdwxzh3evggpvvksh60l
+
+```
+
+### Query status:
+```
+./cyberdcli status --indent
+```
+
+```
+{
+  "node_info": {
+    "protocol_version": {
+      "p2p": "7",
+      "block": "10",
+      "app": "0"
+    },
+    "id": "b99f3254757310d1f470f5cd0331b766f2a843f9",
+    "listen_addr": "tcp://0.0.0.0:26656",
+    "network": "chain-K6U4uZ",
+    "version": "0.30.1",
+    "channels": "4020212223303800",
+    "moniker": "node0",
+    "other": {
+      "tx_index": "on",
+      "rpc_address": "tcp://0.0.0.0:26657"
+    }
+  },
+  "sync_info": {
+    "latest_block_hash": "8059683636349AF9237FABFD147BAD89C7188571E37E8F09356B1837A88337BA",
+    "latest_app_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855",
+    "latest_block_height": "134",
+    "latest_block_time": "2019-05-15T09:04:31.768026Z",
+    "catching_up": false
+  },
+  "validator_info": {
+    "address": "9C2C13F2B6608BF00BADF501A04E728AC5FF7ADC",
+    "pub_key": {
+      "type": "tendermint/PubKeyEd25519",
+      "value": "or7X/1BYcGE1cVX5e3vG9G76JPfXZDKTDg8YL3vtKzo="
+    },
+    "voting_power": "10000000000"
+  }
+}
+
+```
+
+### Query balance:
+```
+./cyberdcli query account cyber18l4v00ar4xsgzc4rr40tfctcjgyp7ppwysdcns 
+```
+
+```
+Account:
+  Address:       cyber18l4v00ar4xsgzc4rr40tfctcjgyp7ppwysdcns
+  Pubkey:        cyberpub1addwnpepq0zm06twxtf7ezv4nj9dhud9ds0fnhkks6qw4g8pdwxzh3evggpvvksh60l
+  Coins:         10000000000000000cyb
+  AccountNumber: 0
+  Sequence:      1
+```
+
+### Query validators:
+```
+./cyberdcli query staking validators  
+```
+
+```
+Validator
+  Operator Address:           cybervaloper18l4v00ar4xsgzc4rr40tfctcjgyp7ppwy3lgak
+  Validator Consensus Pubkey: cybervalconspub1zcjduepq52ld0l6stpcxzdt32huhk77x73h05f8h6ajr9ycwpuvz77ld9vaq6ka2zl
+  Jailed:                     false
+  Status:                     Bonded
+  Tokens:                     10000000000000000
+  Delegator Shares:           10000000000000000.000000000000000000
+  Description:                {node0 tst com.com det}
+  Unbonding Height:           0
+  Unbonding Completion Time:  1970-01-01 00:00:00 +0000 UTC
+  Minimum Self Delegation:    1
+  Commission:                 rate: 0.000000000000000000, maxRate: 0.000000000000000000, maxChangeRate: 0.000000000000000000, updateTime: 2019-05-15 08:52:36.324624 +0000 UTC
+
+```
+
+### Add links
+```
+./cyberdcli link --from=validator --cid-from=QmbTARMsUw9X2ZEbBaFXRu9JEqNN2g4VZ6DPgtgZH1opy9 --cid-to=QmNWkR2v4ZEzT43xiNKJcFPkFQioGbhqsWcE5qayWQHXAo --chain-id=chain-K6U4uZ
+./cyberdcli link --from=validator --cid-from=QmbTARMsUw9X2ZEbBaFXRu9JEqNN2g4VZ6DPgtgZH1opy9 --cid-to=Qmd7AaekFAxXedSQx3B3h8Wc5aeYPYRiYF83Vjb4tVLkMM --chain-id=chain-K6U4uZ
+./cyberdcli link --from=validator --cid-from=QmbTARMsUw9X2ZEbBaFXRu9JEqNN2g4VZ6DPgtgZH1opy9 --cid-to=QmfSh5obPXmkaTd9aaNCYWxnKHZTH6EYeEh7Hq7xgGnRVy --chain-id=chain-K6U4uZ
+```
+
+```
+{"chain_id":"chain-K6U4uZ","account_number":"0","sequence":"1","fee":{"amount":null,"gas":"200000"},"msgs":[{"type":"cyberd/Link","value":{"address":"cyber18l4v00ar4xsgzc4rr40tfctcjgyp7ppwysdcns","links":[{"from":"QmbTARMsUw9X2ZEbBaFXRu9JEqNN2g4VZ6DPgtgZH1opy9","to":"QmNWkR2v4ZEzT43xiNKJcFPkFQioGbhqsWcE5qayWQHXAo"}]}}],"memo":""}
+
+confirm transaction before signing and broadcasting [Y/n]: Y
+Password to sign with 'validator':
+Response:
+  Height: 1720
+  TxHash: 68C4F6389D36747A6A609CCDD9D44027A5234850FF065C78D1B1AB3FAC421541
+  Logs: [{"msg_index":0,"success":true,"log":""}]
+  GasUsed: 31368
+  Tags: 
+    - action = link
+```
+
+### Search and get links with rank:
+```
+curl -X GET 'localhost:26657/search?cid="QmbTARMsUw9X2ZEbBaFXRu9JEqNN2g4VZ6DPgtgZH1opy9"'
+```
+
+#### Links added, rank for them will be computed at next round:
+```
+{
+  "jsonrpc": "2.0",
+  "id": "",
+  "result": {
+    "cids": [
+      {
+        "cid": "QmNWkR2v4ZEzT43xiNKJcFPkFQioGbhqsWcE5qayWQHXAo",
+        "rank": 0
+      },
+      {
+        "cid": "Qmd7AaekFAxXedSQx3B3h8Wc5aeYPYRiYF83Vjb4tVLkMM",
+        "rank": 0
+      },
+      {
+        "cid": "QmfSh5obPXmkaTd9aaNCYWxnKHZTH6EYeEh7Hq7xgGnRVy",
+        "rank": 0
+      }
+    ],
+    "total": "3",
+    "page": "0",
+    "perPage": "100"
+  }
+}%   
+```
+
+#### When rank computed:
+```
+{
+  "jsonrpc": "2.0",
+  "id": "",
+  "result": {
+    "cids": [
+      {
+        "cid": "QmNWkR2v4ZEzT43xiNKJcFPkFQioGbhqsWcE5qayWQHXAo",
+        "rank": 0.056093750000000005
+      },
+      {
+        "cid": "Qmd7AaekFAxXedSQx3B3h8Wc5aeYPYRiYF83Vjb4tVLkMM",
+        "rank": 0.056093750000000005
+      },
+      {
+        "cid": "QmfSh5obPXmkaTd9aaNCYWxnKHZTH6EYeEh7Hq7xgGnRVy",
+        "rank": 0.056093750000000005
+      }
+    ],
+    "total": "3",
+    "page": "0",
+    "perPage": "100"
+  }
+}   
+```
+
+# #fuckgoogle
+
diff --git a/docs/supported_gpu_list.md b/docs/supported_gpu_list.md
index 7cf2ec34..746b328b 100644
--- a/docs/supported_gpu_list.md
+++ b/docs/supported_gpu_list.md
@@ -1,34 +1,34 @@
-# Supported GPU list for cyber validators
-
-In our `cyber protocol` implementation on `GO` proof of relevance root hash is computed on Cuda GPUs every round as the best way to calculate merkle tree faster. We need to load the whole graph in memory for calculating that's why memory volume is important. GPU with 6Gb memory can calculate graph with ~200 M links.
-
-|GPU|Supported|Tested|CUDA cores|Memory|Year of production|
-|---|---|---|---|---|---|
-|[GEFORCE RTX 2080 Ti](https://www.nvidia.com/en-us/geforce/graphics-cards/rtx-2080-ti/)|:white_check_mark:|:x:|4352|11GB GDDR 6|2018|
-|[GEFORCE RTX 2080](https://www.nvidia.com/en-us/geforce/graphics-cards/rtx-2080/)|:white_check_mark:|:x:|4352|11GB GDDR 6|2018|
-|[GEFORCE RTX 2070](https://www.nvidia.com/en-us/geforce/graphics-cards/rtx-2070/)|:white_check_mark:|:x:|2304|8 GB GDDR6|2019|
-|[GeForce RTX 2060](https://www.nvidia.com/en-us/geforce/graphics-cards/rtx-2060/)|:white_check_mark:|:x:|1920|6 GB GDDR6|2019|
-|[GEFORCE GTX 1660 Ti](https://www.nvidia.com/en-us/geforce/graphics-cards/gtx-1660-ti/)|:white_check_mark:|:x:|1536|6GB GDDR6|2019|
-|[GEFORCE GTX 1660](https://www.nvidia.com/en-us/geforce/graphics-cards/gtx-1660-ti/)|:white_check_mark:|:x:|1408|6GB GDDR5|2019|
-|[GEFORCE GTX 1650](https://www.nvidia.com/en-us/geforce/graphics-cards/gtx-1650/)|:white_check_mark:|:white_check_mark:|896|4GB GDDR5|2019|
-|[GeForce GTX 1080](https://www.nvidia.com/en-us/geforce/products/10series/geforce-gtx-1080/)|:white_check_mark:|:white_check_mark:|2560|8 GB GDDR5X|2016|
-|[GeForce GTX 980](https://www.geforce.com/hardware/desktop-gpus/geforce-gtx-980/specifications)|:white_check_mark:|:x:|2048|4 GB GDDR5|2014|
-|[TITAN Xp](https://www.nvidia.com/en-us/titan/titan-xp/)|:white_check_mark:|:x:|3840|12 GB GDDR5|2017|
-|[GeForce GTX 1080 Ti](https://www.nvidia.com/en-us/geforce/products/10series/geforce-gtx-1080-ti/)|:white_check_mark:|:x:|3584|11 GB GDDR5X|2017|
-|[GeForce GTX 980 Ti](https://www.nvidia.com/en-us/geforce/products/10series/geforce-gtx-1080-ti/)|:white_check_mark:|:x:|2816|6 GB GDDR5|2015|
-|[GeForce GTX 1070 Ti](https://www.nvidia.com/en-us/geforce/products/10series/geforce-gtx-1070-ti/)|:white_check_mark:|:white_check_mark:|2432|8 GB GDDR5|2017|
-|[GeForce GTX 1070](https://www.nvidia.com/en-us/geforce/products/10series/geforce-gtx-1070-ti/)|:white_check_mark:|:white_check_mark:|1920|8 GB GDDR5|2016|
-|[GeForce GTX 970](https://www.nvidia.com/en-us/geforce/products/10series/geforce-gtx-1070-ti/)|:white_check_mark:|:x:|1664|4 GB GDDR5|2015|
-|[GEFORCE GTX 1060 6GB](https://www.nvidia.com/en-us/geforce/products/10series/geforce-gtx-1060/)|:white_check_mark:|:white_check_mark:|1280|6 GB GDDR5|2016|
-|[GeForce GTX 1050 Ti 4GB](https://www.nvidia.com/en-us/geforce/products/10series/geforce-gtx-1050/)|:white_check_mark:|:white_check_mark:|768|4 GB GDDR5|2016|
-|[GeForce GTX 1050 4GB mobile](https://www.techpowerup.com/gpu-specs/asus-gtx-1050-mobile-4-gb.b5497)|:white_check_mark:|:white_check_mark:|640|4 GB GDDR5|2020|
-|[GeForce GTX 745 (OEM) 4GB](https://www.geforce.com/hardware/desktop-gpus/geforce-gtx-745-oem/specifications)|:white_check_mark:|:x:|768|4 GB GDDR3|2014|
-|[GeForce GTX TITAN X](https://www.geforce.com/hardware/desktop-gpus/geforce-gtx-titan-x/specifications)|:white_check_mark:|:x:|3072|12 GB GDDR5|2016|
-|[GeForce GTX TITAN Z](https://www.geforce.com/hardware/desktop-gpus/geforce-gtx-titan-z/specifications)|:white_check_mark:|:x:|5760|12 GB GDDR5|2014|
-|[GeForce GTX TITAN Black](https://www.geforce.com/hardware/desktop-gpus/geforce-gtx-titan-black/specifications)|:white_check_mark:|:x:|2880|6 GB GDDR5|2014|
-|[GeForce GTX 770](https://www.geforce.com/hardware/desktop-gpus/geforce-gtx-770/specifications)|:white_check_mark:|:x:|1536|4 GB GDDR5|2013|
-|[Nvidia Quadro K2200](https://www.nvidia.com/content/dam/en-zz/Solutions/design-visualization/documents/75509_DS_NV_Quadro_K2200_US_NV_HR.pdf)|:white_check_mark:|:white_check_mark:|640|4 GB GDDR5|2016|
-
-If you have used some GPU from `column` supported but without :white_check_mark: at `tested` column please submit a pull request with corrections. If you have tested GPU and it's not contained in that list submit PR too.
-
-**Note** If you using some old cards (like GTX 770, or older) make sure your card will be supported by al least **v.410** of NVIDIA diver for Linux.
+# Supported GPU list for cyber validators
+
+In our `cyber protocol` implementation on `GO` proof of relevance root hash is computed on Cuda GPUs every round as the best way to calculate merkle tree faster. We need to load the whole graph in memory for calculating that's why memory volume is important. GPU with 6Gb memory can calculate graph with ~200 M links.
+
+|GPU|Supported|Tested|CUDA cores|Memory|Year of production|
+|---|---|---|---|---|---|
+|[GEFORCE RTX 2080 Ti](https://www.nvidia.com/en-us/geforce/graphics-cards/rtx-2080-ti/)|:white_check_mark:|:x:|4352|11GB GDDR 6|2018|
+|[GEFORCE RTX 2080](https://www.nvidia.com/en-us/geforce/graphics-cards/rtx-2080/)|:white_check_mark:|:x:|4352|11GB GDDR 6|2018|
+|[GEFORCE RTX 2070](https://www.nvidia.com/en-us/geforce/graphics-cards/rtx-2070/)|:white_check_mark:|:x:|2304|8 GB GDDR6|2019|
+|[GeForce RTX 2060](https://www.nvidia.com/en-us/geforce/graphics-cards/rtx-2060/)|:white_check_mark:|:x:|1920|6 GB GDDR6|2019|
+|[GEFORCE GTX 1660 Ti](https://www.nvidia.com/en-us/geforce/graphics-cards/gtx-1660-ti/)|:white_check_mark:|:x:|1536|6GB GDDR6|2019|
+|[GEFORCE GTX 1660](https://www.nvidia.com/en-us/geforce/graphics-cards/gtx-1660-ti/)|:white_check_mark:|:x:|1408|6GB GDDR5|2019|
+|[GEFORCE GTX 1650](https://www.nvidia.com/en-us/geforce/graphics-cards/gtx-1650/)|:white_check_mark:|:white_check_mark:|896|4GB GDDR5|2019|
+|[GeForce GTX 1080](https://www.nvidia.com/en-us/geforce/products/10series/geforce-gtx-1080/)|:white_check_mark:|:white_check_mark:|2560|8 GB GDDR5X|2016|
+|[GeForce GTX 980](https://www.geforce.com/hardware/desktop-gpus/geforce-gtx-980/specifications)|:white_check_mark:|:x:|2048|4 GB GDDR5|2014|
+|[TITAN Xp](https://www.nvidia.com/en-us/titan/titan-xp/)|:white_check_mark:|:x:|3840|12 GB GDDR5|2017|
+|[GeForce GTX 1080 Ti](https://www.nvidia.com/en-us/geforce/products/10series/geforce-gtx-1080-ti/)|:white_check_mark:|:x:|3584|11 GB GDDR5X|2017|
+|[GeForce GTX 980 Ti](https://www.nvidia.com/en-us/geforce/products/10series/geforce-gtx-1080-ti/)|:white_check_mark:|:x:|2816|6 GB GDDR5|2015|
+|[GeForce GTX 1070 Ti](https://www.nvidia.com/en-us/geforce/products/10series/geforce-gtx-1070-ti/)|:white_check_mark:|:white_check_mark:|2432|8 GB GDDR5|2017|
+|[GeForce GTX 1070](https://www.nvidia.com/en-us/geforce/products/10series/geforce-gtx-1070-ti/)|:white_check_mark:|:white_check_mark:|1920|8 GB GDDR5|2016|
+|[GeForce GTX 970](https://www.nvidia.com/en-us/geforce/products/10series/geforce-gtx-1070-ti/)|:white_check_mark:|:x:|1664|4 GB GDDR5|2015|
+|[GEFORCE GTX 1060 6GB](https://www.nvidia.com/en-us/geforce/products/10series/geforce-gtx-1060/)|:white_check_mark:|:white_check_mark:|1280|6 GB GDDR5|2016|
+|[GeForce GTX 1050 Ti 4GB](https://www.nvidia.com/en-us/geforce/products/10series/geforce-gtx-1050/)|:white_check_mark:|:white_check_mark:|768|4 GB GDDR5|2016|
+|[GeForce GTX 1050 4GB mobile](https://www.techpowerup.com/gpu-specs/asus-gtx-1050-mobile-4-gb.b5497)|:white_check_mark:|:white_check_mark:|640|4 GB GDDR5|2020|
+|[GeForce GTX 745 (OEM) 4GB](https://www.geforce.com/hardware/desktop-gpus/geforce-gtx-745-oem/specifications)|:white_check_mark:|:x:|768|4 GB GDDR3|2014|
+|[GeForce GTX TITAN X](https://www.geforce.com/hardware/desktop-gpus/geforce-gtx-titan-x/specifications)|:white_check_mark:|:x:|3072|12 GB GDDR5|2016|
+|[GeForce GTX TITAN Z](https://www.geforce.com/hardware/desktop-gpus/geforce-gtx-titan-z/specifications)|:white_check_mark:|:x:|5760|12 GB GDDR5|2014|
+|[GeForce GTX TITAN Black](https://www.geforce.com/hardware/desktop-gpus/geforce-gtx-titan-black/specifications)|:white_check_mark:|:x:|2880|6 GB GDDR5|2014|
+|[GeForce GTX 770](https://www.geforce.com/hardware/desktop-gpus/geforce-gtx-770/specifications)|:white_check_mark:|:x:|1536|4 GB GDDR5|2013|
+|[Nvidia Quadro K2200](https://www.nvidia.com/content/dam/en-zz/Solutions/design-visualization/documents/75509_DS_NV_Quadro_K2200_US_NV_HR.pdf)|:white_check_mark:|:white_check_mark:|640|4 GB GDDR5|2016|
+
+If you have used some GPU from `column` supported but without :white_check_mark: at `tested` column please submit a pull request with corrections. If you have tested GPU and it's not contained in that list submit PR too.
+
+**Note** If you using some old cards (like GTX 770, or older) make sure your card will be supported by al least **v.410** of NVIDIA diver for Linux.
diff --git a/docs/ultimate-commands-guide.md b/docs/ultimate-commands-guide.md
index 63e6321c..1876125e 100644
--- a/docs/ultimate-commands-guide.md
+++ b/docs/ultimate-commands-guide.md
@@ -1,812 +1,812 @@
-# Ultimate cyber CLI guide. Chain: bostrom
-
-## Install cyber client
-
-It is possible to interact with cyber even if you don't have your own node. All you need to do is install `cyber` client on your machine using the script below, paste it in the console (currently Linux supported):
-
-```bash
-bash < <(curl -s https://raw.githubusercontent.com/cybercongress/go-cyber/main/scripts/install_cyber.sh)
-```
-
-After installation, you will be able to use `cyber` to [import accounts](#account-management), create links or swap tokens.
-
-In case you have your own node, which is already running inside Docker container, please add `docker exec -ti container-name` before every cyber command:
-
-```bash
-docker exec -ti bostrom cyber --help
-```
-
-First of all, I would like to encourage you to use the  `--help` feature if you want to have a better experience using cyber. This is a really easy way to find all the necessary commands with the appropriate options and flags.
-
-For example, you can enter:
-
-```bash
-cyber --help
-```
-
-You should see this message:
-
-```bash
-Usage:
-  cyber [command]
-
-Available Commands:
-  add-genesis-account Add a genesis account to genesis.json
-  collect-gentxs      Collect genesis txs and output a genesis.json file
-  config              Create or query an application CLI configuration file
-  debug               Tool for helping with debugging your application
-  export              Export state to JSON
-  gentx               Generate a genesis tx carrying a self delegation
-  help                Help about any command
-  init                Initialize private validator, p2p, genesis, and application configuration files
-  keys                Manage your applications keys
-  migrate             Migrate genesis to a specified target version
-  query               Querying subcommands
-  start               Run the full node
-  status              Query remote node for status
-  tendermint          Tendermint subcommands
-  testnet             Initialize files for a simapp testnet
-  tx                  Transactions subcommands
-  unsafe-reset-all    Resets the blockchain database, removes address book files, and resets data/priv_validator_state.json to the genesis state
-  validate-genesis    validates the genesis file at the default location or at the location passed as an arg
-  version             Print the application binary version information
-```
-
-The help feature works like a pyramid, you can use it with any command to find available options, subcommands and flags. For example, lets explore the `query` subcommands:
-
-```bash
-cyber query --help
-```
-
-You can see the structure of the subcommand:
-
-```bash
-Usage:
-  cyber query [flags]
-  cyber query [command]
-```
-
-And the available subcommands and flags:
-
-```bash
-Querying subcommands
-
-Aliases:
-  query, q
-
-Available Commands:
-  account                  Query for account by address
-  auth                     Querying commands for the auth module
-  authz                    Querying commands for the authz module
-  bandwidth                Querying commands for the bandwidth module
-  bank                     Querying commands for the bank module
-  block                    Get verified data for a the block at given height
-  distribution             Querying commands for the distribution module
-  dmn                      Querying commands for the dmn module
-  evidence                 Query for evidence by hash or for all (paginated) submitted evidence
-  feegrant                 Querying commands for the feegrant module
-  gov                      Querying commands for the governance module
-  graph                    Querying commands for the graph module
-  grid                     Querying commands for the grid module
-  ibc                      Querying commands for the IBC module
-  ibc-transfer             IBC fungible token transfer query subcommands
-  liquidity                Querying commands for the liquidity module
-  mint                     Querying commands for the minting module
-  params                   Querying commands for the params module
-  rank                     Querying commands for the rank module
-  resources                Querying commands for the resources module
-  slashing                 Querying commands for the slashing module
-  staking                  Querying commands for the staking module
-  tendermint-validator-set Get the full tendermint validator set at given height
-  tx                       Query for a transaction by hash, "<addr>/<seq>" combination or comma-separated signatures in a committed block
-  txs                      Query for paginated transactions that match a set of events
-  upgrade                  Querying commands for the upgrade module
-  wasm                     Querying commands for the wasm module
-
-Flags:
-      --chain-id string   The network chain ID
-  -h, --help              help for query
-
-Global Flags:
-      --home string         directory for config and data (default "/root/.cyber")
-      --log_format string   The logging format (json|plain) (default "plain")
-      --log_level string    The logging level (trace|debug|info|warn|error|fatal|panic) (default "info")
-      --trace               print out full stack trace on errors
-
-Use "cyber query [command] --help" for more information about a command.
-
-```
-
-Let's explore the `bank` subcommand:
-
-```bash
-cyber query bank --help
-```
-
-We can see all of the options available for these subcommands, names and account address:
-
-```bash
-Usage:
-  cyber query bank [flags]
-  cyber query bank [command]
-
-Available Commands:
-  balances       Query for account balances by address
-  denom-metadata Query the client metadata for coin denominations
-  total          Query the total supply of coins of the chain
-```
-
-In most cases you will need just two extra flags:
-
-```bash
---from=<your_key_name> \
---chain-id=bostrom \
---node=<rpc_node_path>
-```
-
-That's it. This is a very useful tool for using cyber and troubleshooting.
-
-## Glossary
-
-**Bonded tokens** - Tokens that are nominated to a validator, non transferable.
-
-**Commission** -  The tokens that you've earned via validating from delegators.
-
-**Dyson Sphere** - Construct in cyber responsible for energy transformation and routing.
-
-**Investminting** - Process of convertation Hydrogen to Volts or Amperes, locking a certain amount of H for a certain amount of time produces some V or A.
-
-**Hero** - A validator.
-
-**Hydrogen** - Token issued after boot delegation, 1:1 H to boot. Used to generate enery through the Dyson sphere (investminting process).
-
-**Unbonding** - The process of taking back your share (delegated tokens + any rewards). 4 days for `bostrom` chain.
-
-
-**link** - A reference between a CID key and a CID value. Link message cost is `100*n`, where `n` is the number of links in a message. Link finalization time is 1 block. New rank for CIDs of links will be recalculated at a period of 5 blocks.
-
-**liquid tokens** - Transferable tokens within the cyber.
-
-**local keystore** - A store with keys on your local machine.
-
-**rewards** - Tokens that a hero earned via delegation. To reduce network load all the rewards are stored in a pool. You can take your part of the bounty at any time with commands from the **delegator** section.
-
-**<comission_rate_percentage>** - The commission that a validator gets for their work. Must be a fraction >0 and <=1
-
-**<delegator_address>** - Delegator address. Starts with `bostrom` most often coinciding with **<key_address>**
-
-**<key_address>** - An account address. Starts with `bostrom`
-
-**<key_name>** - The name of the account in cyber
-
-**<operator_address>** - Validator address. Starts with `cybervaloper`
-
-**<shares_percentage>** - The part of illiquid tokens that you want to unbond or redelegate. Must be a fraction >0 and <=1
-
-**<chain_id>** - The current version of the chain  (bostrom).
-
-## General commands
-
-### Show all validators
-
-Return the set of all active and jailed validators:
-
-```bash
-cyber query staking validators 
-```
-
-### Show chain status
-
-Return general chain information:
-
-```bash
- cyber status
-```
-
-### Distribution params
-
-```bash
- cyber query distribution params 
-```
-
-### Staking params
-
-Chain staking info:
-
-```bash
- cyber query staking params 
-```
-
-### Staking pool
-
-```bash
- cyber query staking pool 
-```
-
-## Account management
-
-### Import an account with a seed phrase and store it in the local keystore
-
-```bash
- cyber keys add <your_key_name> --recover
-```
-
-### Create a new account
-
-```bash
- cyber keys add <your_key_name>
-```
-
-### Show account information
-
-Name, address and the public key of the current account
-
-```bash
- cyber keys show <your_key_name>
-```
-
-### Show account balance
-
-Return account number and amount of tokens.
-
-```bash
- cyber query bank balances <your_key_address>
-```
-
-### List existing keys
-
-Return all the existing keys in cyber:
-
-```bash
- cyber keys list
-```
-
-### Delete account from cyber
-
-```bash
- cyber keys delete <deleting_key_name>
-```
-
-### Keyring manipulation settings
-
-**Important note**: Starting with v.38, Cosmos-SDK uses os-native keyring to store all of your keys. We've noticed that in certain cases it does not work well by default (for example if you don't have any GUI installed on your machine). If during the execution `cyber keys add` command, you are getting this type of error:
-
-```bash
-panic: No such interface 'org.freedesktop.DBus.Properties' on object at path /
-
-goroutine 1 [running]:
-github.com/cosmos/cosmos-sdk/crypto/keys.keyringKeybase.writeInfo(0x1307a18, 0x1307a10, 0xc000b37160, 0x1, 0x1, 0xc000b37170, 0x1, 0x1, 0x147a6c0, 0xc000f1c780, ...)
-    /root/go/pkg/mod/github.com/cosmos/cosmos-sdk@v0.38.1/crypto/keys/keyring.go:479 +0x38c
-github.com/cosmos/cosmos-sdk/crypto/keys.keyringKeybase.writeLocalKey(0x1307a18, 0x1307a10, 0xc000b37160, 0x1, 0x1, 0xc000b37170, 0x1, 0x1, 0x147a6c0, 0xc000f1c780, ...)
-    /root/go/pkg/mod/github.com/cosmos/cosmos-sdk@v0.38.1/crypto/keys/keyring.go:465 +0x189
-github.com/cosmos/cosmos-sdk/crypto/keys.baseKeybase.CreateAccount(0x1307a18, 0x1307a10, 0xc000b37160, 0x1, 0x1, 0xc000b37170, 0x1, 0x1, 0x146aa00, 0xc000b15630, ...)
-    /root/go/pkg/mod/github.com/cosmos/cosmos-sdk@v0.38.1/crypto/keys/keybase_base.go:171 +0x192
-github.com/cosmos/cosmos-sdk/crypto/keys.keyringKeybase.CreateAccount(...)
-    /root/go/pkg/mod/github.com/cosmos/cosmos-sdk@v0.38.1/crypto/keys/keyring.go:107
-github.com/cosmos/cosmos-sdk/client/keys.RunAddCmd(0xc000f0b400, 0xc000f125f0, 0x1, 0x1, 0x148dcc0, 0xc000aca550, 0xc000ea75c0, 0xc000ae1c08, 0x5e93b7)
-    /root/go/pkg/mod/github.com/cosmos/cosmos-sdk@v0.38.1/client/keys/add.go:273 +0xa8b
-... etc
-```
-
-You will have to use another keyring backend to keep your keys. 
-
-In that case you'll have to use file based keyring by adding the `--keyring-backend file` option to every key manipulation command:
-
-```bash
-cyber keys add key_name --keyring-backend file
-```
-
-That means that you've set your keyring-backend to a local file. *Note*, in this case, all the keys in your keyring will be encrypted using the same password. If you would like to set up a unique password for each key, you should set a unique `--home` folder for each key. To do that, just use `--home=/<unique_path_to_key_folder>/` with setup keyring backend and at all interactions with keys when using cyber:
-
-```bash
-cyber keys add <your_second_key_name> --keyring-backend file --home=/<unique_path_to_key_folder>/
-cyber keys list --home=/<unique_path_to_key_folder>/
-```
-
-### Send tokens
-
-```bash
-cyber tx bank send [from_key_or_address] [to_address] [amount] \
---from=<your_key_name> \
---chain-id=bostrom
-```
-
-### Linking content
-
-Only IPFS hashes are available to use as CIDs
-
-```bash
-cyber tx graph cyberlink [cid-from] [cid-to] [flags] \
---from=<your_key_name> \
---chain-id=bostrom
-```
-
-Real command example:
-
-```bash 
-cyber tx graph cyberlink QmWZYRj344JSLShtBnrMS4vw5DQ2zsGqrytYKMqcQgEneB QmfZwbahFLTcB3MTMT8TA8si5khhRmzm7zbHToo4WVK3zn --from fuckgoogle --chain-id bostrom --yes
-```
-
-## Validator commands
-
-### Get all validators
-
-```bash
- cyber query staking validators 
-```
-
-### State of a current validator
-
-```bash
-cyber query staking validator <operator_address>
-```
-
-### Return all delegations to a validator
-
-```bash
- cyber query staking delegations-to <operator_address>
-```
-
-### Edit the commission in an existing validator account
-
-```bash
- cyber tx staking edit-validator \
-  --from=<your_key_name> \
-  --commission-rate=<new_comission_rate_percentage> \
-  --chain-id=bostrom
-```
-
-### Withdraw the commission for any delegation
-
-```bash
- cyber tx distribution withdraw-rewards <operator_address> --commission \
-  --from=<your_key_name> \
-  --chain-id=bostrom
-```
-
-### Edit the site and description for an existing validator account
-
-```bash
- cyber tx staking edit-validator \
-  --from=<your_key_name> \
-  --details="<description>" \
-  --website=<your_website> \
-  --chain-id=bostrom
-```
-
-### Unjail a validator previously jailed for downtime
-
-```bash
- cyber tx slashing unjail --from=<your_key_name> --chain-id=bostrom
-```
-
-### Get info about a redelegation process from a validator
-
-```bash
- cyber query staking redelegations-from <operator_address>
-```
-
-## Delegator commands
-
-### Return distribution delegator rewards for a specified validator
-
-```bash
- cyber query distribution rewards <delegator_address> <operator_address>
-```
-
-### Return delegator shares for the specified validator
-
-```bash
- cyber query staking delegation <delegator_address> <operator_address>
-```
-
-### Return all delegations made from a delegator
-
-```bash
- cyber query staking delegations <delegator_address>
-```
-
-### Return all unbonding delegations from a validator
-
-```bash
- cyber query staking unbonding-delegations-from <operator_address>
-```
-
-### Withdraw rewards for any delegation
-
-```bash
- cyber tx distribution withdraw-rewards <operator_address> \
-  --from=<your_key_name> \
-  --chain-id=bostrom
-```
-
-### Withdraw all delegation rewards
-
-```bash
- cyber tx distribution withdraw-all-rewards \
-  --from=<your_key_name> \
-  --chain-id=bostrom
-```
-
-### Change the default withdrawal address for rewards associated with an address
-
-```bash
- cyber tx distribution set-withdraw-addr <your_new_address> \
-  --from=<your_key_name> \
-  --chain-id=bostrom
-```
-
-### Delegate liquid tokens to a validator
-
-```bash
- cyber tx staking delegate <operator_address> <amount_boot> \
-  --from=<your_key_name> \
-  --chain-id=bostrom
-```
-
-### Redelegate illiquid tokens from one validator to another in absolute BOOT value
-
-> There is a 4-day unbonding period
-
-```bash
- cyber tx staking redelegate <old_operator_address> <new_operator_address> <amount_boot> \
- --from=<your_key_name> \
- --chain-id=bostrom
-```
-
-### Redelegate illiquid tokens from one validator to another in percentages
-
-```bash
- cyber tx staking redelegate <old_operator_address> <new_operator_address> <shares_percentage>
-  --from=<your_key_name> \
-  --chain-id=bostrom
-```
-
-### Unbond shares from a validator in absolute BOOT value
-
-> 8 days for unbonding
-
-```bash
- cyber tx staking unbond <operator_address> <amount_boot>
-  --from=<your_key_name> \
-  --chain-id=bostrom
-```
-
-### Unbond shares from a validator in percentages
-
-> 8 days for unbonding
-
-```bash
- cyber tx staking unbond <operator_address> <shares_percentage>
-  --from=<your_key_name> \
-  --chain-id=bostrom
-```
-
-### Get info about the unbonding delegation process to any validator
-
-```bash
- cyber query staking unbonding-delegation <delegator_address> <operator_address>
-```
-
-### Get info about the unbonding delegation process to all unbonded validators
-
-```bash
- cyber query staking unbonding-delegation <delegator_address>
-```
-
-### Get info about redelegation process from to current validator
-
-```bash
- cyber query staking redelegation <delegator_address> <old_operator_address> <new_operator_address>
-```
-
-### Get the info about all the redelegation processes by a delegator
-
-```bash
- cyber query staking redelegations <delegator_address>
-```
-
-## Governance and voting
-
-### Query specific proposal
-
-```bash
-cyber q gov proposal <proposal_id> 
-```
-
-### Query all proposals
-
-```bash
-cyber q gov proposals 
-```
-
-### Query votes on proposal
-
-```bash
-cyber q gov votes 
-```
-
-### Query parameters from governance module
-
-```bash
-cyber q gov params
-```
-
-### Vote for specific proposal
-
-```bash
-cyber tx gov vote <proposal_id> <vote_option:_yes_no_abstain> \
---from=<your_key_name> \
---chain-id=bostrom
-```
-
-### Submit text proposal
-
-```bash
-cyber tx gov submit-proposal --title="Test Proposal" --description="My awesome proposal" --type="Text" --deposit="10boot" \
---from=<your_key_name> \
---chain-id=bostrom
-```
-
-### Submit community spend proposal
-
-```bash
-cyber tx gov submit-proposal community-pool-spend <path/to/proposal.json> \
---from=<key_or_address> \
---chain-id=bostrom
-```
-
-Where `proposal.json` is a file, structured in following way:
-
-```json
-{
-  "title": "Community Pool Spend",
-  "description": "Pay me some boots!",
-  "recipient": "bostrom1s5afhd6gxevu37mkqcvvsj8qeylhn0rz46zdlq",
-  "amount": [
-    {
-      "denom": "boot",
-      "amount": "10000"
-    }
-  ],
-  "deposit": [
-    {
-      "denom": "boot",
-      "amount": "10000"
-    }
-  ]
-}
-```
-
-### Submit chain parameters change proposal
-
-```bash
-cyber tx gov submit-proposal param-change <path/to/proposal.json> \
---from=<key_or_address> \
---chain-id=bostrom
-```
-
-Where `proposal.json` is a file, structured in following way:
-
-```json
-{
-  "title": "Staking Param Change",
-  "description": "Update max validators",
-  "changes": [
-    {
-      "subspace": "staking",
-      "key": "MaxValidators",
-      "value": 105
-    }
-  ],
-  "deposit": [
-    {
-      "denom": "stake",
-      "amount": "10000"
-    }
-  ]
-}
-```
-
-Few examples of real param-change proposals:
-
-- Change max block bandwidth:
-
-  ```json
-  {
-    "title": "Insrease max block bandwidth to 500000",
-    "description": "Increase max block bandwidth to 500000.\n",
-    "changes": [
-      {
-        "subspace": "bandwidth",
-        "key": "MaxBlockBandwidth",
-        "value": "500000"
-      }
-    ],
-    "deposit": "10000boot"
-  }
-  ```
-- Increase max block gas:
-
-  ```json
-  {
-    "title": "Increase max gasprice",
-    "description": "Increase  maximum block gas.\n",
-    "changes": [
-      {
-        "subspace": "baseapp",
-        "key": "BlockParams",
-        "value": '"{\n                \"max_bytes\": \"22020096\",  \n                \"max_gas\": \"200000000\",\n                 \"time_iota_ms\": \"1000\"\n            }"'
-      }
-    ],
-    "deposit": "10000boot"
-  }
-  ```
-
-- Change rank calculation window:
-
-  ```json
-  {
-    "title": "Change rank calculation window to 25",
-    "description": "Increase rank calculation window from every 5 to every 25 blocks.\n",
-    "changes": [
-      {
-        "subspace": "rank",
-        "key": "CalculationPeriod",
-        "value": "25"
-      }
-    ],
-    "deposit": "10000boot"
-  }
-  ```
-
-## Liquidity and pools 
-
-Cyber has Gravity-DEX module implemented, so it is possible to create pools, swap tokens and add\remove liquidity to exisitng pools: 
-
-```bash
-Liquidity transaction subcommands
-
-Usage:
-  cyber tx liquidity [flags]
-  cyber tx liquidity [command]
-
-Available Commands:
-  create-pool Create liquidity pool and deposit coins
-  deposit     Deposit coins to a liquidity pool
-  swap        Swap offer coin with demand coin from the liquidity pool with the given order price
-  withdraw    Withdraw pool coin from the specified liquidity pool
-```
-
-### Create liquidity pool
-
-
-This example creates a liquidity pool of pool-type 1 (two coins) and deposits 2000000milliampere and 200000000000boot.
-New liquidity pools can be created only for coin combinations that do not already exist in the network.
-
-[pool-type]: The id of the liquidity pool-type. The only supported pool type is 1
-[deposit-coins]: The amount of coins to deposit to the liquidity pool. The number of deposit coins must be 2 in pool type 1.
-
-Example:
-
-```bash
-cyber tx liquidity create-pool 1 2000000milliampere,200000000000boot \
---from=mykey \
---chain-id=bostrom  \
---yes
-```
-
-### Deposit tokens to liquidity pool
-
-Deposit coins a liquidity pool.
-
-This deposit request is not processed immediately since it is accumulated in the liquidity pool batch.
-All requests in a batch are treated equally and executed at the same swap price.
-
-Example:
-
-```bash
-cyber tx liquidity deposit 1 100000000milliampere,50000000000boot \
---from=mykey \
---chain-id=bostrom
-```
-
-This example request deposits 100000000milliampere and 50000000000boot to pool-id 1.
-Deposits must be the same coin denoms as the reserve coins.
-
-[pool-id]: The pool id of the liquidity pool
-[deposit-coins]: The amount of coins to deposit to the liquidity pool
-
-### Swap coins
-
-Swap offer coin with demand coin from the liquidity pool with the given order price.
-
-This swap request is not processed immediately since it is accumulated in the liquidity pool batch.
-All requests in a batch are treated equally and executed at the same swap price.
-The order of swap requests is ignored since the universal swap price is calculated in every batch to prevent front running.
-
-The requested swap is executed with a swap price that is calculated from the given swap price function of the pool, the other swap requests, and the liquidity pool coin reserve status.
-Swap orders are executed only when the execution swap price is equal to or greater than the submitted order price of the swap order.
-
-Example:
-
-```bash
-cyber tx liquidity swap 1 1 50000000boot hydrogen 0.019 0.003 \
---from=mykey \
---chain-id=bostrom
-```
-
-For this example, imagine that an existing liquidity pool has with 1000000000hydrogen and 50000000000boot.
-This example request swaps 50000000boot for at least 950000hydrogen with the order price of 0.019 and swap fee rate of 0.003.
-A sufficient balance of half of the swap-fee-rate of the offer coin is required to reserve the offer coin fee.
-
-The order price is the exchange ratio of X/Y, where X is the amount of the first coin and Y is the amount of the second coin when their denoms are sorted alphabetically.
-Increasing order price reduces the possibility for your request to be processed and results in buying hydrogen at a lower price than the pool price.
-
-For explicit calculations, The swap fee rate must be the value that is set as liquidity parameter in the current network.
-The only supported swap-type is 1. For the detailed swap algorithm, see https://github.com/tendermint/liquidity
-
-[pool-id]: The pool id of the liquidity pool
-[swap-type]: The swap type of the swap message. The only supported swap type is 1 (instant swap).
-[offer-coin]: The amount of offer coin to swap
-[demand-coin-denom]: The denomination of the coin to exchange with offer coin
-[order-price]: The limit order price for the swap order. The price is the exchange ratio of X/Y where X is the amount of the first coin and Y is the amount of the second coin when their denoms are sorted alphabetically
-[swap-fee-rate]: The swap fee rate to pay for swap that is proportional to swap amount. The swap fee rate must be the value that is set as liquidity parameter in the current network.
-
-Usage:
-
-```bash
-  cyber tx liquidity swap [pool-id] [swap-type] [offer-coin] [demand-coin-denom] [order-price] [swap-fee-rate] [flags]
-```
-
-### Withdraw tokens from liquidity pool
-
-Withdraw pool coin from the specified liquidity pool.
-
-This swap request is not processed immediately since it is accumulated in the liquidity pool batch.
-All requests in a batch are treated equally and executed at the same swap price.
-
-Example:
-
-```bash
- cyber tx liquidity withdraw 1 10000pool96EF6EA6E5AC828ED87E8D07E7AE2A8180570ADD212117B2DA6F0B75D17A6295 \
- --from=mykey \
- --chain-id=bostrom
-```
-
-This example request withdraws 10000 pool coin from the specified liquidity pool.
-The appropriate pool coin must be requested from the specified pool.
-
-[pool-id]: The pool id of the liquidity pool
-[pool-coin]: The amount of pool coin to withdraw from the liquidity pool
-
-Usage:
-
-```bash
-  cyber tx liquidity withdraw [pool-id] [pool-coin] [flags]\
-  --from=<key_or_address> \
-  --chain-id=bostrom
-```
-
-### Query existing pools
-
-Query details of a liquidity pool
-
-```bash
-cyber query liquidity pool 1
-```
-
-Example (with pool coin denom):
-
-```bash
-cyber query liquidity pool --pool-coin-denom=[denom]
-```
-
-Query details about all liquidity pools on a network.
-Example:
-
-```bash
-cyber query liquidity pools
-```
-
-## 
+# Ultimate cyber CLI guide. Chain: bostrom
+
+## Install cyber client
+
+It is possible to interact with cyber even if you don't have your own node. All you need to do is install `cyber` client on your machine using the script below, paste it in the console (currently Linux supported):
+
+```bash
+bash < <(curl -s https://raw.githubusercontent.com/cybercongress/go-cyber/main/scripts/install_cyber.sh)
+```
+
+After installation, you will be able to use `cyber` to [import accounts](#account-management), create links or swap tokens.
+
+In case you have your own node, which is already running inside Docker container, please add `docker exec -ti container-name` before every cyber command:
+
+```bash
+docker exec -ti bostrom cyber --help
+```
+
+First of all, I would like to encourage you to use the  `--help` feature if you want to have a better experience using cyber. This is a really easy way to find all the necessary commands with the appropriate options and flags.
+
+For example, you can enter:
+
+```bash
+cyber --help
+```
+
+You should see this message:
+
+```bash
+Usage:
+  cyber [command]
+
+Available Commands:
+  add-genesis-account Add a genesis account to genesis.json
+  collect-gentxs      Collect genesis txs and output a genesis.json file
+  config              Create or query an application CLI configuration file
+  debug               Tool for helping with debugging your application
+  export              Export state to JSON
+  gentx               Generate a genesis tx carrying a self delegation
+  help                Help about any command
+  init                Initialize private validator, p2p, genesis, and application configuration files
+  keys                Manage your applications keys
+  migrate             Migrate genesis to a specified target version
+  query               Querying subcommands
+  start               Run the full node
+  status              Query remote node for status
+  tendermint          Tendermint subcommands
+  testnet             Initialize files for a simapp testnet
+  tx                  Transactions subcommands
+  unsafe-reset-all    Resets the blockchain database, removes address book files, and resets data/priv_validator_state.json to the genesis state
+  validate-genesis    validates the genesis file at the default location or at the location passed as an arg
+  version             Print the application binary version information
+```
+
+The help feature works like a pyramid, you can use it with any command to find available options, subcommands and flags. For example, lets explore the `query` subcommands:
+
+```bash
+cyber query --help
+```
+
+You can see the structure of the subcommand:
+
+```bash
+Usage:
+  cyber query [flags]
+  cyber query [command]
+```
+
+And the available subcommands and flags:
+
+```bash
+Querying subcommands
+
+Aliases:
+  query, q
+
+Available Commands:
+  account                  Query for account by address
+  auth                     Querying commands for the auth module
+  authz                    Querying commands for the authz module
+  bandwidth                Querying commands for the bandwidth module
+  bank                     Querying commands for the bank module
+  block                    Get verified data for a the block at given height
+  distribution             Querying commands for the distribution module
+  dmn                      Querying commands for the dmn module
+  evidence                 Query for evidence by hash or for all (paginated) submitted evidence
+  feegrant                 Querying commands for the feegrant module
+  gov                      Querying commands for the governance module
+  graph                    Querying commands for the graph module
+  grid                     Querying commands for the grid module
+  ibc                      Querying commands for the IBC module
+  ibc-transfer             IBC fungible token transfer query subcommands
+  liquidity                Querying commands for the liquidity module
+  mint                     Querying commands for the minting module
+  params                   Querying commands for the params module
+  rank                     Querying commands for the rank module
+  resources                Querying commands for the resources module
+  slashing                 Querying commands for the slashing module
+  staking                  Querying commands for the staking module
+  tendermint-validator-set Get the full tendermint validator set at given height
+  tx                       Query for a transaction by hash, "<addr>/<seq>" combination or comma-separated signatures in a committed block
+  txs                      Query for paginated transactions that match a set of events
+  upgrade                  Querying commands for the upgrade module
+  wasm                     Querying commands for the wasm module
+
+Flags:
+      --chain-id string   The network chain ID
+  -h, --help              help for query
+
+Global Flags:
+      --home string         directory for config and data (default "/root/.cyber")
+      --log_format string   The logging format (json|plain) (default "plain")
+      --log_level string    The logging level (trace|debug|info|warn|error|fatal|panic) (default "info")
+      --trace               print out full stack trace on errors
+
+Use "cyber query [command] --help" for more information about a command.
+
+```
+
+Let's explore the `bank` subcommand:
+
+```bash
+cyber query bank --help
+```
+
+We can see all of the options available for these subcommands, names and account address:
+
+```bash
+Usage:
+  cyber query bank [flags]
+  cyber query bank [command]
+
+Available Commands:
+  balances       Query for account balances by address
+  denom-metadata Query the client metadata for coin denominations
+  total          Query the total supply of coins of the chain
+```
+
+In most cases you will need just two extra flags:
+
+```bash
+--from=<your_key_name> \
+--chain-id=bostrom \
+--node=<rpc_node_path>
+```
+
+That's it. This is a very useful tool for using cyber and troubleshooting.
+
+## Glossary
+
+**Bonded tokens** - Tokens that are nominated to a validator, non transferable.
+
+**Commission** -  The tokens that you've earned via validating from delegators.
+
+**Dyson Sphere** - Construct in cyber responsible for energy transformation and routing.
+
+**Investminting** - Process of convertation Hydrogen to Volts or Amperes, locking a certain amount of H for a certain amount of time produces some V or A.
+
+**Hero** - A validator.
+
+**Hydrogen** - Token issued after boot delegation, 1:1 H to boot. Used to generate enery through the Dyson sphere (investminting process).
+
+**Unbonding** - The process of taking back your share (delegated tokens + any rewards). 4 days for `bostrom` chain.
+
+
+**link** - A reference between a CID key and a CID value. Link message cost is `100*n`, where `n` is the number of links in a message. Link finalization time is 1 block. New rank for CIDs of links will be recalculated at a period of 5 blocks.
+
+**liquid tokens** - Transferable tokens within the cyber.
+
+**local keystore** - A store with keys on your local machine.
+
+**rewards** - Tokens that a hero earned via delegation. To reduce network load all the rewards are stored in a pool. You can take your part of the bounty at any time with commands from the **delegator** section.
+
+**<comission_rate_percentage>** - The commission that a validator gets for their work. Must be a fraction >0 and <=1
+
+**<delegator_address>** - Delegator address. Starts with `bostrom` most often coinciding with **<key_address>**
+
+**<key_address>** - An account address. Starts with `bostrom`
+
+**<key_name>** - The name of the account in cyber
+
+**<operator_address>** - Validator address. Starts with `cybervaloper`
+
+**<shares_percentage>** - The part of illiquid tokens that you want to unbond or redelegate. Must be a fraction >0 and <=1
+
+**<chain_id>** - The current version of the chain  (bostrom).
+
+## General commands
+
+### Show all validators
+
+Return the set of all active and jailed validators:
+
+```bash
+cyber query staking validators 
+```
+
+### Show chain status
+
+Return general chain information:
+
+```bash
+ cyber status
+```
+
+### Distribution params
+
+```bash
+ cyber query distribution params 
+```
+
+### Staking params
+
+Chain staking info:
+
+```bash
+ cyber query staking params 
+```
+
+### Staking pool
+
+```bash
+ cyber query staking pool 
+```
+
+## Account management
+
+### Import an account with a seed phrase and store it in the local keystore
+
+```bash
+ cyber keys add <your_key_name> --recover
+```
+
+### Create a new account
+
+```bash
+ cyber keys add <your_key_name>
+```
+
+### Show account information
+
+Name, address and the public key of the current account
+
+```bash
+ cyber keys show <your_key_name>
+```
+
+### Show account balance
+
+Return account number and amount of tokens.
+
+```bash
+ cyber query bank balances <your_key_address>
+```
+
+### List existing keys
+
+Return all the existing keys in cyber:
+
+```bash
+ cyber keys list
+```
+
+### Delete account from cyber
+
+```bash
+ cyber keys delete <deleting_key_name>
+```
+
+### Keyring manipulation settings
+
+**Important note**: Starting with v.38, Cosmos-SDK uses os-native keyring to store all of your keys. We've noticed that in certain cases it does not work well by default (for example if you don't have any GUI installed on your machine). If during the execution `cyber keys add` command, you are getting this type of error:
+
+```bash
+panic: No such interface 'org.freedesktop.DBus.Properties' on object at path /
+
+goroutine 1 [running]:
+github.com/cosmos/cosmos-sdk/crypto/keys.keyringKeybase.writeInfo(0x1307a18, 0x1307a10, 0xc000b37160, 0x1, 0x1, 0xc000b37170, 0x1, 0x1, 0x147a6c0, 0xc000f1c780, ...)
+    /root/go/pkg/mod/github.com/cosmos/cosmos-sdk@v0.38.1/crypto/keys/keyring.go:479 +0x38c
+github.com/cosmos/cosmos-sdk/crypto/keys.keyringKeybase.writeLocalKey(0x1307a18, 0x1307a10, 0xc000b37160, 0x1, 0x1, 0xc000b37170, 0x1, 0x1, 0x147a6c0, 0xc000f1c780, ...)
+    /root/go/pkg/mod/github.com/cosmos/cosmos-sdk@v0.38.1/crypto/keys/keyring.go:465 +0x189
+github.com/cosmos/cosmos-sdk/crypto/keys.baseKeybase.CreateAccount(0x1307a18, 0x1307a10, 0xc000b37160, 0x1, 0x1, 0xc000b37170, 0x1, 0x1, 0x146aa00, 0xc000b15630, ...)
+    /root/go/pkg/mod/github.com/cosmos/cosmos-sdk@v0.38.1/crypto/keys/keybase_base.go:171 +0x192
+github.com/cosmos/cosmos-sdk/crypto/keys.keyringKeybase.CreateAccount(...)
+    /root/go/pkg/mod/github.com/cosmos/cosmos-sdk@v0.38.1/crypto/keys/keyring.go:107
+github.com/cosmos/cosmos-sdk/client/keys.RunAddCmd(0xc000f0b400, 0xc000f125f0, 0x1, 0x1, 0x148dcc0, 0xc000aca550, 0xc000ea75c0, 0xc000ae1c08, 0x5e93b7)
+    /root/go/pkg/mod/github.com/cosmos/cosmos-sdk@v0.38.1/client/keys/add.go:273 +0xa8b
+... etc
+```
+
+You will have to use another keyring backend to keep your keys. 
+
+In that case you'll have to use file based keyring by adding the `--keyring-backend file` option to every key manipulation command:
+
+```bash
+cyber keys add key_name --keyring-backend file
+```
+
+That means that you've set your keyring-backend to a local file. *Note*, in this case, all the keys in your keyring will be encrypted using the same password. If you would like to set up a unique password for each key, you should set a unique `--home` folder for each key. To do that, just use `--home=/<unique_path_to_key_folder>/` with setup keyring backend and at all interactions with keys when using cyber:
+
+```bash
+cyber keys add <your_second_key_name> --keyring-backend file --home=/<unique_path_to_key_folder>/
+cyber keys list --home=/<unique_path_to_key_folder>/
+```
+
+### Send tokens
+
+```bash
+cyber tx bank send [from_key_or_address] [to_address] [amount] \
+--from=<your_key_name> \
+--chain-id=bostrom
+```
+
+### Linking content
+
+Only IPFS hashes are available to use as CIDs
+
+```bash
+cyber tx graph cyberlink [cid-from] [cid-to] [flags] \
+--from=<your_key_name> \
+--chain-id=bostrom
+```
+
+Real command example:
+
+```bash 
+cyber tx graph cyberlink QmWZYRj344JSLShtBnrMS4vw5DQ2zsGqrytYKMqcQgEneB QmfZwbahFLTcB3MTMT8TA8si5khhRmzm7zbHToo4WVK3zn --from fuckgoogle --chain-id bostrom --yes
+```
+
+## Validator commands
+
+### Get all validators
+
+```bash
+ cyber query staking validators 
+```
+
+### State of a current validator
+
+```bash
+cyber query staking validator <operator_address>
+```
+
+### Return all delegations to a validator
+
+```bash
+ cyber query staking delegations-to <operator_address>
+```
+
+### Edit the commission in an existing validator account
+
+```bash
+ cyber tx staking edit-validator \
+  --from=<your_key_name> \
+  --commission-rate=<new_comission_rate_percentage> \
+  --chain-id=bostrom
+```
+
+### Withdraw the commission for any delegation
+
+```bash
+ cyber tx distribution withdraw-rewards <operator_address> --commission \
+  --from=<your_key_name> \
+  --chain-id=bostrom
+```
+
+### Edit the site and description for an existing validator account
+
+```bash
+ cyber tx staking edit-validator \
+  --from=<your_key_name> \
+  --details="<description>" \
+  --website=<your_website> \
+  --chain-id=bostrom
+```
+
+### Unjail a validator previously jailed for downtime
+
+```bash
+ cyber tx slashing unjail --from=<your_key_name> --chain-id=bostrom
+```
+
+### Get info about a redelegation process from a validator
+
+```bash
+ cyber query staking redelegations-from <operator_address>
+```
+
+## Delegator commands
+
+### Return distribution delegator rewards for a specified validator
+
+```bash
+ cyber query distribution rewards <delegator_address> <operator_address>
+```
+
+### Return delegator shares for the specified validator
+
+```bash
+ cyber query staking delegation <delegator_address> <operator_address>
+```
+
+### Return all delegations made from a delegator
+
+```bash
+ cyber query staking delegations <delegator_address>
+```
+
+### Return all unbonding delegations from a validator
+
+```bash
+ cyber query staking unbonding-delegations-from <operator_address>
+```
+
+### Withdraw rewards for any delegation
+
+```bash
+ cyber tx distribution withdraw-rewards <operator_address> \
+  --from=<your_key_name> \
+  --chain-id=bostrom
+```
+
+### Withdraw all delegation rewards
+
+```bash
+ cyber tx distribution withdraw-all-rewards \
+  --from=<your_key_name> \
+  --chain-id=bostrom
+```
+
+### Change the default withdrawal address for rewards associated with an address
+
+```bash
+ cyber tx distribution set-withdraw-addr <your_new_address> \
+  --from=<your_key_name> \
+  --chain-id=bostrom
+```
+
+### Delegate liquid tokens to a validator
+
+```bash
+ cyber tx staking delegate <operator_address> <amount_boot> \
+  --from=<your_key_name> \
+  --chain-id=bostrom
+```
+
+### Redelegate illiquid tokens from one validator to another in absolute BOOT value
+
+> There is a 4-day unbonding period
+
+```bash
+ cyber tx staking redelegate <old_operator_address> <new_operator_address> <amount_boot> \
+ --from=<your_key_name> \
+ --chain-id=bostrom
+```
+
+### Redelegate illiquid tokens from one validator to another in percentages
+
+```bash
+ cyber tx staking redelegate <old_operator_address> <new_operator_address> <shares_percentage>
+  --from=<your_key_name> \
+  --chain-id=bostrom
+```
+
+### Unbond shares from a validator in absolute BOOT value
+
+> 8 days for unbonding
+
+```bash
+ cyber tx staking unbond <operator_address> <amount_boot>
+  --from=<your_key_name> \
+  --chain-id=bostrom
+```
+
+### Unbond shares from a validator in percentages
+
+> 8 days for unbonding
+
+```bash
+ cyber tx staking unbond <operator_address> <shares_percentage>
+  --from=<your_key_name> \
+  --chain-id=bostrom
+```
+
+### Get info about the unbonding delegation process to any validator
+
+```bash
+ cyber query staking unbonding-delegation <delegator_address> <operator_address>
+```
+
+### Get info about the unbonding delegation process to all unbonded validators
+
+```bash
+ cyber query staking unbonding-delegation <delegator_address>
+```
+
+### Get info about redelegation process from to current validator
+
+```bash
+ cyber query staking redelegation <delegator_address> <old_operator_address> <new_operator_address>
+```
+
+### Get the info about all the redelegation processes by a delegator
+
+```bash
+ cyber query staking redelegations <delegator_address>
+```
+
+## Governance and voting
+
+### Query specific proposal
+
+```bash
+cyber q gov proposal <proposal_id> 
+```
+
+### Query all proposals
+
+```bash
+cyber q gov proposals 
+```
+
+### Query votes on proposal
+
+```bash
+cyber q gov votes 
+```
+
+### Query parameters from governance module
+
+```bash
+cyber q gov params
+```
+
+### Vote for specific proposal
+
+```bash
+cyber tx gov vote <proposal_id> <vote_option:_yes_no_abstain> \
+--from=<your_key_name> \
+--chain-id=bostrom
+```
+
+### Submit text proposal
+
+```bash
+cyber tx gov submit-proposal --title="Test Proposal" --description="My awesome proposal" --type="Text" --deposit="10boot" \
+--from=<your_key_name> \
+--chain-id=bostrom
+```
+
+### Submit community spend proposal
+
+```bash
+cyber tx gov submit-proposal community-pool-spend <path/to/proposal.json> \
+--from=<key_or_address> \
+--chain-id=bostrom
+```
+
+Where `proposal.json` is a file, structured in following way:
+
+```json
+{
+  "title": "Community Pool Spend",
+  "description": "Pay me some boots!",
+  "recipient": "bostrom1s5afhd6gxevu37mkqcvvsj8qeylhn0rz46zdlq",
+  "amount": [
+    {
+      "denom": "boot",
+      "amount": "10000"
+    }
+  ],
+  "deposit": [
+    {
+      "denom": "boot",
+      "amount": "10000"
+    }
+  ]
+}
+```
+
+### Submit chain parameters change proposal
+
+```bash
+cyber tx gov submit-proposal param-change <path/to/proposal.json> \
+--from=<key_or_address> \
+--chain-id=bostrom
+```
+
+Where `proposal.json` is a file, structured in following way:
+
+```json
+{
+  "title": "Staking Param Change",
+  "description": "Update max validators",
+  "changes": [
+    {
+      "subspace": "staking",
+      "key": "MaxValidators",
+      "value": 105
+    }
+  ],
+  "deposit": [
+    {
+      "denom": "stake",
+      "amount": "10000"
+    }
+  ]
+}
+```
+
+Few examples of real param-change proposals:
+
+- Change max block bandwidth:
+
+  ```json
+  {
+    "title": "Insrease max block bandwidth to 500000",
+    "description": "Increase max block bandwidth to 500000.\n",
+    "changes": [
+      {
+        "subspace": "bandwidth",
+        "key": "MaxBlockBandwidth",
+        "value": "500000"
+      }
+    ],
+    "deposit": "10000boot"
+  }
+  ```
+- Increase max block gas:
+
+  ```json
+  {
+    "title": "Increase max gasprice",
+    "description": "Increase  maximum block gas.\n",
+    "changes": [
+      {
+        "subspace": "baseapp",
+        "key": "BlockParams",
+        "value": '"{\n                \"max_bytes\": \"22020096\",  \n                \"max_gas\": \"200000000\",\n                 \"time_iota_ms\": \"1000\"\n            }"'
+      }
+    ],
+    "deposit": "10000boot"
+  }
+  ```
+
+- Change rank calculation window:
+
+  ```json
+  {
+    "title": "Change rank calculation window to 25",
+    "description": "Increase rank calculation window from every 5 to every 25 blocks.\n",
+    "changes": [
+      {
+        "subspace": "rank",
+        "key": "CalculationPeriod",
+        "value": "25"
+      }
+    ],
+    "deposit": "10000boot"
+  }
+  ```
+
+## Liquidity and pools 
+
+Cyber has Gravity-DEX module implemented, so it is possible to create pools, swap tokens and add\remove liquidity to exisitng pools: 
+
+```bash
+Liquidity transaction subcommands
+
+Usage:
+  cyber tx liquidity [flags]
+  cyber tx liquidity [command]
+
+Available Commands:
+  create-pool Create liquidity pool and deposit coins
+  deposit     Deposit coins to a liquidity pool
+  swap        Swap offer coin with demand coin from the liquidity pool with the given order price
+  withdraw    Withdraw pool coin from the specified liquidity pool
+```
+
+### Create liquidity pool
+
+
+This example creates a liquidity pool of pool-type 1 (two coins) and deposits 2000000milliampere and 200000000000boot.
+New liquidity pools can be created only for coin combinations that do not already exist in the network.
+
+[pool-type]: The id of the liquidity pool-type. The only supported pool type is 1
+[deposit-coins]: The amount of coins to deposit to the liquidity pool. The number of deposit coins must be 2 in pool type 1.
+
+Example:
+
+```bash
+cyber tx liquidity create-pool 1 2000000milliampere,200000000000boot \
+--from=mykey \
+--chain-id=bostrom  \
+--yes
+```
+
+### Deposit tokens to liquidity pool
+
+Deposit coins a liquidity pool.
+
+This deposit request is not processed immediately since it is accumulated in the liquidity pool batch.
+All requests in a batch are treated equally and executed at the same swap price.
+
+Example:
+
+```bash
+cyber tx liquidity deposit 1 100000000milliampere,50000000000boot \
+--from=mykey \
+--chain-id=bostrom
+```
+
+This example request deposits 100000000milliampere and 50000000000boot to pool-id 1.
+Deposits must be the same coin denoms as the reserve coins.
+
+[pool-id]: The pool id of the liquidity pool
+[deposit-coins]: The amount of coins to deposit to the liquidity pool
+
+### Swap coins
+
+Swap offer coin with demand coin from the liquidity pool with the given order price.
+
+This swap request is not processed immediately since it is accumulated in the liquidity pool batch.
+All requests in a batch are treated equally and executed at the same swap price.
+The order of swap requests is ignored since the universal swap price is calculated in every batch to prevent front running.
+
+The requested swap is executed with a swap price that is calculated from the given swap price function of the pool, the other swap requests, and the liquidity pool coin reserve status.
+Swap orders are executed only when the execution swap price is equal to or greater than the submitted order price of the swap order.
+
+Example:
+
+```bash
+cyber tx liquidity swap 1 1 50000000boot hydrogen 0.019 0.003 \
+--from=mykey \
+--chain-id=bostrom
+```
+
+For this example, imagine that an existing liquidity pool has with 1000000000hydrogen and 50000000000boot.
+This example request swaps 50000000boot for at least 950000hydrogen with the order price of 0.019 and swap fee rate of 0.003.
+A sufficient balance of half of the swap-fee-rate of the offer coin is required to reserve the offer coin fee.
+
+The order price is the exchange ratio of X/Y, where X is the amount of the first coin and Y is the amount of the second coin when their denoms are sorted alphabetically.
+Increasing order price reduces the possibility for your request to be processed and results in buying hydrogen at a lower price than the pool price.
+
+For explicit calculations, The swap fee rate must be the value that is set as liquidity parameter in the current network.
+The only supported swap-type is 1. For the detailed swap algorithm, see https://github.com/tendermint/liquidity
+
+[pool-id]: The pool id of the liquidity pool
+[swap-type]: The swap type of the swap message. The only supported swap type is 1 (instant swap).
+[offer-coin]: The amount of offer coin to swap
+[demand-coin-denom]: The denomination of the coin to exchange with offer coin
+[order-price]: The limit order price for the swap order. The price is the exchange ratio of X/Y where X is the amount of the first coin and Y is the amount of the second coin when their denoms are sorted alphabetically
+[swap-fee-rate]: The swap fee rate to pay for swap that is proportional to swap amount. The swap fee rate must be the value that is set as liquidity parameter in the current network.
+
+Usage:
+
+```bash
+  cyber tx liquidity swap [pool-id] [swap-type] [offer-coin] [demand-coin-denom] [order-price] [swap-fee-rate] [flags]
+```
+
+### Withdraw tokens from liquidity pool
+
+Withdraw pool coin from the specified liquidity pool.
+
+This swap request is not processed immediately since it is accumulated in the liquidity pool batch.
+All requests in a batch are treated equally and executed at the same swap price.
+
+Example:
+
+```bash
+ cyber tx liquidity withdraw 1 10000pool96EF6EA6E5AC828ED87E8D07E7AE2A8180570ADD212117B2DA6F0B75D17A6295 \
+ --from=mykey \
+ --chain-id=bostrom
+```
+
+This example request withdraws 10000 pool coin from the specified liquidity pool.
+The appropriate pool coin must be requested from the specified pool.
+
+[pool-id]: The pool id of the liquidity pool
+[pool-coin]: The amount of pool coin to withdraw from the liquidity pool
+
+Usage:
+
+```bash
+  cyber tx liquidity withdraw [pool-id] [pool-coin] [flags]\
+  --from=<key_or_address> \
+  --chain-id=bostrom
+```
+
+### Query existing pools
+
+Query details of a liquidity pool
+
+```bash
+cyber query liquidity pool 1
+```
+
+Example (with pool coin denom):
+
+```bash
+cyber query liquidity pool --pool-coin-denom=[denom]
+```
+
+Query details about all liquidity pools on a network.
+Example:
+
+```bash
+cyber query liquidity pools
+```
+
+## 

From d4970ae6016f321fd4b18b86ae0c88ee98f47098 Mon Sep 17 00:00:00 2001
From: Your Name <timshak@gmail.com>
Date: Wed, 31 Jan 2024 07:38:23 +0300
Subject: [PATCH 3/3] commit message 1

---
 docs/cyber_Ledger_guide.md      |  14 +--
 docs/keystore.md                |  48 ++++----
 docs/multisig_guide.md          |  22 ++--
 docs/run_validator.md           |   2 +-
 docs/ultimate-commands-guide.md | 208 ++++++++++++++++----------------
 5 files changed, 147 insertions(+), 147 deletions(-)

diff --git a/docs/cyber_Ledger_guide.md b/docs/cyber_Ledger_guide.md
index 22835ce3..9e86aea0 100644
--- a/docs/cyber_Ledger_guide.md
+++ b/docs/cyber_Ledger_guide.md
@@ -1,16 +1,16 @@
 # Ledger nano Support
 
-It is possible to use your Ledger device with cyber to store keys and sign transactions.
+It is possible to use your Ledger device with deep to store keys and sign transactions.
 
 ## Cyberd CLI & Ledger Nano
 
 How to get started. First of all, you'll need a couple of things to be done:
 
-+ A running and synced cyber node (how to: [here](https://github.com/cybercongress/go-cyber/blob/bostrom-dev/docs/run_validator.md) and [here](https://github.com/cybercongress/go-cyber/blob/main/docs/ultimate-commands-guide.md))
++ A running and synced deep node (how to: [here](https://github.com/cybercongress/go-cyber/blob/bostrom-dev/docs/run_validator.md) and [here](https://github.com/cybercongress/go-cyber/blob/main/docs/ultimate-commands-guide.md))
 
 + [Setup](https://support.ledger.com/hc/en-us/articles/360000613793-Set-up-as-new-device) your Ledger device and [install Cosmos app on it](https://github.com/cosmos/ledger-cosmos/blob/master/README.md#installing) (the latest firmware for Ledger and Cosmos app required)
 
-It is necessary to verify that cyber is built with netgo and Ledger tags. To check that, we can run: `cyber version --long`.
+It is necessary to verify that cyber is built with netgo and Ledger tags. To check that, we can run: `deepchain version --long`.
 
 ## Add your Ledger key
 
@@ -24,7 +24,7 @@ When you made sure that your Ledger device is successfully interacting with your
 For account creation run:
 
 ``` js
-cyber keys add <your_key_name> --ledger
+deepchain keys add <your_key_name> --ledger
 ```
 
 After submitting this command your Ledger device should show a generated address and will wait for confirmation. Hit confirm the button and in the console, you'll see the following output:
@@ -42,7 +42,7 @@ After submitting this command your Ledger device should show a generated address
 By default, the `...keys add` command with account and index set to 0 of [bip44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) derivation path is used. To add more than one key account and/or index it must be specified separately in the following way:
 
 ``` js
-cyber keys add <your_key2_name> --ledger --account 1 --index 1
+deepchain keys add <your_key2_name> --ledger --account 1 --index 1
 ```
 
 You don't need to remember which numbers for account and index you've used, it will be matched to <your_key_name> automatically.
@@ -52,7 +52,7 @@ You don't need to remember which numbers for account and index you've used, it w
 To make sure you have added everything correctly just run:
 
 ``` js
-cyber keys show <key_name> -d
+deepchain keys show <key_name> -d
 ```
 
 It's necessary to confirm that the key on your Ledger matches the one shown in the console.
@@ -62,7 +62,7 @@ It's necessary to confirm that the key on your Ledger matches the one shown in t
 You are now ready to sign and send transactions. This could be done by using the `tx bank send` command. Your Ledger device should be connected and unlocked at this step. Run the following to send some CYB tokens:
 
 ``` js
-cyber tx bank send <from_key_name> <destination_address> <ammount>cyb --chain-id <current_chain_id>
+deepchain tx bank send <from_key_name> <destination_address> <ammount>cyb --chain-id <current_chain_id>
 ```
 
 `<from_key_name>` is your ledger key name, `<destination_address>` is the address of the recipient in the following format: `cyber1wq7p5qfygxr37vqqufhj5fzwlg55zmm4w0p8sw`.
diff --git a/docs/keystore.md b/docs/keystore.md
index 2f450c2c..3c7c596e 100644
--- a/docs/keystore.md
+++ b/docs/keystore.md
@@ -6,29 +6,29 @@ Key types can be conditionally divided into two groups: **agents** and **validat
 
 **Agents** keys are used for linking content, sending liquid tokens, delegating, redelegating, and undelegating tokens to validators. Also, withdrawing rewards, voting and creating multisig accounts.
 
-- `bostrom` a.k.a. address. Cyber application key.
-  - Derived from account mnemonic phrase, generated by `cyber keys add`
-  - e.g. `bostrom 15h6vd5f0wqps26zjlwrc6chah08ryu4hzzdwhc`
+- `deep` a.k.a. address. deepchain application key.
+  - Derived from account mnemonic phrase, generated by `deepchain keys add`
+  - e.g. `deep 15h6vd5f0wqps26zjlwrc6chah08ryu4hzzdwhc`
 
-- `bostrom pub` the public key of an account address. It is used for generating multisig addresses.  
-  - Derived from account mnemonic phrase, generated by `cyber keys add`
-  - e.g. `bostrom pub1zcjduc3q7fu03jnlu2xpl75s2nkt7krm6grh4cc5aqth73v0zwmea25wj2hsqhlqzm`
+- `deep pub` the public key of an account address. It is used for generating multisig addresses.  
+  - Derived from account mnemonic phrase, generated by `deepchain keys add`
+  - e.g. `deep pub1zcjduc3q7fu03jnlu2xpl75s2nkt7krm6grh4cc5aqth73v0zwmea25wj2hsqhlqzm`
 
 All agents keypairs are stored locally in the `PATH_TO_CYBER/keys` folder. 
 
 **Validators** are actors on the network committing new blocks by submitting their votes. This refers to the node itself, not a single person or a single account. Therefore, the public key here is referring to the nodes public key, not the public key of the agent address.
 
-- `bostrom valoper` validator application-level address. It is associated with a public key `bostrom valconspub`. This is the address used to identify your validator publicly. The private key associated with this address is used to delegate, unbond, claim rewards, and participate in governance. Generated by cyber on the application level. Application keys are associated with a public key prefixed by `bostrom pub` and an address prefixed by cyber  network. Both are derived from account keys generated by cyber keys add. 
-  - e.g. `bostrom valoper1carzvgq3e6y3z5kz5y6gxp3wpy3qdrv928vyah`
+- `deep valoper` validator application-level address. It is associated with a public key `deep valconspub`. This is the address used to identify your validator publicly. The private key associated with this address is used to delegate, unbond, claim rewards, and participate in governance. Generated by deepchain on the application level. Application keys are associated with a public key prefixed by `deep pub` and an address prefixed by deepchain  network. Both are derived from account keys generated by deepchain keys add. 
+  - e.g. `deep valoper1carzvgq3e6y3z5kz5y6gxp3wpy3qdrv928vyah`
 
 -  the public key of node/validator address has been recently migrated to protobuf look. The private key associated with this Tendermint PubKey is used to sign prevotes and precommits.
   - Generated when the node is created
-  - Get this value with `cyber tendermint show-validator`
+  - Get this value with `deepchain tendermint show-validator`
   - e.g. `{"@type":"/cosmos.crypto.ed25519.PubKey","key":"YxN/kkQlXBwKNF4Cgi6tiqMh2ae8+tpo9VxENmFUhv8="}`
 
 > Note: A validator's operator key is directly tied to an application key, but uses reserved prefixes solely for this purpose: `bostrom valoper`.
 
-A nodes keypair is stored in `node_key.json` and `priv_validator_key.json` at `$HOME/.cyber/config` folder. You can delete them and restart `cyber ` if you want to change this keypair. The new pair will be created automatically.
+A nodes keypair is stored in `node_key.json` and `priv_validator_key.json` at `$HOME/.cyber/config` folder. You can delete them and restart `deepchain ` if you want to change this keypair. The new pair will be created automatically.
 
 ## Generate keys
 
@@ -37,7 +37,7 @@ You'll need an account private and public key pair \(a.k.a. `sk, pk` respectivel
 To generate a new _secp256k1_ key:
 
 ```bash
-cyber keys add <account_name>
+deepchain keys add <account_name>
 ```
 
 Next, you will have to create a passphrase to protect the key on disk. The output of the above
@@ -46,39 +46,39 @@ place so that in case you forget the password, you could eventually regenerate t
 the seed phrase with the following command:
 
 ```bash
-cyber keys add <account_name> --recover
+deepchain keys add <account_name> --recover
 ```
 
-Also, you can import your Cosmos account to `cyber cli` using seed phrase:
+Also, you can import your Cosmos account to `deepchain cli` using seed phrase:
 
 ```bash
-cyber keys add <account_name> --recover 
+deepchain keys add <account_name> --recover 
 ```
 
-cyber provides compatibility of Cosmos with Cyber addresses.
+deepchain provides compatibility of Cosmos with deep addresses.
 
 You can check your application account details by account name:
 
 ```bash
-cyber keys show <account_name>
+deepchain keys show <account_name>
 ```
 
 You can see all of your available keys by typing:
 
 ```bash
-cyber keys list
+deepchain keys list
 ```
 
 View the validator pubkey for your node by typing:
 
 ```bash
-cyber tendermint show-validator
+deepchain tendermint show-validator
 ```
 
 Note that this is the Tendermint signing key, _not_ the operator key you will use in delegation transactions.
 
 
-**Important note**: Starting with v.38 cosmos-SDK uses os-native keyring to store all your keys. We've noticed that in certain cases this does not work well by default (for example if you don't have any GUI installed on your machine). If during the execution of the `cyber keys add` command you get this type of error:
+**Important note**: Starting with v.38 cosmos-SDK uses os-native keyring to store all your keys. We've noticed that in certain cases this does not work well by default (for example if you don't have any GUI installed on your machine). If during the execution of the `deep keys add` command you get this type of error:
 
 ```bash
 panic: No such interface 'org.freedesktop.DBus.Properties' on object at path /
@@ -104,13 +104,13 @@ Using the keyring backend as a **local file**:
 Execute:
 
 ```bash
-cyber keys add <key_name> keyring-backend file
+deepchain keys add <key_name> keyring-backend file
 ```
 
-This means that you've saved your keyring-backend to a local file. *Note*, in this case, all the keys in your keyring will be encrypted using the same password. If you would like to set up a unique password for each key, you should set a unique `--home` folder for each key. To do that, just use `--home=/<unique_path_to_key_folder>/` with setup keyring backend and at all interactions with keys when using cyber cli:
+This means that you've saved your keyring-backend to a local file. *Note*, in this case, all the keys in your keyring will be encrypted using the same password. If you would like to set up a unique password for each key, you should set a unique `--home` folder for each key. To do that, just use `--home=/<unique_path_to_key_folder>/` with setup keyring backend and at all interactions with keys when using deep cli:
 
 ```bash
-cyber config keyring-backend file --home=/<unique_path_to_key_folder>/
-cyber keys add <your_second_key_name> --home=/<unique_path_to_key_folder>/
-cyber keys list --home=/<unique_path_to_key_folder>/
+deepchain config keyring-backend file --home=/<unique_path_to_key_folder>/
+deepchain keys add <your_second_key_name> --home=/<unique_path_to_key_folder>/
+deep keys list --home=/<unique_path_to_key_folder>/
 ```
diff --git a/docs/multisig_guide.md b/docs/multisig_guide.md
index df5bf7fc..f048102c 100644
--- a/docs/multisig_guide.md
+++ b/docs/multisig_guide.md
@@ -1,9 +1,9 @@
 # A guide for creating a 2 of 3 multisig account and sending transactions
 
-To follow this guide you'll need `cyber` installed and connected to any cyber node (refer to our cli [guide](https://github.com/cybercongress/go-cyber/blob/main/docs/ultimate-commands-guide.md)).
+To follow this guide you'll need `deepchain` installed and connected to any cyber node (refer to our cli [guide](https://github.com/cybercongress/go-cyber/blob/main/docs/ultimate-commands-guide.md)).
 A reminder: this guide covers all types of transactions, not only send transactions. This guide is also relevant for Cosmos Hub Gaiacli users, except for the bandwidth params, in Cosmos we pay a fee using tokens.
 
-Do not forget about the `--chain-id` flag in `cyber`, and in the `Cosmos Hub` networks.
+Do not forget about the `--chain-id` flag in `deepchain`, and in the `Cosmos Hub` networks.
 You can always get the current `<chain-id>` in the master branch of the [repository](https://github.com/cybercongress/go-cyber).
 
 ## Creating a multisig
@@ -13,14 +13,14 @@ The multisig account creation and sending transactions are simple and clear but
 1. Import or create a thresholder accounts for multisig:
 
 ```bash
-cyber keys add test1
-cyber keys add test2
+deepchain keys add test1
+deepchain keys add test2
 ```
 
 2. Add pubkeys of remote thresholder accounts:
 
 ```bash
-cyber keys add test3 --pubkey=<thresholder_pub_key>
+deepchain keys add test3 --pubkey=<thresholder_pub_key>
 ```
 
 We now have 3 accounts for multisig account generating:
@@ -29,13 +29,13 @@ We now have 3 accounts for multisig account generating:
 All the created and imported accounts can be checked with:
 
 ```bash
-cyber keys list
+deepchain keys list
 ```
 
 3. Now, we can create and test the 2-of-3 multisig account, named for example: `multitest1` with keys `test1`,`test2` on a local machine and `test3` on a remote thresholder:
 
 ```bash
-cyber keys add multitest1 --multisig=test1,test2,test3 --multisig-threshold=2
+deepchain keys add multitest1 --multisig=test1,test2,test3 --multisig-threshold=2
 ```
 
 4. You should top up the balance of your multisig account. Make sure that you have enough bandwidth to execute transactions later.
@@ -45,7 +45,7 @@ cyber keys add multitest1 --multisig=test1,test2,test3 --multisig-threshold=2
 5. Create an unsigned transaction from the multisig account and store it in the `unsigned.json` file:
 
 ```bash
-cyber tx send <recipient_address> <amount>boot \
+deepchain tx send <recipient_address> <amount>boot \
 --from=<multisig_address> \
 --chain-id=<chain_id> \
 --generate-only > unsigned.json
@@ -54,7 +54,7 @@ cyber tx send <recipient_address> <amount>boot \
 6. Sign this transaction with the following command and then store the signed file in `sign1.json`:
 
 ```bash
-cyber tx sign unsigned.json --multisig=<multisig_address> \
+deepchain tx sign unsigned.json --multisig=<multisig_address> \
 --from=<your_account_name> \
 --output-document=sign1.json \
 --chain-id=<chain_id>
@@ -83,14 +83,14 @@ Your cli-home folder should content 3 `.json` files:
 10. Generate a multisig transaction with all signatures:
 
 ```bash
-cyber tx multisign unsigned.json multitest1 sign1.json sign2.json \
+deepchain tx multisign unsigned.json multitest1 sign1.json sign2.json \
 --chain-id=<chain_id> > signed.json
 ```
 
 11. Finally, we need to broadcast this transaction to the network:
 
 ```bash
-cyber tx broadcast signed.json --chain-id=<chain_id>
+deepchain tx broadcast signed.json --chain-id=<chain_id>
 ```
 
 If the multisig account has enough bandwidth, the transaction should be broadcasted to the network.
diff --git a/docs/run_validator.md b/docs/run_validator.md
index 909bb6ca..2a1b7384 100644
--- a/docs/run_validator.md
+++ b/docs/run_validator.md
@@ -1,5 +1,5 @@
 
-# Join cyber as a Validator
+# Join deepchain as a Validator
 
 ## Prepare your server
 
diff --git a/docs/ultimate-commands-guide.md b/docs/ultimate-commands-guide.md
index 1876125e..7996f526 100644
--- a/docs/ultimate-commands-guide.md
+++ b/docs/ultimate-commands-guide.md
@@ -1,34 +1,34 @@
-# Ultimate cyber CLI guide. Chain: bostrom
+# Ultimate deepchain CLI guide. Chain: deep
 
-## Install cyber client
+## Install deepchain client
 
-It is possible to interact with cyber even if you don't have your own node. All you need to do is install `cyber` client on your machine using the script below, paste it in the console (currently Linux supported):
+It is possible to interact with deepchain even if you don't have your own node. All you need to do is install `deepchain` client on your machine using the script below, paste it in the console (currently Linux supported):
 
 ```bash
 bash < <(curl -s https://raw.githubusercontent.com/cybercongress/go-cyber/main/scripts/install_cyber.sh)
 ```
 
-After installation, you will be able to use `cyber` to [import accounts](#account-management), create links or swap tokens.
+After installation, you will be able to use `deepchain` to [import accounts](#account-management), create links or swap tokens.
 
-In case you have your own node, which is already running inside Docker container, please add `docker exec -ti container-name` before every cyber command:
+In case you have your own node, which is already running inside Docker container, please add `docker exec -ti container-name` before every deepchain command:
 
 ```bash
-docker exec -ti bostrom cyber --help
+docker exec -ti deep deepchain --help
 ```
 
-First of all, I would like to encourage you to use the  `--help` feature if you want to have a better experience using cyber. This is a really easy way to find all the necessary commands with the appropriate options and flags.
+First of all, I would like to encourage you to use the  `--help` feature if you want to have a better experience using deepchain. This is a really easy way to find all the necessary commands with the appropriate options and flags.
 
 For example, you can enter:
 
 ```bash
-cyber --help
+deepchain --help
 ```
 
 You should see this message:
 
 ```bash
 Usage:
-  cyber [command]
+  deepchain [command]
 
 Available Commands:
   add-genesis-account Add a genesis account to genesis.json
@@ -55,15 +55,15 @@ Available Commands:
 The help feature works like a pyramid, you can use it with any command to find available options, subcommands and flags. For example, lets explore the `query` subcommands:
 
 ```bash
-cyber query --help
+deepchain query --help
 ```
 
 You can see the structure of the subcommand:
 
 ```bash
 Usage:
-  cyber query [flags]
-  cyber query [command]
+  deepchain query [flags]
+  deepchain query [command]
 ```
 
 And the available subcommands and flags:
@@ -113,22 +113,22 @@ Global Flags:
       --log_level string    The logging level (trace|debug|info|warn|error|fatal|panic) (default "info")
       --trace               print out full stack trace on errors
 
-Use "cyber query [command] --help" for more information about a command.
+Use "deepchain query [command] --help" for more information about a command.
 
 ```
 
 Let's explore the `bank` subcommand:
 
 ```bash
-cyber query bank --help
+deepchain query bank --help
 ```
 
 We can see all of the options available for these subcommands, names and account address:
 
 ```bash
 Usage:
-  cyber query bank [flags]
-  cyber query bank [command]
+  deepchain query bank [flags]
+  deepchain query bank [command]
 
 Available Commands:
   balances       Query for account balances by address
@@ -140,7 +140,7 @@ In most cases you will need just two extra flags:
 
 ```bash
 --from=<your_key_name> \
---chain-id=bostrom \
+--chain-id=deep \
 --node=<rpc_node_path>
 ```
 
@@ -192,7 +192,7 @@ That's it. This is a very useful tool for using cyber and troubleshooting.
 Return the set of all active and jailed validators:
 
 ```bash
-cyber query staking validators 
+deepchain query staking validators 
 ```
 
 ### Show chain status
@@ -200,13 +200,13 @@ cyber query staking validators
 Return general chain information:
 
 ```bash
- cyber status
+ deepchain status
 ```
 
 ### Distribution params
 
 ```bash
- cyber query distribution params 
+ deepchain query distribution params 
 ```
 
 ### Staking params
@@ -214,13 +214,13 @@ Return general chain information:
 Chain staking info:
 
 ```bash
- cyber query staking params 
+ deepchain query staking params 
 ```
 
 ### Staking pool
 
 ```bash
- cyber query staking pool 
+ deepchain query staking pool 
 ```
 
 ## Account management
@@ -228,13 +228,13 @@ Chain staking info:
 ### Import an account with a seed phrase and store it in the local keystore
 
 ```bash
- cyber keys add <your_key_name> --recover
+ deepchain keys add <your_key_name> --recover
 ```
 
 ### Create a new account
 
 ```bash
- cyber keys add <your_key_name>
+ deepchain keys add <your_key_name>
 ```
 
 ### Show account information
@@ -242,7 +242,7 @@ Chain staking info:
 Name, address and the public key of the current account
 
 ```bash
- cyber keys show <your_key_name>
+ deepchain keys show <your_key_name>
 ```
 
 ### Show account balance
@@ -250,26 +250,26 @@ Name, address and the public key of the current account
 Return account number and amount of tokens.
 
 ```bash
- cyber query bank balances <your_key_address>
+ deepchain query bank balances <your_key_address>
 ```
 
 ### List existing keys
 
-Return all the existing keys in cyber:
+Return all the existing keys in deepchain:
 
 ```bash
- cyber keys list
+ deepchain keys list
 ```
 
-### Delete account from cyber
+### Delete account from deepchain
 
 ```bash
- cyber keys delete <deleting_key_name>
+ deepchain keys delete <deleting_key_name>
 ```
 
 ### Keyring manipulation settings
 
-**Important note**: Starting with v.38, Cosmos-SDK uses os-native keyring to store all of your keys. We've noticed that in certain cases it does not work well by default (for example if you don't have any GUI installed on your machine). If during the execution `cyber keys add` command, you are getting this type of error:
+**Important note**: Starting with v.38, Cosmos-SDK uses os-native keyring to store all of your keys. We've noticed that in certain cases it does not work well by default (for example if you don't have any GUI installed on your machine). If during the execution `deepchain keys add` command, you are getting this type of error:
 
 ```bash
 panic: No such interface 'org.freedesktop.DBus.Properties' on object at path /
@@ -293,22 +293,22 @@ You will have to use another keyring backend to keep your keys.
 In that case you'll have to use file based keyring by adding the `--keyring-backend file` option to every key manipulation command:
 
 ```bash
-cyber keys add key_name --keyring-backend file
+deepchain keys add key_name --keyring-backend file
 ```
 
-That means that you've set your keyring-backend to a local file. *Note*, in this case, all the keys in your keyring will be encrypted using the same password. If you would like to set up a unique password for each key, you should set a unique `--home` folder for each key. To do that, just use `--home=/<unique_path_to_key_folder>/` with setup keyring backend and at all interactions with keys when using cyber:
+That means that you've set your keyring-backend to a local file. *Note*, in this case, all the keys in your keyring will be encrypted using the same password. If you would like to set up a unique password for each key, you should set a unique `--home` folder for each key. To do that, just use `--home=/<unique_path_to_key_folder>/` with setup keyring backend and at all interactions with keys when using deepchain:
 
 ```bash
-cyber keys add <your_second_key_name> --keyring-backend file --home=/<unique_path_to_key_folder>/
-cyber keys list --home=/<unique_path_to_key_folder>/
+deepchain keys add <your_second_key_name> --keyring-backend file --home=/<unique_path_to_key_folder>/
+deepchain keys list --home=/<unique_path_to_key_folder>/
 ```
 
 ### Send tokens
 
 ```bash
-cyber tx bank send [from_key_or_address] [to_address] [amount] \
+deepchain tx bank send [from_key_or_address] [to_address] [amount] \
 --from=<your_key_name> \
---chain-id=bostrom
+--chain-id=deep
 ```
 
 ### Linking content
@@ -316,15 +316,15 @@ cyber tx bank send [from_key_or_address] [to_address] [amount] \
 Only IPFS hashes are available to use as CIDs
 
 ```bash
-cyber tx graph cyberlink [cid-from] [cid-to] [flags] \
+deepchain tx graph cyberlink [cid-from] [cid-to] [flags] \
 --from=<your_key_name> \
---chain-id=bostrom
+--chain-id=deep
 ```
 
 Real command example:
 
 ```bash 
-cyber tx graph cyberlink QmWZYRj344JSLShtBnrMS4vw5DQ2zsGqrytYKMqcQgEneB QmfZwbahFLTcB3MTMT8TA8si5khhRmzm7zbHToo4WVK3zn --from fuckgoogle --chain-id bostrom --yes
+deepchain tx graph cyberlink QmWZYRj344JSLShtBnrMS4vw5DQ2zsGqrytYKMqcQgEneB QmfZwbahFLTcB3MTMT8TA8si5khhRmzm7zbHToo4WVK3zn --from fuckgoogle --chain-id deep --yes
 ```
 
 ## Validator commands
@@ -332,58 +332,58 @@ cyber tx graph cyberlink QmWZYRj344JSLShtBnrMS4vw5DQ2zsGqrytYKMqcQgEneB QmfZwbah
 ### Get all validators
 
 ```bash
- cyber query staking validators 
+ deepchain query staking validators 
 ```
 
 ### State of a current validator
 
 ```bash
-cyber query staking validator <operator_address>
+deepchain query staking validator <operator_address>
 ```
 
 ### Return all delegations to a validator
 
 ```bash
- cyber query staking delegations-to <operator_address>
+ deepchain query staking delegations-to <operator_address>
 ```
 
 ### Edit the commission in an existing validator account
 
 ```bash
- cyber tx staking edit-validator \
+ deepchain tx staking edit-validator \
   --from=<your_key_name> \
   --commission-rate=<new_comission_rate_percentage> \
-  --chain-id=bostrom
+  --chain-id=deep
 ```
 
 ### Withdraw the commission for any delegation
 
 ```bash
- cyber tx distribution withdraw-rewards <operator_address> --commission \
+ deepchain tx distribution withdraw-rewards <operator_address> --commission \
   --from=<your_key_name> \
-  --chain-id=bostrom
+  --chain-id=deep
 ```
 
 ### Edit the site and description for an existing validator account
 
 ```bash
- cyber tx staking edit-validator \
+ deepchain tx staking edit-validator \
   --from=<your_key_name> \
   --details="<description>" \
   --website=<your_website> \
-  --chain-id=bostrom
+  --chain-id=deep
 ```
 
 ### Unjail a validator previously jailed for downtime
 
 ```bash
- cyber tx slashing unjail --from=<your_key_name> --chain-id=bostrom
+ deepchain tx slashing unjail --from=<your_key_name> --chain-id=deep
 ```
 
 ### Get info about a redelegation process from a validator
 
 ```bash
- cyber query staking redelegations-from <operator_address>
+ deepchain query staking redelegations-from <operator_address>
 ```
 
 ## Delegator commands
@@ -391,57 +391,57 @@ cyber query staking validator <operator_address>
 ### Return distribution delegator rewards for a specified validator
 
 ```bash
- cyber query distribution rewards <delegator_address> <operator_address>
+ deepchain query distribution rewards <delegator_address> <operator_address>
 ```
 
 ### Return delegator shares for the specified validator
 
 ```bash
- cyber query staking delegation <delegator_address> <operator_address>
+ deepchain query staking delegation <delegator_address> <operator_address>
 ```
 
 ### Return all delegations made from a delegator
 
 ```bash
- cyber query staking delegations <delegator_address>
+ deepchain query staking delegations <delegator_address>
 ```
 
 ### Return all unbonding delegations from a validator
 
 ```bash
- cyber query staking unbonding-delegations-from <operator_address>
+ deepchain query staking unbonding-delegations-from <operator_address>
 ```
 
 ### Withdraw rewards for any delegation
 
 ```bash
- cyber tx distribution withdraw-rewards <operator_address> \
+ deepchain tx distribution withdraw-rewards <operator_address> \
   --from=<your_key_name> \
-  --chain-id=bostrom
+  --chain-id=deep
 ```
 
 ### Withdraw all delegation rewards
 
 ```bash
- cyber tx distribution withdraw-all-rewards \
+ deepchain tx distribution withdraw-all-rewards \
   --from=<your_key_name> \
-  --chain-id=bostrom
+  --chain-id=deep
 ```
 
 ### Change the default withdrawal address for rewards associated with an address
 
 ```bash
- cyber tx distribution set-withdraw-addr <your_new_address> \
+ deepchain tx distribution set-withdraw-addr <your_new_address> \
   --from=<your_key_name> \
-  --chain-id=bostrom
+  --chain-id=deep
 ```
 
 ### Delegate liquid tokens to a validator
 
 ```bash
- cyber tx staking delegate <operator_address> <amount_boot> \
+ deepchain tx staking delegate <operator_address> <amount_boot> \
   --from=<your_key_name> \
-  --chain-id=bostrom
+  --chain-id=deep
 ```
 
 ### Redelegate illiquid tokens from one validator to another in absolute BOOT value
@@ -449,17 +449,17 @@ cyber query staking validator <operator_address>
 > There is a 4-day unbonding period
 
 ```bash
- cyber tx staking redelegate <old_operator_address> <new_operator_address> <amount_boot> \
+ deepchain tx staking redelegate <old_operator_address> <new_operator_address> <amount_boot> \
  --from=<your_key_name> \
- --chain-id=bostrom
+ --chain-id=deep
 ```
 
 ### Redelegate illiquid tokens from one validator to another in percentages
 
 ```bash
- cyber tx staking redelegate <old_operator_address> <new_operator_address> <shares_percentage>
+ deepchain tx staking redelegate <old_operator_address> <new_operator_address> <shares_percentage>
   --from=<your_key_name> \
-  --chain-id=bostrom
+  --chain-id=deep
 ```
 
 ### Unbond shares from a validator in absolute BOOT value
@@ -467,9 +467,9 @@ cyber query staking validator <operator_address>
 > 8 days for unbonding
 
 ```bash
- cyber tx staking unbond <operator_address> <amount_boot>
+ deepchain tx staking unbond <operator_address> <amount_boot>
   --from=<your_key_name> \
-  --chain-id=bostrom
+  --chain-id=deep
 ```
 
 ### Unbond shares from a validator in percentages
@@ -477,33 +477,33 @@ cyber query staking validator <operator_address>
 > 8 days for unbonding
 
 ```bash
- cyber tx staking unbond <operator_address> <shares_percentage>
+ deepchain tx staking unbond <operator_address> <shares_percentage>
   --from=<your_key_name> \
-  --chain-id=bostrom
+  --chain-id=deep
 ```
 
 ### Get info about the unbonding delegation process to any validator
 
 ```bash
- cyber query staking unbonding-delegation <delegator_address> <operator_address>
+ deepchain query staking unbonding-delegation <delegator_address> <operator_address>
 ```
 
 ### Get info about the unbonding delegation process to all unbonded validators
 
 ```bash
- cyber query staking unbonding-delegation <delegator_address>
+ deepchain query staking unbonding-delegation <delegator_address>
 ```
 
 ### Get info about redelegation process from to current validator
 
 ```bash
- cyber query staking redelegation <delegator_address> <old_operator_address> <new_operator_address>
+ deepchain query staking redelegation <delegator_address> <old_operator_address> <new_operator_address>
 ```
 
 ### Get the info about all the redelegation processes by a delegator
 
 ```bash
- cyber query staking redelegations <delegator_address>
+ deepchain query staking redelegations <delegator_address>
 ```
 
 ## Governance and voting
@@ -511,49 +511,49 @@ cyber query staking validator <operator_address>
 ### Query specific proposal
 
 ```bash
-cyber q gov proposal <proposal_id> 
+deepchain q gov proposal <proposal_id> 
 ```
 
 ### Query all proposals
 
 ```bash
-cyber q gov proposals 
+deepchain q gov proposals 
 ```
 
 ### Query votes on proposal
 
 ```bash
-cyber q gov votes 
+deepchain q gov votes 
 ```
 
 ### Query parameters from governance module
 
 ```bash
-cyber q gov params
+deepchain q gov params
 ```
 
 ### Vote for specific proposal
 
 ```bash
-cyber tx gov vote <proposal_id> <vote_option:_yes_no_abstain> \
+deepchain tx gov vote <proposal_id> <vote_option:_yes_no_abstain> \
 --from=<your_key_name> \
---chain-id=bostrom
+--chain-id=deep
 ```
 
 ### Submit text proposal
 
 ```bash
-cyber tx gov submit-proposal --title="Test Proposal" --description="My awesome proposal" --type="Text" --deposit="10boot" \
+deepchain tx gov submit-proposal --title="Test Proposal" --description="My awesome proposal" --type="Text" --deposit="10boot" \
 --from=<your_key_name> \
---chain-id=bostrom
+--chain-id=deep
 ```
 
 ### Submit community spend proposal
 
 ```bash
-cyber tx gov submit-proposal community-pool-spend <path/to/proposal.json> \
+deepchain tx gov submit-proposal community-pool-spend <path/to/proposal.json> \
 --from=<key_or_address> \
---chain-id=bostrom
+--chain-id=deep
 ```
 
 Where `proposal.json` is a file, structured in following way:
@@ -581,9 +581,9 @@ Where `proposal.json` is a file, structured in following way:
 ### Submit chain parameters change proposal
 
 ```bash
-cyber tx gov submit-proposal param-change <path/to/proposal.json> \
+deepchain tx gov submit-proposal param-change <path/to/proposal.json> \
 --from=<key_or_address> \
---chain-id=bostrom
+--chain-id=deep
 ```
 
 Where `proposal.json` is a file, structured in following way:
@@ -662,14 +662,14 @@ Few examples of real param-change proposals:
 
 ## Liquidity and pools 
 
-Cyber has Gravity-DEX module implemented, so it is possible to create pools, swap tokens and add\remove liquidity to exisitng pools: 
+deepchain has Gravity-DEX module implemented, so it is possible to create pools, swap tokens and add\remove liquidity to exisitng pools: 
 
 ```bash
 Liquidity transaction subcommands
 
 Usage:
-  cyber tx liquidity [flags]
-  cyber tx liquidity [command]
+  deepchain tx liquidity [flags]
+  deepchain tx liquidity [command]
 
 Available Commands:
   create-pool Create liquidity pool and deposit coins
@@ -690,9 +690,9 @@ New liquidity pools can be created only for coin combinations that do not alread
 Example:
 
 ```bash
-cyber tx liquidity create-pool 1 2000000milliampere,200000000000boot \
+deepchain tx liquidity create-pool 1 2000000milliampere,200000000000boot \
 --from=mykey \
---chain-id=bostrom  \
+--chain-id=deep  \
 --yes
 ```
 
@@ -706,9 +706,9 @@ All requests in a batch are treated equally and executed at the same swap price.
 Example:
 
 ```bash
-cyber tx liquidity deposit 1 100000000milliampere,50000000000boot \
+deepchain tx liquidity deposit 1 100000000milliampere,50000000000boot \
 --from=mykey \
---chain-id=bostrom
+--chain-id=deep
 ```
 
 This example request deposits 100000000milliampere and 50000000000boot to pool-id 1.
@@ -731,9 +731,9 @@ Swap orders are executed only when the execution swap price is equal to or great
 Example:
 
 ```bash
-cyber tx liquidity swap 1 1 50000000boot hydrogen 0.019 0.003 \
+deepchain tx liquidity swap 1 1 50000000boot hydrogen 0.019 0.003 \
 --from=mykey \
---chain-id=bostrom
+--chain-id=deep
 ```
 
 For this example, imagine that an existing liquidity pool has with 1000000000hydrogen and 50000000000boot.
@@ -756,7 +756,7 @@ The only supported swap-type is 1. For the detailed swap algorithm, see https://
 Usage:
 
 ```bash
-  cyber tx liquidity swap [pool-id] [swap-type] [offer-coin] [demand-coin-denom] [order-price] [swap-fee-rate] [flags]
+  deepchain tx liquidity swap [pool-id] [swap-type] [offer-coin] [demand-coin-denom] [order-price] [swap-fee-rate] [flags]
 ```
 
 ### Withdraw tokens from liquidity pool
@@ -769,9 +769,9 @@ All requests in a batch are treated equally and executed at the same swap price.
 Example:
 
 ```bash
- cyber tx liquidity withdraw 1 10000pool96EF6EA6E5AC828ED87E8D07E7AE2A8180570ADD212117B2DA6F0B75D17A6295 \
+ deepchain tx liquidity withdraw 1 10000pool96EF6EA6E5AC828ED87E8D07E7AE2A8180570ADD212117B2DA6F0B75D17A6295 \
  --from=mykey \
- --chain-id=bostrom
+ --chain-id=deep
 ```
 
 This example request withdraws 10000 pool coin from the specified liquidity pool.
@@ -783,9 +783,9 @@ The appropriate pool coin must be requested from the specified pool.
 Usage:
 
 ```bash
-  cyber tx liquidity withdraw [pool-id] [pool-coin] [flags]\
+  deepchain tx liquidity withdraw [pool-id] [pool-coin] [flags]\
   --from=<key_or_address> \
-  --chain-id=bostrom
+  --chain-id=deep
 ```
 
 ### Query existing pools
@@ -793,20 +793,20 @@ Usage:
 Query details of a liquidity pool
 
 ```bash
-cyber query liquidity pool 1
+deepchain query liquidity pool 1
 ```
 
 Example (with pool coin denom):
 
 ```bash
-cyber query liquidity pool --pool-coin-denom=[denom]
+deepchain query liquidity pool --pool-coin-denom=[denom]
 ```
 
 Query details about all liquidity pools on a network.
 Example:
 
 ```bash
-cyber query liquidity pools
+deepchain query liquidity pools
 ```
 
 ##