fix: Update node docs [DEV-5610]

architecture/adr-list/adr-005-genesis-parameters.md

@@ -22,7 +22,7 @@ Genesis consists of Tendermint consensus engine parameters and Cosmos app-specif
 
 ## Tendermint consensus parameters
 
-Tendermint requires [genesis parameters](https://docs.cometbft.com/v0.34/core/using-cometbft#genesis) to be defined for basic consensus conditions on any Cosmos network.
+Tendermint requires [genesis parameters](https://docs.cometbft.com/v0.38/core/using-cometbft#genesis) to be defined for basic consensus conditions on any Cosmos network.
 
 ### Block parameters
 
@@ -185,4 +185,4 @@ The parameters above were agreed separate the cheqd mainnet and testnet paramete
 ## References
 
 * [List of Cosmos modules](https://docs.cosmos.network/main/modules)
-* [Tendermint genesis parameters](https://docs.cometbft.com/v0.34/core/using-cometbft#genesis)
+* [Tendermint genesis parameters](https://docs.cometbft.com/v0.38/core/using-cometbft#genesis)

docs/build-and-networks/docker-build.md

@@ -13,7 +13,7 @@ These advanced instructions are intended for developers who want to build their
 1. Docker Engine v20.10.x and above (use `docker -v` to check)
 2. Docker Compose v2.3.x and above (use `docker compose version` to check)
 
-Our Docker Compose files [use Compose v2 syntax](https://docs.docker.com/compose/compose-v2/). The primary difference in usage is that Docker Compose's new implementation uses `docker compose` commands (with a space), rather than the legacy `docker-compose` although they are supposed to be drop-in replacements for each other.
+Our Docker Compose files [use Compose v2 syntax](https://docs.docker.com/reference/compose-file/). The primary difference in usage is that Docker Compose's new implementation uses `docker compose` commands (with a space), rather than the legacy `docker-compose` although they are supposed to be drop-in replacements for each other.
 
 ### Special guidance for Mac OS running on Apple silicon (M-series chips)
 

docs/setup-and-configure/docker.md

@@ -15,7 +15,7 @@ Docker-based installations are useful when running non-validator (observer) node
 1. Docker Engine v20.10.x and above (use `docker -v` to check)
 2. Docker Compose v2.3.x and above (use `docker compose version` to check)
 
-Our Docker Compose files [use Compose v2 syntax](https://docs.docker.com/compose/compose-v2/). The primary difference in usage is that Docker Compose's new implementation uses `docker compose` commands (with a space), rather than the legacy `docker-compose` although they are supposed to be drop-in replacements for each other.
+Our Docker Compose files [use Compose v2 syntax](https://docs.docker.com/reference/compose-file/). The primary difference in usage is that Docker Compose's new implementation uses `docker compose` commands (with a space), rather than the legacy `docker-compose` although they are supposed to be drop-in replacements for each other.
 
 ### Special guidance for Mac OS running on Apple silicon (M-series chips)
 

docs/setup-and-configure/requirements.md

@@ -12,7 +12,7 @@ For most nodes, the RAM/vCPU requirements are relatively static and do not chang
 
 It is recommended to **mount disk storage for blockchain data as an expandable volume/partition separate from your root partition**. This allows you mount the node data/configuration path on `/home` (for example) and increase the storage if necessary *independent* of the root `/` partition since hosting providers typically force an increase in CPU/RAM specifications to grow the root partition.
 
-Extended information on [recommended hardware requirements is available in Tendermint documentation](https://docs.cometbft.com/main/explanation/core/running-in-production#hardware). The figures below have been updated from the default Tendermint recommendations to account for current cheqd network chain size, real-world usage accounting for requests nodes need to handle, etc.
+Extended information on [recommended hardware requirements is available in Tendermint documentation](https://docs.cometbft.com/v0.38/core/running-in-production#hardware). The figures below have been updated from the default Tendermint recommendations to account for current cheqd network chain size, real-world usage accounting for requests nodes need to handle, etc.
 
 ### Recommended hardware specifications
 
@@ -60,13 +60,13 @@ The P2P port is used for peer-to-peer communication between nodes. This port is
 * Outbound TCP connections must be allowed on *all* ports to *any* IP address range.
 * The default P2P port can be changed in `$HOME/.cheqdnode/config/config.toml`.
 
-Further details on [how P2P settings work is defined in Tendermint documentation](https://docs.cometbft.com/main/explanation/core/running-in-production#p2p).
+Further details on [how P2P settings work is defined in Tendermint documentation](https://docs.cometbft.com/v0.38/core/running-in-production#p2p).
 
 ### RPC port
 
 The RPC port is intended to be used by client applications as well as the cheqd-node CLI. Your RPC port **must** be active and available on localhost to be able to use the CLI. It is up to a node operator whether they want to expose the RPC port to public internet.
 
-The [RPC endpoints for a node](https://docs.cometbft.com/main/explanation/core/rpc) provide REST, JSONRPC over HTTP, and JSONRPC over WebSockets. These API endpoints can provide useful information for node operators, such as healthchecks, network information, validator information etc.
+The [RPC endpoints for a node](https://docs.cometbft.com/v0.38/core/rpc) provide REST, JSONRPC over HTTP, and JSONRPC over WebSockets. These API endpoints can provide useful information for node operators, such as healthchecks, network information, validator information etc.
 
 * By default, the RPC port is set to `26657`
 * Inbound and outbound TCP connections should be allowed from destinations desired by the node operator. The default is to allow this from any IPv4 address range.
@@ -82,7 +82,7 @@ In addition to the P2P/RPC ports above, you need to allow the following ports in
 
 ### Sentry nodes (optional)
 
-Tendermint allows more complex setups in production, where the ingress/egress to a validator node is [proxied behind a "sentry" node](https://docs.cometbft.com/main/explanation/core/validators).
+Tendermint allows more complex setups in production, where the ingress/egress to a validator node is [proxied behind a "sentry" node](https://docs.cometbft.com/v0.38/core/validators).
 
 While this setup is not compulsory, node operators with higher stakes or a need to have more robust network security may consider setting up a sentry-validator node architecture.
 
@@ -94,5 +94,5 @@ If you're not running a validator node, or if you want more advanced control on
 
 ## Further information
 
-* Tendermint documentation has [best practices for running a Cosmos node in production](https://docs.cometbft.com/main/explanation/core/running-in-production).
+* Tendermint documentation has [best practices for running a Cosmos node in production](https://docs.cometbft.com/v0.38/core/running-in-production).
 * [Сosmovisor could be used for automatic upgrades](https://docs.cosmos.network/main/tooling/cosmovisor); however in our testing so far this method has not been reliable and is therefore currently not recommended.

docs/setup-and-configure/set-up-state-sync.md

@@ -36,7 +36,7 @@ After that, you need to provide **RPC endpoints** that expose and serve state sy
 After that, you need to add the `trust_height` - this is usually $CURRENT_BLOCK_HEIGHT - 2000 blocks (which is the interval at we generate new snapshots on our RPC nodes).
 Finally, you need to add the block ID hash, as `trust_hash` parameter. This can be fetched via RPC, like this - `https://rpc.cheqd.net/block?height=20748000`. You will find block hash under `.result.block_id.hash`.
 
-Reference: [CometBFT State Sync docs](https://docs.cometbft.com/v0.34/core/state-sync)
+Reference: [CometBFT State Sync docs](https://docs.cometbft.com/v0.38/core/state-sync)
 
 You can also use this simple bash script to update your node configuration:
 

docs/validator-guide/README.md

@@ -65,13 +65,25 @@ P.S. in case of using Ledger Nano device it would be helpful to use [this instru
 
    You can decide how many tokens you would like to stake from your account balance. For instance, you may want to leave a portion of the balance for paying transaction fees (now and in the future).
 
-   To promote to validation, submit a `create-validator` transaction to the network:
+   To promote to validation, first prepare a json file with all the validator information named `validator.json`:
 
-   ```bash
-   cheqd-noded tx staking create-validator --amount <amount-staking> --from <key-name> --chain-id <chain-id> --min-self-delegation <min-self-delegation> --gas auto --gas-adjustment <multiplication-factor> --gas-prices <price-gas> --pubkey <validator-pubkey> --commission-max-change-rate <commission-max-change-rate> --commission-max-rate <commission-max-rate> --commission-rate <commission-rate>
-   ```
+```bash
+{
+	"pubkey": {"@type":"/cosmos.crypto.ed25519.PubKey","key":"4anVUO8WhmRMqG1t4z6VxqmqZL3V7q6HqucjwZePiUw="},
+	"amount": "1000000000ncheq",
+	"moniker": "mainnet-validator-name",
+	"identity": "optional identity signature (ex. UPort or Keybase)",
+	"website": "validator's (optional) website",
+	"security": "validator's (optional) security contact email",
+	"details": "validator's (optional) details",
+	"commission-rate": "0.1",
+	"commission-max-rate": "0.2",
+	"commission-max-change-rate": "0.01",
+	"min-self-delegation": "1"
+}
+```
 
-   Parameters required in the transaction above are:
+   Parameters required in the json file above are:
 
    * **`amount`**: Amount of tokens to stake. You should stake at least 1 CHEQ (= 1,000,000,000ncheq) to successfully complete a staking transaction.
    * **`from`**: Key alias of the node operator account that makes the initial stake
@@ -80,21 +92,17 @@ P.S. in case of using Ledger Nano device it would be helpful to use [this instru
    * **`commission-rate`**: Validator's commission rate. The minimum is set to `0.05`.
    * **`commission-max-rate`**: Validator's maximum commission rate, expressed as a number with up to two decimal points. The value for this cannot be changed later.
    * **`commission-max-change-rate`**: Maximum rate of change of a validator's commission rate per day, expressed as a number with up to two decimal points. The value for this cannot be changed later.
-   * **`chain-id`**: Unique identifier for the chain.
-     * For cheqd's current mainnet, this is `cheqd-mainnet-1`
-     * For cheqd's current testnet, this is `cheqd-testnet-6`
-   * **`gas`**: Maximum gas to use for *this specific* transaction. Using `auto` uses Cosmos's auto-calculation mechanism, but can also be specified manually as an integer value.
-   * **gas-adjustment** (optional): If you're using `auto` gas calculation, this parameter multiplies the auto-calculated amount by the specified factor, e.g., `1.4`. This is recommended so that it leaves enough margin of error to add a bit more gas to the transaction and ensure it successfully goes through.
-   * **`gas-prices`**: Maximum gas price set by the validator. Default value is `5000ncheq`.
 
-Please note the parameters below are just an “**example**”.
+Please note the parameters mentioned are just an “**example**”.
 
 When setting parameters such as the commission rate, a good benchmark is to consider the [commission rates set by validators on existing networks such as Cosmos ATOM chain](https://www.mintscan.io/cosmos/validators).
 
 You will see the commission they set, the max rate they set, and the rate of change. Please use this as a guide when thinking of your own commission configurations. This is important to get right, because the `commission-max-rate` and `commission-max-change-rate` cannot be changed after they are initially set.
 
+Submit the `create-validator` transaction to the chain:
+
    ```bash
-   cheqd-noded tx staking create-validator --amount 1000000000ncheq --from key-alias-name --moniker mainnet-validator-name --chain-id cheqd-mainnet-1 --min-self-delegation="1" --gas auto --gas-adjustment 1.4 --gas-prices="5000ncheq" --pubkey '{"@type":"/cosmos.crypto.ed25519.PubKey","key":"4anVUO8WhmRMqG1t4z6VxqmqZL3V7q6HqucjwZePiUw="}' --commission-max-change-rate 0.01 --commission-max-rate 0.2 --commission-rate 0.05 --node https://rpc.cheqd.net:443
+cheqd-noded tx staking create-validator path/to/validator.json --from key-alias-name --gas auto --gas-adjustment 1.4 --gas-prices="5000ncheq" --node https://rpc.cheqd.net:443
    ```
 
 1. **Check that your validator node is bonded**

docs/validator-guide/cpu-memory.md

@@ -4,7 +4,7 @@
 
 Blockchain applications (especially when running validator nodes) are a-typical from "traditional" web server applications because their performance characteristics tend to be different in the way specified below:
 
-1. **Tend to be more disk I/O heavy**: Traditional web apps will typically offload data storage to persistent stores such as a database. In case of a blockchain/validator node, the database *is* on the machine itself, rather than offloaded to separate machine with a standalone engine. Many blockchains use [LevelDB](https://github.com/google/leveldb) for their local data copies. (In Cosmos SDK apps, such as cheqd, this is the [Golang implementation of LevelDB](https://github.com/syndtr/goleveldb), but can also be [C-implementation of LevelDB](https://docs.cometbft.com/main/tutorials/install), [RocksDB](https://rocksdb.org/), etc.) The net result is the same as if you were trying to run a database engine on a machine: the system needs to have fast read/write performance characteristics.
+1. **Tend to be more disk I/O heavy**: Traditional web apps will typically offload data storage to persistent stores such as a database. In case of a blockchain/validator node, the database *is* on the machine itself, rather than offloaded to separate machine with a standalone engine. Many blockchains use [LevelDB](https://github.com/google/leveldb) for their local data copies. (In Cosmos SDK apps, such as cheqd, this is the [Golang implementation of LevelDB](https://github.com/syndtr/goleveldb), but can also be [C-implementation of LevelDB](https://docs.cometbft.com/v0.38/guides/install#compile-with-cleveldb-support), [RocksDB](https://rocksdb.org/), etc.) The net result is the same as if you were trying to run a database engine on a machine: the system needs to have fast read/write performance characteristics.
 2. **Validator nodes cannot *easily* be auto-scaled**: Many traditional applications can be *horizontally* (i.e., add more machines) or *vertically* (i.e., make current machine beefier) scaled. While this is *possible* for validator nodes, it must be done with extreme caution to ensure there aren't two instances of the same validator active simultaneously. This can be perceived by network consensus as a sign of compromised validator keys and lead to the [node being jailed for double-signing blocks](unjail.md). These concerns are less relevant for non-validating nodes, since they have a greater tolerance for missed blocks and *can* be scaled horizontally/vertically.
 3. **Docker/Kubernetes setups are not recommended for validators** (unless you *really* know what you're doing): Primarily due to the double-signing risk, it's (../setup-and-configure/docker.md) unless you have a strong DevOps practice. The other reason is related to the first point, i.e., a Docker setup adds an abstraction layer between the actual underlying file-storage vs the Docker volume engine. Depending on the Docker (or similar abstraction) storage drivers used, you may need to [tune the storage/volume engine options](https://docs.docker.com/storage/storagedriver/select-storage-driver/) for optimal performance.
 
@@ -54,7 +54,7 @@ If you don't have a monitoring application installed, you could use the built-in
 
 Unfortunately, this only provides the **real-time** usage, rather than historical usage over time. Historical usage typically requires an external application, which many cloud providers provide, or through 3rd party monitoring tools such as [Datadog](https://www.datadoghq.com/), etc.
 
-[Tendermint / Cosmos SDK also provides a Prometheus metrics interface](https://docs.cometbft.com/v0.34/core/metrics), in case you already have a Prometheus instance you can use or comfortable with using the software. This can allow alerting based on actual metrics emitted by the node, rather than just top-level system metrics which are a blunt instrument / don't go into detail.
+[Tendermint / Cosmos SDK also provides a Prometheus metrics interface](https://docs.cometbft.com/v0.38/core/metrics), in case you already have a Prometheus instance you can use or comfortable with using the software. This can allow alerting based on actual metrics emitted by the node, rather than just top-level system metrics which are a blunt instrument / don't go into detail.
 
 ## Troubleshooting system clock synchronisation issues
 

docs/validator-guide/faq.md

@@ -108,7 +108,7 @@ We have also [built a tool](https://github.com/cheqd/validator-status) internall
 
 Please join the channel 'mainnet-alerts' on the cheqd community slack.
 
-In addition to that, [Cosmos/Tendermint also provide a Prometheus metrics interface](https://docs.cometbft.com/v0.34/core/metrics) (for those who already use it for monitoring/want to set one up) that has metrics for monitoring node status (and a lot more).
+In addition to that, [Cosmos/Tendermint also provide a Prometheus metrics interface](https://docs.cometbft.com/v0.38/core/metrics) (for those who already use it for monitoring/want to set one up) that has metrics for monitoring node status (and a lot more).
 
 ## **Are there any other ways to optimise?**