Restore / replace dead links

Eengineer1 · Eengineer1 · commit 751f78880973 · 2025-04-07T18:55:40.000+03:00
diff --git a/architecture/adr-list/adr-005-genesis-parameters.md b/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.tendermint.com/main/tendermint-core/using-tendermint.html#genesis) to be defined for basic consensus conditions on any Cosmos network.
+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.
 
 ### 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.tendermint.com/main/tendermint-core/using-tendermint.html#genesis)
+* [Tendermint genesis parameters](https://docs.cometbft.com/v0.34/core/using-cometbft#genesis)
diff --git a/docs/setup-and-configure/requirements.md b/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.tendermint.com/main/tendermint-core/running-in-production.html#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/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.
 
 ### Recommended hardware specifications
 
@@ -53,13 +53,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.tendermint.com/main/tendermint-core/running-in-production.html#p2p).
+Further details on [how P2P settings work is defined in Tendermint documentation](https://docs.cometbft.com/main/explanation/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.tendermint.com/main/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/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.
 
 * 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.
@@ -75,7 +75,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.tendermint.com/main/tendermint-core/validators.html).
+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).
 
 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.
 
@@ -87,5 +87,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.tendermint.com/main/tendermint-core/running-in-production.html).
+* Tendermint documentation has [best practices for running a Cosmos node in production](https://docs.cometbft.com/main/explanation/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.
diff --git a/docs/validator-guide/cpu-memory.md b/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.tendermint.com/v0.34/introduction/install.html), [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/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.
 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.tendermint.com/v0.34/tendermint-core/metrics.html), 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.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.
 
 ## Troubleshooting system clock synchronisation issues
 
diff --git a/docs/validator-guide/faq.md b/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.tendermint.com/v0.34/tendermint-core/metrics.html) (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.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).
 
 ## **Are there any other ways to optimise?**
 
diff --git a/docs/validator-guide/pruning.md b/docs/validator-guide/pruning.md
@@ -178,7 +178,6 @@ Instead of syncing a full node from scratch, validators can leverage pruned snap
    * Website: [https://nodestake.org/cheqd](https://nodestake.org/cheqd)
    * Instructions: Navigate to the **Snapshot** tab for detailed steps on downloading and using their snapshots.
 2. **Nysa Network**
-   * Website: [https://snapshots.nysa.network/#cheqd-mainnet-1/](https://snapshots.nysa.network/#cheqd-mainnet-1/)
    * Snapshot details and setup instructions are provided on the site.
 3. **Lavender.Five Nodes**
    * Website: [https://services.lavenderfive.com/mainnet/cheqd/snapshot](https://services.lavenderfive.com/mainnet/cheqd/snapshot)
