diff --git a/README.md b/README.md
index d5096075318..5189a137870 100644
--- a/README.md
+++ b/README.md
@@ -11,117 +11,47 @@ developed.](https://img.shields.io/badge/repo%20status-Active-green.svg)](https:
[](https://sonarcloud.io/summary/new_code?id=cosmos_gaia)
[](https://sonarcloud.io/summary/new_code?id=cosmos_gaia)
[](https://sonarcloud.io/summary/new_code?id=cosmos_gaia)
-[](https://discord.gg/cosmosnetwork)
-[](https://twitter.com/cosmoshub)
+[](https://x.com/cosmoshub)
+[](https://discord.gg/interchain)
+[](https://forum.cosmos.network)
-The Cosmos Hub is the first of an exploding number of interconnected blockchains that comprise theΒ Cosmos Network.
+The Cosmos Hub is the first of an exploding number of interconnected blockchains that comprise theΒ [Cosmos Network](https://cosmos.network).
-
-
-## π€ β Why should you be interested in the Cosmos Hub
-
-___
+## π€ Why should you be interested in the Cosmos Hub
The Cosmos Hub is built using the [Cosmos SDK](https://github.com/cosmos/cosmos-sdk) and compiled to a binary called `gaiad` (Gaia Daemon). The Cosmos Hub and other fully sovereign Cosmos SDK blockchains interact with one another using a protocol called [IBC](https://github.com/cosmos/ibc) that enables Inter-Blockchain Communication. In order to understand what the Cosmos Hub is you can read this [introductory explanation](https://hub.cosmos.network).
-
-
-## β‘ β Documentation & Introduction
-
-___
-
-Cosmos Hub is a blockchain network that operates on Proof-of-Stake consensus. You can find an introduction to the Cosmos Hub and how to use the `gaiad` binary as a delegator, validator or node operator as well as how governance on the Cosmos Hub works in the [documentation](https://hub.cosmos.network).
-
-Alternatively, whether you're new to blockchain technology or interested in getting involved, the Cosmos Network [Course](https://tutorials.cosmos.network/academy/0-welcome/) will guide you through everything. The course walks you through the basics of blockchain technology, to staking, setting up your own node, and beyond.
-
-
-
-## π€Β β Node Operators
-
-___
-If you're interested in running a node on the current Cosmos Hub, check out the docs to [Join the Cosmos Hub Mainnet](https://github.com/cosmos/gaia/blob/main/docs/docs/hub-tutorials/join-mainnet.md).
-
-
-
-## π£οΈΒ β Validators
-
-___
-
-If you want to participate and help secure Cosmos Hub, check out becoming a validator. Information on what a validator is and how to participate as one can be found at the [Validator FAQ](https://hub.cosmos.network/validators/validator-faq.html#). If you're running a validator node on the Cosmos Hub, reach out to a Janitor on the [Cosmos Developers Discord](https://discord.gg/cosmosnetwork) to join the `#cosmos-hub-validators-verified` channel.
-
-
-
-## π₯Β β Delegators
-
-___
-
-If you still want to participate on the Cosmos Hub, check out becoming a delegator. Information on what a delegator is and how to participate as one can be found at the [Delegator FAQ](https://hub.cosmos.network/delegators/delegator-faq.html).
-
-
-
-## π₯ β Testnet
-
-___
-
-To participate in or utilize the current Cosmos Hub testnet, take a look at the [cosmos/testnets](https://github.com/cosmos/testnets) repository. This testnet is for the Theta Upgrade expected in Q1 2022. For future upgrades of the Cosmos Hub take a look at the [roadmap](https://github.com/cosmos/gaia/blob/main/docs/docs/roadmap/cosmos-hub-roadmap-2.0.md).
-
-
-
-## πΒ β Roadmap
-
-___
-
-For an overview of upcoming changes to the Cosmos Hub take a look at the [Roadmap](https://github.com/cosmos/gaia/blob/main/docs/docs/roadmap/README.md).
-
-
-
-## ποΈ β Archives & Genesis
-
-___
-
-With each version of the Cosmos Hub, the chain is restarted from a new Genesis state.
-Mainnet is currently running as `cosmoshub-4`. Archives of the state of `cosmoshub-1`, `cosmoshub-2`, and `cosmoshub-3` are available [here](./docs/resources/archives.md).
-
-If you are looking for historical genesis files and other data [`cosmos/mainnet`](http://github.com/cosmos/mainnet) is an excellent resource. Snapshots are also available at [cosmos.quicksync.io](https://cosmos.quicksync.io).
-
-
-
-## π€ β How to contribute
-
-___
+## Documentation
-Check out [contributing.md](CONTRIBUTING.md) for our guidelines & policies for how we develop the Cosmos Hub. Thank you to all those who have contributed!
+For the most up to date documentation please visit [hub.cosmos.network](https://hub.cosmos.network).
-
+For an overview of the Interchain Stack (the Cosmos SDK, IBC, etc.), as well as examples and exercises to help developers get a quick start, please visit [tutorials.cosmos.network](https://tutorials.cosmos.network).
-## π¬ β Talk to us
+### Additional resources
-___
+**For node operators:** If you're interested in running a node on the current Cosmos Hub, check out the docs to [Join the Cosmos Hub Mainnet](https://hub.cosmos.network/main/hub-tutorials/join-mainnet).
-We have active, helpful communities on Twitter, Discord, and Telegram.
+**For validators:** If you want to participate and help secure the Cosmos Hub and its [consumer chains](https://hub.cosmos.network/main/interchain-security), consider becoming a validator. Information on what a validator is and how to participate as one can be found at the [Validator FAQ](https://hub.cosmos.network/main/validators/validator-faq). If you're running a validator node on the Cosmos Hub, reach out to a Janitor on the [Cosmos Developers Discord](https://discord.gg/interchain) to join the `#cosmos-hub-validators-verified` channel.
-| | |
-| -- | -- |
-| Cosmos Developers Discord | 
|
-| Cosmos Twitter | 
|
-| Cosmos Gov Twitter | 
|
-| Cosmos Telegram | 
|
+**For delegators:** If you want to secure the Cosmos Hub without running a validator, you can consider becoming a delegator. Information on what a delegator is and how to participate as one can be found at the [Delegator FAQ](https://hub.cosmos.network/main/delegators/delegator-faq).
-For updates on the Cosmos Hub team's activities follow us on the [Cosmos Hub Twitter](https://twitter.com/cosmoshub) account.
+## Testnet
-
+To participate in or utilize the current Cosmos Hub testnet, take a look at the [cosmos/testnets](https://github.com/cosmos/testnets) repository.
-## π β Supporters
+## Archives & Genesis
-___
+In the Cosmos Network, chain IDs have a revision number that is incremented on a hard-fork, i.e., when the chain restarts from a new genesis state.
+Mainnet is currently running as `cosmoshub-4`.
+If you are looking for historical genesis files and other data [`cosmos/mainnet`](http://github.com/cosmos/mainnet) is an excellent resource.
+Snapshots are also available at [cosmos.quicksync.io](https://quicksync.io/networks/cosmos.html).
-[](https://github.com/cosmos/gaia/stargazers)
-[](https://github.com/cosmos/gaia/network/members)
+## Contributing
-
+Check out [CONTRIBUTING.md](CONTRIBUTING.md) for our guidelines & policies for how we develop the Cosmos Hub. Thank you to all those who have contributed!
-
+## Talk to us
-
+Follow the Cosmos Hub team's activities on the [Cosmos Hub Twitter](https://x.com/cosmoshub) account.
-
+Join the conversation on the [Cosmos Hub Forum](https://forum.cosmos.network) and on [Discord](https://discord.gg/interchain).
diff --git a/docs/docs/delegators/delegator-guide-cli.md b/docs/docs/delegators/delegator-guide-cli.md
index 3525dbc2fde..b832d8e2d23 100644
--- a/docs/docs/delegators/delegator-guide-cli.md
+++ b/docs/docs/delegators/delegator-guide-cli.md
@@ -7,7 +7,7 @@ This document contains all the necessary information for delegators to interact
It also contains instructions on how to manage accounts, restore accounts from the fundraiser and use a ledger nano device.
-:::warning
+:::tip
**Very Important**: Please assure that you follow the steps described hereinafter
carefully, as negligence in this significant process could lead to an indefinite
loss of your Atoms. Therefore, read through the following instructions in their
@@ -32,10 +32,15 @@ Please exercise extreme caution!
## Table of Contents
+- [Table of Contents](#table-of-contents)
- [Installing `gaiad`](#installing-gaiad)
- [Cosmos Accounts](#cosmos-accounts)
- [Restoring an Account from the Fundraiser](#restoring-an-account-from-the-fundraiser)
+ - [On a Ledger Device](#on-a-ledger-device)
+ - [On a Computer](#on-a-computer)
- [Creating an Account](#creating-an-account)
+ - [Using a Ledger Device](#using-a-ledger-device)
+ - [Using a Computer](#using-a-computer)
- [Accessing the Cosmos Hub Network](#accessing-the-cosmos-hub-network)
- [Running Your Own Full-Node](#running-your-own-full-node)
- [Connecting to a Remote Full-Node](#connecting-to-a-remote-full-node)
@@ -43,9 +48,12 @@ Please exercise extreme caution!
- [Querying the State](#querying-the-state)
- [Sending Transactions](#sending-transactions)
- [A Note on Gas and Fees](#a-note-on-gas-and-fees)
+ - [Sending Tokens](#sending-tokens)
- [Bonding Atoms and Withdrawing Rewards](#bonding-atoms-and-withdrawing-rewards)
- - [Participating in Governance](#participating-in-governance)
- - [Signing Transactions from an Offline Computer](#signing-transactions-from-an-offline-computer)
+- [Participating in Governance](#participating-in-governance)
+ - [Primer on Governance](#primer-on-governance)
+ - [In Practice](#in-practice)
+ - [Signing Transactions From an Offline Computer](#signing-transactions-from-an-offline-computer)
## Installing `gaiad`
diff --git a/docs/docs/governance/README.md b/docs/docs/governance/README.md
index 0e2bfd7485d..86042283eb7 100644
--- a/docs/docs/governance/README.md
+++ b/docs/docs/governance/README.md
@@ -14,8 +14,6 @@ Cosmos governance is driven by the Cosmos community, and much of the documentati
Governance discussions happens in a number of places moderated by diverse community members, including:
- [Forum](http://forum.cosmos.network/)
-- [Discord](https://discord.com/invite/cosmosnetwork)
-
-- [Twitter](https://twitter.com/CosmosGov)
+- [Discord](https://discord.gg/interchain)
- [Reddit](http://reddit.com/r/cosmosnetwork)
- anywhere else you might interact with members of the Cosmos community!
diff --git a/docs/docs/governance/proposal-types/changes-archive/Auth.mdx b/docs/docs/governance/proposal-types/changes-archive/Auth.mdx
deleted file mode 100644
index 568d83dfdf0..00000000000
--- a/docs/docs/governance/proposal-types/changes-archive/Auth.mdx
+++ /dev/null
@@ -1,121 +0,0 @@
----
-title: x/auth
----
-
-import { KeyValueTable } from '@site/src/js/KeyValueTable';
-import { Var } from '@site/src/js/Var';
-import { currentParams } from '@site/docs/governance/current-parameters.js';
-
-```
-gaiad q auth params
-```
-
-The `auth` module is responsible for authenticating accounts and transactions. It has the following parameters:
-
-
-
-The `auth` module is responsible for specifying the base transaction and account types for an application, since the SDK itself is agnostic to these particulars. It contains the ante handler, where all basic transaction validity checks (signatures, nonces, auxiliary fields) are performed, and exposes the account keeper, which allows other modules to read, write, and modify accounts.
-
-## Governance notes on parameters
-
-### `max_memo_characters`
-
-**The character limit for each transaction memo.**
-
-There is an option to include a "memo," or additional information (data) to Cosmos Hub transactions, whether sending funds, delegating, voting, or other transaction types. This parameter limits the number of characters that may be included in the memo line of each transaction.
-
-- on-chain value:
-- `cosmoshub-4` genesis: `512`
-- `cosmoshub-3` genesis: `512`
-
-#### Decreasing the value of `max_memo_characters`
-
-Decreasing the value of `max_memo_characters` will decrease the character limit for each transaction memo. This may break the functionality of applications that rely upon the data in the memo field. For example, an exchange may use a common deposit address for all of its users, and then individualize account deposits using the memo field. If the memo field suddenly decreased, the exchange may no longer automatically sort its users' transactions.
-
-#### Increasing the value of `max_memo_characters`
-
-
-
-Increasing the value of `max_memo_characters` will increase the character limit for each transaction memo. This may enable new functionality for applications that use transaction memos. It may also enable an increase in the amount of data in each block, leading to an increased storage need for the blockchain and [state bloat](https://thecontrol.co/state-growth-a-look-at-the-problem-and-its-solutions-6de9d7634b0b).
-
-
-
-### `tx_sig_limit`
-
-**The max number of signatures per transaction**
-
-Users and applications may create multisignature (aka multisig) accounts. These accounts require more than one signature to generate a transaction. This parameter limits the number of signatures in a transaction.
-
-- on-chain value:
-- `cosmoshub-4` genesis: `7`
-- `cosmoshub-3` genesis: `7`
-
-#### Decreasing the value of `tx_sig_limit`
-
-Decreasing the value of `tx_sig_limit` will decrease the maximum number of signatures possible. This may constrain stakeholders that want to use as many as seven signatures to authorize a transaction. It will also break the functionality of entities or applications dependent upon up to seven transactions, meaning that those transactions will no longer be able to be authorized. In this case, funds and functions controlled by a multisignature address will no longer be accessible, and funds may become stranded.
-
-#### Increasing the value of `tx_sig_limit`
-
-Increasing the value of `tx_sig_limit` will increase the maximum number of signatures possible. As this value increases, the network becomes more likely to be susceptible to attacks that slow block production, due to the burden of computational cost when verifying more signatures (since signature verification is costlier than other operations).
-
-### `tx_size_cost_per_byte`
-
-**Sets the cost of transactions, in units of gas.**
-
-`tx_size_cost_per_byte` is used to compute the gas-unit consumption for each transaction.
-
-- on-chain value:
-- `cosmoshub-4` genesis: `10`
-- `cosmoshub-3` genesis: `10`
-
-#### Decreasing the value of `tx_size_cost_per_byte`
-
-Decreasing the value of `tx_size_cost_per_byte` will reduce the number of gas units used per transaction. This may also reduce the fees that validators earn for processing transactions. There may be other effects that have not been detailed here.
-
-#### Increasing the value of `tx_size_cost_per_byte`
-
-Increasing the value of `tx_size_cost_per_byte` will raise the number of gas units used per transaction. This may also increase the fees that validators earn for processing transactions. There may be other effects that have not been detailed here.
-
-### `sig_verify_cost_ed25519`
-
-**The cost for verifying ED25519 signatures, in units of gas.**
-
-Ed25519 is the EdDSA cryptographic signature scheme (using SHA-512 (SHA-2) and Curve25519) that is used by Cosmos Hub validators. `sig_verify_cost_ed25519` is the gas (ie. computational) cost for verifying ED25519 signatures, and ED25519-based transactions are not currently accepted by the Cosmos Hub.
-
-- on-chain value:
-- `cosmoshub-4` genesis: `590`
-- `cosmoshub-3` genesis: `590`
-
-#### Decreasing the value of `sig_verify_cost_ed25519`
-
-Decreasing the value of `sig_verify_cost_ed25519` will decrease the amount of gas that is consumed by transactions that require Ed25519 signature verifications. Since Ed25519-signed transactions are not currently accepted by Cosmos Hub, changing this parameter is unlikely to affect stakeholders at this time.
-
-#### Increasing the value of `sig_verify_cost_ed25519`
-
-Increasing the value of `sig_verify_cost_ed25519` will increase the amount of gas that is consumed by transactions that require Ed25519 signature verifications. Since Ed25519 signature transactions are not currently accepted by Cosmos Hub, changing this parameter is unlikely to affect stakeholders at this time.
-
-#### Notes
-
-Ed25519 signatures are not currently being accepted by the Cosmos Hub. Ed25519 signatures will be verified and can be considered valid, so the gas to verify them will be consumed. However, the transaction itself will be rejected. It could be that these signatures will be used for transactions a later time, such as after inter-blockchain communication (IBC) evidence upgrades happen.
-
-### `sig_verify_cost_secp256k1`
-
-**The cost for verifying Secp256k1 signatures, in units of gas.**
-
-Secp256k1 is an elliptic curve domain parameter for cryptographic signatures used by user accounts in the Cosmos Hub. `sig_verify_cost_secp256k1` is the gas (ie. computational) cost for verifying Secp256k1 signatures. Practically all Cosmos Hub transactions require Secp256k1 signature verifications.
-
-- on-chain value:
-- `cosmoshub-4` default: `1000`
-- `cosmoshub-3` default: `1000`
-
-#### Decreasing the value of `sig_verify_cost_secp256k1`
-
-Decreasing the value of `sig_verify_cost_secp256k1` will decrease the amount of gas that is consumed by practically all Cosmos Hub transactions, which require Secp256k1 signature verifications. Decreasing this parameter may have unintended effects on how the Cosmos Hub operates, since the computational cost of verifying a transaction may be greater than what the system's assumption is.
-
-#### Increasing the value of `sig_verify_cost_secp256k1`
-
-Increasing the value of `sig_verify_cost_secp256k1` will increase the amount of gas that is consumed by practically all Cosmos Hub transactions, which require Secp256k1 signature verifications. Increasing this parameter may have unintended effects on how the Cosmos Hub operates, since the computational cost of verifying a transaction may be less than what the system's assumption is.
-
-#### Notes
-
-There should be a better understanding of what the potential implications are for changing `sig_verify_cost_secp256k1`. For example, gas calculations are important because blocks have a gas limit. Transactions could be rejected for exceeding the block gas limit, breaking application functionality or perhaps preventing addresses controlled by multiple signatures from moving funds.
diff --git a/docs/docs/governance/proposal-types/changes-archive/Crisis.mdx b/docs/docs/governance/proposal-types/changes-archive/Crisis.mdx
deleted file mode 100644
index 3aa1416acfa..00000000000
--- a/docs/docs/governance/proposal-types/changes-archive/Crisis.mdx
+++ /dev/null
@@ -1,37 +0,0 @@
----
-title: x/crisis subspace
----
-
-import { KeyValueTable } from '@site/src/js/KeyValueTable';
-import { Var } from '@site/src/js/Var';
-import { currentParams } from '@site/docs/governance/current-parameters.js';
-
-The `crisis` module is responsible for halting the Cosmos Hub if an invariant is broken. The crisis module has the following parameters:
-
-
-
-The `crisis` module is responsible for halting the blockchain under the circumstance that a blockchain invariant is broken. Invariants can be registered with the application during the application initialization process.
-
-## Governance notes on parameters
-
-### `ConstantFee`
-
-**The amount required to send a message to halt the Cosmos Hub chain if an invariant is broken, in micro-ATOM.**
-
-A Cosmos account (address) can send a transaction message that will halt the Cosmos Hub chain if an invariant is broken. An example of this would be if all of the account balances in total did not equal the total supply. This kind of transaction could consume excessive amounts of gas to compute, beyond the maximum allowable block gas limit. `ConstantFee` makes it possible to bypass the gas limit in order to process this transaction, while setting a cost to disincentivize using the function to attack the network. The cost of the transaction is `1333000000` `uatom` (1,333 ATOM) and will effectively not be paid if the chain halts due to a broken invariant (which similar to being refunded). If the invariant is not broken, then `ConstantFee` will be paid. All in Bits has published more information about the [crisis module here](https://docs.cosmos.network/main/modules/crisis).
-
-- on-chain value:
-- `cosmoshub-4` default: `1333000000` `uatom`
-- `cosmoshub-3` default: `1333000000` `uatom`
-
-#### Decreasing the value of `ConstantFee`
-
-Decreasing the value of the `ConstantFee` parameter will reduce the cost of checking an invariant. This will likely make it easier to halt the chain if an invariant is actually broken, but it will lower the cost for an attacker to use this function to slow block production.
-
-#### Increasing the value of `ConstantFee`
-
-Increasing the value of the `ConstantFee` parameter will increase the cost of checking an invariant. This will likely make it more difficult to halt the chain if an invariant is actually broken, but it will increase the cost for an attacker to use this function to slow block production.
-
-#### Notes
-
-Only registered invariants may be checked with this transaction message. Validators are reportedly performant enough to handle large computations like invariant checks, and the likely outcome of multiple invariant checks would be longer block times. In the code, there is a comment that indicates that the designers were targeting $5000 USD as the required amount of ATOMs to run an invariant check.
diff --git a/docs/docs/governance/proposal-types/changes-archive/Distribution.mdx b/docs/docs/governance/proposal-types/changes-archive/Distribution.mdx
deleted file mode 100644
index 37b5ade99e1..00000000000
--- a/docs/docs/governance/proposal-types/changes-archive/Distribution.mdx
+++ /dev/null
@@ -1,146 +0,0 @@
----
-title: x/distribution
----
-
-```shell
-gaiad q distribution params
-```
-
-import { KeyValueTable } from '@site/src/js/KeyValueTable';
-import { Var } from '@site/src/js/Var';
-import { currentParams } from '@site/docs/governance/current-parameters.js';
-
-The `distribution` module is responsible for distributing staking rewards between validators, delegators, and the Community Pool. It has the following parameters:
-
-
-
-The `distribution` module enables a simple distribution mechanism that passively distributes rewards between validators and delegators. Collected rewards are pooled globally and divided out passively to validators and delegators. Each validator has the opportunity to charge commission to the delegators on the rewards collected on behalf of the delegators. Fees are collected directly into a global reward pool and validator proposer-reward pool.
-
-**There is [a known bug](#known-bug) associated with this module.**
-
-## Governance notes on parameters
-
-### `community_tax`
-
-**The proportion of staking rewards diverted to the community pool.**
-
-Staking on the Cosmos Hub entitles participants to inflationary (aka "block") rewards and transaction fees. A portion of these staking rewards is diverted to the community pool, which can be spent with a successful community-spend governance proposal. `community_tax` is the parameter that determines the proportion of staking rewards diverted to the community pool, which is currently `0.020000000000000000` (2%) of all staking rewards.
-
-- on-chain value:
-- `cosmoshub-4` default: `0.020000000000000000`
-- `cosmoshub-3` default: `0.020000000000000000`
-
-#### Decreasing the value of `community_tax`
-
-Decreasing the value of the `community_tax` parameter will decrease the rate that the community pool is funded and will increase the staking rewards captured by staking participants. This will make it more likely for the community pool to be exhausted and could potentially increase the motivation for participants to stake.
-
-#### Increasing the value of `community_tax`
-
-Increasing the value of the `community_tax` parameter will increase the rate that the community pool is funded and will decrease the staking rewards captured by staking participants. This will make it more less for the community pool to be exhausted and could potentially decrease the motivation for participants to stake.
-
-### `base_proposer_reward`
-
-**The fixed base reward bonus for the validator proposing a block, as a proportion of transaction fees.**
-
-All validators in the active set share the rewards for producing a block equally, except for the proposer of a valid block: that validator receives a bonus of `0.010000000000000000` (1%) more in transaction fees. The proposer must include a minimum of 2/3 of precommit signatures from the other validators in the active set in order for the block to be valid and to receive the `base_proposer_reward` bonus. All in Bits has published more in-depth information [here](https://hub.cosmos.network/validators/validator-faq#how-are-fees-distributed).
-
-- on-chain value:
-- `cosmoshub-4` default: `0.010000000000000000`
-- `cosmoshub-3` default: `0.010000000000000000`
-
-#### Decreasing the value of `base_proposer_reward`
-
-Decreasing the value of the `base_proposer_reward` parameter will decrease the advantage that the proposer has over other validators. This may decrease an operator's motivation to ensure that its validator is reliably online and includes at least 2/3 precommit signatures of the other validators in its proposed block.
-
-#### Increasing the value of `base_proposer_reward`
-
-Increasing the value of the `base_proposer_reward` parameter will increase the advantage that the proposer has over other validators. This may increase an operator's motivation to ensure that its validator is reliably online and includes at least 2/3 precommit signatures of the other validators in its proposed block.
-
-#### Notes
-
-The Cosmos Hub transaction fee volume is proportionally very low in value compared to the inflationary block rewards, and until that changes, this parameter will likely have very little impact on validator behaviours. As fee volumes increase, the `base_proposer_reward` bonus may incentivize delegations to the validator(s) with the greatest stake-backing. There are some detailed discussions about the proposer bonus [here](https://github.com/cosmos/cosmos-sdk/issues/3529).
-
-### `bonus_proposer_reward`
-
-**The maximum additional reward bonus for the validator proposing a block, as a proportion of transaction fees.**
-
-All validators in the active set share the rewards for producing a block equally, except for the proposer of a valid block. If that validator includes more than a minimum of 2/3 of precommit signatures from the other validators in the active set, they are eligible to receive the `bonus_proposer_reward` of up to 4% (`0.040000000000000000`), beyond the 1% `base_proposer_reward`. The bonus proposer reward amount that a validator receives depends upon how many precommit signatures are included in the proposed block (additional to the requisite 2/3). All in Bits has published more in-depth information [here](../../../validators/validator-faq#how-are-fees-distributed).
-
-- on-chain value:
-- `cosmoshub-4` default: `0.040000000000000000`
-- `cosmoshub-3` default: `0.040000000000000000`
-
-#### Decreasing the value of `bonus_proposer_reward`
-
-Decreasing the value of the `bonus_proposer_reward` parameter will decrease the advantage that the proposer has over other validators. This may decrease an operator's motivation to ensure that its validator is reliably online and includes more than 2/3 precommit signatures from the other validators in its proposed block.
-
-#### Increasing the value of `bonus_proposer_reward`
-
-Increasing the value of the `bonus_proposer_reward` parameter will increase the advantage that the proposer has over other validators. This may increase an operator's motivation to ensure that its validator is reliably online and includes more than 2/3 precommit signatures from the other validators in its proposed block.
-
-#### Notes
-
-The Cosmos Hub transaction fee volume is proportionally very low in value compared to the inflationary block rewards, and until that changes, this parameter will likely have very little impact on validator behaviours. As fee volumes increase, the `bonus_proposer_reward` bonus may incentivize delegations to the validator(s) with the greatest stake-backing. There are some detailed discussions about the proposer bonus [here](https://github.com/cosmos/cosmos-sdk/issues/3529).
-
-#### Example
-
-**Note** that "reserve pool" refers to the community pool. In this example from the [All in Bits website](../../../validators/validator-faq#how-are-fees-distributed), there are 10 validators with equal stake. Each of them applies a 1% commission rate and has 20% of self-delegated Atoms. Now comes a successful block that collects a total of 1025.51020408 Atoms in fees.
-
-First, a 2% tax is applied. The corresponding Atoms go to the reserve pool (aka community pool). Reserve pool's funds can be allocated through governance to fund bounties and upgrades.
-
-2% \* 1025.51020408 = 20.51020408 Atoms go to the reserve pool.
-1005 Atoms now remain. Let's assume that the proposer included 100% of the signatures in its block. It thus obtains the full bonus of 5%.
-
-We have to solve this simple equation to find the reward R for each validator:
-
-9*R + R + R*5% = 1005 β R = 1005/10.05 = 100
-
-For the proposer validator:
-
-The pool obtains R + R \* 5%: 105 Atoms
-
-Commission: 105 _ 80% _ 1% = 0.84 Atoms
-
-Validator's reward: 105 \* 20% + Commission = 21.84 Atoms
-
-Delegators' rewards: 105 \* 80% - Commission = 83.16 Atoms (each delegator will be able to claim its portion of these rewards in proportion to their stake)
-
-For each non-proposer validator:
-
-The pool obtains R: 100 Atoms
-
-Commission: 100 _ 80% _ 1% = 0.8 Atoms
-
-Validator's reward: 100 \* 20% + Commission = 20.8 Atoms
-
-Delegators' rewards: 100 \* 80% - Commission = 79.2 Atoms (each delegator will be able to claim their portion of these rewards in proportion to their stake)
-
-### `withdrawaddrenabled`
-
-**Determines whether or not delegators may set a separate address for receiving staking rewards.**
-
-Delegators can designate a separate withdrawal address (account) that receives staking rewards when `withdrawaddrenabled` is set to `true`. When `withdrawaddrenabled` is set to `false`, the delegator can no longer designate a separate address for withdrawals.
-
-- on-chain value:
-- `cosmoshub-4` default: `true`
-- `cosmoshub-3` default: `true`
-
-#### Changing the `withdrawaddrenabled` parameter
-
-Changing the `withdrawaddrenabled` to false will prevent delegators from changing or setting a separate withdrawal address (account) that receives the staking rewards. This may disrupt the functionality of applications and the expectations of staking participants.
-
-#### Notes
-
-This parameter was set to `false` before transfers were enabled in order to prevent stakers from diverting their rewards to other addresses ie. to avoid a loophole that would enable ATOM transfer via diverting staking rewards to a designated address.
-
-## Known Bug
-
-There is a known bug associated with this module that has reportedly caused a chain to halt. In [this reported case](https://github.com/cosmos/cosmos-sdk/issues/5808), the chain's parameter values were changed to be:
-
-```
-community_tax: "0.020000000000000000"
-base_proposer_reward: "0.999000000000000000"
-bonus_proposer_reward: "0.040000000000000000"
-```
-
-Though the system will not allow eg. `base_proposer_reward` to be a value greater than 1.0, it will allow the [`community_tax`](#community_tax), [`base_proposer_reward`](#base_proposer_reward), and [`bonus_proposer_reward`](#bonus_proposer_reward) parameters values to total an amount greater than 1.00, which will apparently cause the chain to panic and halt. You can [read more about the reported issue here](https://github.com/cosmos/cosmos-sdk/issues/5808).
diff --git a/docs/docs/governance/proposal-types/changes-archive/Governance.mdx b/docs/docs/governance/proposal-types/changes-archive/Governance.mdx
deleted file mode 100644
index ce779d4af6b..00000000000
--- a/docs/docs/governance/proposal-types/changes-archive/Governance.mdx
+++ /dev/null
@@ -1,167 +0,0 @@
----
-title: x/gov
----
-
-```shell
-gaiad q gov params
-```
-
-import { KeyValueTable } from '@site/src/js/KeyValueTable';
-import { Var } from '@site/src/js/Var';
-import { currentParams } from '@site/docs/governance/current-parameters.js';
-
-The `gov` module is responsible for on-chain governance proposals and voting functionality.
-
-
-
-The `gov` module is responsible for the on-chain governance system. In this system, holders of the native staking token of the chain may vote on proposals on a 1-token per 1-vote basis. The module supports:
-
-- **Proposal submission**: Users can submit proposals with a deposit. Once the minimum deposit is reached, proposal enters voting period
-- **Vote**: Participants can vote on proposals that reached MinDeposit
-- **Inheritance and penalties**: Delegators inherit their validator's vote if they don't vote themselves.
-- **Claiming deposit**: Users that deposited on proposals can recover their deposits if the proposal was accepted OR if the proposal never entered voting period.
-
-## Governance notes on parameters
-
-### `deposit_params`
-
-#### `min_deposit`
-
-**The minimum deposit required for a proposal to enter the [voting period](#votingperiod), in micro-ATOMs.**
-
-- on-chain value:
-- [Proposal 47](https://www.mintscan.io/cosmos/proposals/47) change: `64000000` `uatom`
-- `cosmoshub-4` default: `512000000` `uatom`
-- `cosmoshub-3` default: `512000000` `uatom`
-
-Prior to a governance proposal entering the [voting period](#votingperiod) (ie. for the proposal to be voted upon), there must be at least a minimum number of ATOMs deposited. Anyone may contribute to this deposit. Deposits of passed and failed proposals are returned to the contributors. Deposits are burned when proposals 1) [expire](#max_deposit_period), 2) fail to reach [quorum](#quorum), or 3) are [vetoed](#veto_threshold). This parameter subkey value represents the minimum deposit required for a proposal to enter the [voting period](#votingperiod) in micro-ATOMs, where `512000000uatom` is equivalent to 512 ATOM.
-
-##### Decreasing the value of `min_deposit`
-
-Decreasing the value of the `min_deposit` subkey will enable governance proposals to enter the [voting period](#votingperiod) with fewer ATOMs at risk. This will likely increase the volume of new governance proposals.
-
-##### Increasing the value of `min_deposit`
-
-Increasing the value of the `min_deposit` subkey will require risking a greater number of ATOMs before governance proposals may enter the [voting period](#votingperiod). This will likely decrease the volume of new governance proposals.
-
-#### `max_deposit_period`
-
-**The maximum amount of time that a proposal can accept deposit contributions before expiring, in nanoseconds.**
-
-- on-chain value:
-- `cosmoshub-4` default: `1209600000000000`
-- `cosmoshub-3` default: `1209600000000000`
-
-Prior to a governance proposal entering the [voting period](#votingperiod), there must be at least a minimum number of ATOMs deposited. This parameter subkey value represents the maximum amount of time that the proposal has to reach the minimum deposit amount before expiring. The maximum amount of time that a proposal can accept deposit contributions before expiring is currently `1209600000000000` nanoseconds or 14 days. If the proposal expires, any deposit amounts will be burned.
-
-##### Decreasing the value of `maxdepositperiod`
-
-Decreasing the value of the `maxdepositperiod` subkey will decrease the time for deposit contributions to governance proposals. This will likely decrease the time that some proposals remain visible and potentially decrease the likelihood that they will enter the [voting period](#votingperiod). This may increase the likelihood that proposals will expire and have their deposits burned.
-
-##### Increasing the value of `maxdepositperiod`
-
-Increasing the value of the `maxdepositperiod` subkey will extend the time for deposit contributions to governance proposals. This will likely increase the time that some proposals remain visible and potentially increase the likelihood that they will enter the [voting period](#votingperiod). This may decrease the likelihood that proposals will expire and have their deposits burned.
-
-##### Notes
-
-Currently most network explorers (eg. Hubble, Big Dipper, Mintscan) give the same visibility to proposals in the deposit period as those in the [voting period](#votingperiod). This means that a proposal with a small deposit (eg. 0.001 ATOM) will have the same visibility as those with a full 512 ATOM deposit in the voting period.
-
-### `voting_params`
-
-#### `votingperiod`
-
-**The maximum amount of time that a proposal can accept votes before the voting period concludes, in nanoseconds.**
-
-- on-chain value:
-- `cosmoshub-4` default: `1209600000000000`
-- `cosmoshub-3` default: `1209600000000000`
-
-Once a governance proposal enters the voting period, there is a maximum period of time that may elapse before the voting period concludes. This parameter subkey value represents the maximum amount of time that the proposal has to accept votes, which is currently `1209600000000000` nanoseconds or 14 days. If the proposal vote does not reach quorum ((ie. 40% of the network's voting power is participating) before this time, any deposit amounts will be burned and the proposal's outcome will not be considered to be valid. Voters may change their vote any number of times before the voting period ends. This voting period is currently the same for any kind of governance proposal.
-
-##### Decreasing the value of `votingperiod`
-
-Decreasing the value of the `votingperiod` subkey will decrease the time for voting on governance proposals. This will likely:
-
-1. decrease the proportion of the network that participates in voting, and
-2. decrease the likelihood that quorum will be reached.
-
-##### Increasing the value of `votingperiod`
-
-Increasing the value of the `votingperiod` subkey will increase the time for voting on governance proposals. This may:
-
-1. increase the proportion of the network that participates in voting, and
-2. increase the likelihood that quorum will be reached.
-
-##### Notes
-
-Historically, off-chain discussions and engagement appears to be have been greater occurred during the voting period of a governance proposal than when the proposal is posted off-chain as a draft. A non-trivial amount of the voting power has voted in the second week of the voting period. Proposals 23, 19, and 13 each had approximately 80% network participation or more.
-
-### `tally_params`
-
-#### `quorum`
-
-**The minimum proportion of network voting power required for a governance proposal's outcome to be considered valid.**
-
-- on-chain value:
-- `cosmoshub-4` default: `0.400000000000000000`
-- `cosmoshub-3` default: `0.400000000000000000`
-
-Quorum is required for the outcome of a governance proposal vote to be considered valid and for deposit contributors to recover their deposit amounts, and this parameter subkey value represents the minimum value for quorum. Voting power, whether backing a vote of 'yes', 'abstain', 'no', or 'no-with-veto', counts toward quorum. If the proposal vote does not reach quorum (ie. 40% of the network's voting power is participating) before this time, any deposit amounts will be burned and the proposal outcome will not be considered to be valid.
-
-##### Decreasing the value of `quorum`
-
-Decreasing the value of the `quorum` subkey will enable a smaller proportion of the network to legitimize the outcome of a proposal. This increases the risk that a decision will be made with a smaller proportion of ATOM-stakers' positions being represented, while decreasing the risk that a proposal will be considered invalid. This will likely decrease the risk of a proposal's deposit being burned.
-
-##### Increasing the value of `quorum`
-
-Increasing the value of the `quorum` subkey will require a larger proportion of the network to legitimize the outcome of a proposal. This decreases the risk that a decision will be made with a smaller proportion of ATOM-stakers' positions being represented, while increasing the risk that a proposal will be considered invalid. This will likely increase the risk of a proposal's deposit being burned.
-
-#### `threshold`
-
-**The minimum proportion of participating voting power required for a governance proposal to pass.**
-
-- on-chain value:
-- `cosmoshub-4` default: `0.500000000000000000`
-- `cosmoshub-3` default: `0.500000000000000000`
-
-A simple majority 'yes' vote (ie. 50% of participating voting power) is required for a governance proposal vote to pass. Though necessary, a simple majority 'yes' vote may not be sufficient to pass a proposal in two scenarios:
-
-1. Failure to reach [quorum](#quorum) of 40% network power or
-2. A 'no-with-veto' vote of 33.4% of participating voting power or greater.
-
-If a governance proposal passes, deposit amounts are returned to contributors. If a text-based proposal passes, nothing is enacted automatically, but there is a social expectation that participants will co-ordinate to enact the commitments signalled in the proposal. If a parameter change proposal passes, the protocol parameter will automatically change immediately after the [voting period](#votingperiod) ends, and without the need to run new software. If a community-spend proposal passes, the Community Pool balance will decrease by the number of ATOMs indicated in the proposal and the recipient's address will increase by this same number of ATOMs immediately after the voting period ends.
-
-##### Decreasing the value of `threshold`
-
-Decreasing the value of the `threshold` subkey will decrease the proportion of voting power required to pass a proposal. This may:
-
-1. increase the likelihood that a proposal will pass, and
-2. increase the likelihood that a minority group will effect changes to the network.
-
-##### Increasing the value of `threshold`
-
-Increasing the value of the `threshold` subkey will increase the proportion of voting power required to pass a proposal. This may:
-
-1. decrease the likelihood that a proposal will pass, and
-2. decrease the likelihood that a minority group will effect changes to the network.
-
-#### `veto_threshold`
-
-**The minimum proportion of participating voting power to veto (ie. fail) a governance proposal.**
-
-- on-chain value:
-- `cosmoshub-4` default: `0.334000000000000000`
-- `cosmoshub-3` default: `0.334000000000000000`
-
-Though a simple majority 'yes' vote (ie. 50% of participating voting power) is required for a governance proposal vote to pass, a 'no-with-veto' vote of 33.4% of participating voting power or greater can override this outcome and cause the proposal to fail. This enables a minority group representing greater than 1/3 of voting power to fail a proposal that would otherwise pass.
-
-##### Decreasing the value of `veto_threshold`
-
-Decreasing the value of the `veto_threshold` subkey will decrease the proportion of participating voting power required to veto. This will likely:
-
-1. enable a smaller minority group to prevent proposals from passing, and
-2. decrease the likelihood that contentious proposals will pass.
-
-##### Increasing the value of `veto_threshold`
-
-Increasing the value of the `veto_threshold` subkey will increase the proportion of participating voting power required to veto. This will require a larger minority group to prevent proposals from passing, and will likely increase the likelihood that contentious proposals will pass.
diff --git a/docs/docs/governance/proposal-types/changes-archive/Mint.mdx b/docs/docs/governance/proposal-types/changes-archive/Mint.mdx
deleted file mode 100644
index bf68e8612df..00000000000
--- a/docs/docs/governance/proposal-types/changes-archive/Mint.mdx
+++ /dev/null
@@ -1,170 +0,0 @@
----
-title: x/mint
----
-
-```shell
-gaiad q mint params
-```
-
-import { KeyValueTable } from '@site/src/js/KeyValueTable';
-import { Var } from '@site/src/js/Var';
-import { currentParams } from '@site/docs/governance/current-parameters.js';
-
-The `mint` module is responsible for enabling the Cosmos Hub to have a flexible inflation rate that depends upon a bonded stake ratio target. It has the following parameters
-
-
-
-The `mint` module was designed to allow for a flexible inflation rate determined by market demand targeting a particular bonded-stake ratio, and effect a balance between market liquidity and staked supply.
-
-In order to best determine the appropriate market rate for inflation rewards, a moving change rate is used. The moving change rate mechanism ensures that if the % bonded is either over or under the goal %-bonded, the inflation rate will adjust to further incentivize or disincentivize being bonded, respectively. Setting the goal %-bonded at less than 100% encourages the network to maintain some non-staked tokens in order to help provide some liquidity.
-
-It can be broken down in the following way:
-
-- If the inflation rate is below the goal %-bonded the inflation rate will increase until a maximum value is reached
-- If the goal % bonded (67% in Cosmos-Hub) is maintained, then the inflation rate will stay constant
-- If the inflation rate is above the goal %-bonded the inflation rate will decrease until a minimum value is reached
-
-## Governance notes on parameters
-
-### `mint_denom`
-
-**Type of asset/coin that the Cosmos Hub mints.**
-
-- on-chain value
-- `cosmoshub-4` default: `uatom`
-- `cosmoshub-3` default: `uatom`
-
-This is the type of asset (aka coin) that is being minted. The Cosmos Hub produces `uatom`, or micro-ATOM, where 1,000,000 uatom is equivalent to 1 ATOM.
-
-#### Changing the `mint_denom` parameter
-
-Changing the `mint_denom` will change the asset that the Cosmos Hub mints from the ATOM. This is likely to disrupt the functionality of applications and the expectations of staking participants.
-
-### `inflation_rate_change`
-
-**A factor of and limit to the speed at which the Cosmos Hub's inflation rate changes.**
-
-- on-chain value:
-- [Proposal 48](https://www.mintscan.io/cosmos/proposals/48) change to `1.000000000000000000`
-- `cosmoshub-4` default: `0.130000000000000000`
-- `cosmoshub-3` default: `0.130000000000000000`
-
-Cosmos Hub's inflation rate can change faster or slower, depending on staking participation, and is limited to a minimum of 7% and maximum of 20%. The inflation rate cannot increase or decrease faster than 13% per year (`inflation_rate_change`). The speed that the inflation rate changes depends upon two things:
-
-1. how far away the _current staking participation ratio_ is from [`goal_bonded`](#5-goal_bonded) (67%)
-2. the value of `inflation_rate_change`, which is
-
-```
-inflationRateChangePerYear = (1 - bondedRatio/params.goal_bonded) * params.inflation_rate_change
-```
-
-[The source for this information can be found here](https://github.com/cosmos/cosmos-sdk/tree/main/x/mint#begin-block).
-
-The inflation rate increases when under 67% of the token supply is staking, and it will take less time to reach the maximum of rate of 20% inflation if (for example) 30% of the token supply is staking than if 50% is staking.
-
-#### Decreasing the value of `inflation_rate_change`
-
-Decreasing the value of the `inflation_rate_change` parameter will decrease both how fast the inflation rate changes and also the maximum speed that it can potentially change. It will then take longer for inflation to reach [`inflation_min`](#inflation_min) or [`inflation_max`](#inflation_max). This may lessen the response of staking behaviour to the incentive mechanism [described in the notes below](#notes).
-
-#### Increasing the value of `inflation_rate_change`
-
-Increasing the value of the `inflation_rate_change` parameter will increase both how fast the inflation rate changes and also the maximum speed that it can potentially change. It will then take less time for inflation to reach [`inflation_min`](#inflation_min) or [`inflation_max`](#inflation_max). This may quicken the response of staking behaviour to the incentive mechanism [described in the notes below](#notes).
-
-#### Notes
-
-**Example:** if the current staking participation ratio (aka "bond ratio") is 73%, then this is the calculation for speed that the inflation rate will change:
-
-(1 - 73%/67%) \* 13% = -1.16% per year
-
-This means that if the staking participation rate stays the same, the inflation rate will decrease by 1.16% over the course of one year, during which time the Hub's inflation rate will decrease by about 0.1% per month.
-
-If `inflation_rate_change` is 26% and the current staking participation ratio (aka "bond ratio") is 73%, then the inflation will decrease by 2.33% over the course of one year, during which time inflation will decrease by about 0.19% per month.
-
-The Cosmos Hub's inflation rate is tied to its staking participation ratio in order to make staking more or less desirable, since most of the Hub's inflation is used to fund staking rewards. If the speed of inflation responds more strongly to staking participation, it could be that staking behaviour will also respond more strongly.
-
-### `inflation_max`
-
-**The maximum rate that the Cosmos Hub can mint new ATOMs, proportional to the supply.**
-
-- on-chain value:
-- `cosmoshub-4` default: `0.200000000000000000`
-- `cosmoshub-3` default: `0.200000000000000000`
-
-The maximum rate that the Cosmos Hub can be set to mint new ATOMs is determined by `inflation_max`, which is 20% (`0.200000000000000000`) of the ATOM supply per year and based on the assumption that there are 4,855,015 blocks produced per year (see [`blocks_per_year`](#blocks_per_year)). If the Cosmos Hub's staking ratio (ie. the number of ATOMs staked vs total supply) remains below [`goal_bonded`](#goal_bonded)(67%) for long enough, its inflation setting will eventually reach this maximum.
-
-#### Decreasing the value of `inflation_max`
-
-Decreasing the value of the `inflation_max` parameter will lower the maximum rate that the Cosmos Hub produces new ATOMs and reduce the rate at which the ATOM supply expands. This will reduce the rate at which token-holders' assets are diluted and may reduce the incentive for staking participation.
-
-#### Increasing the value of `inflation_max`
-
-Increasing the value of the `inflation_max` parameter will raise the maximum rate that the Cosmos Hub produces new ATOMs and raise the rate at which the ATOM supply expands. This will increase the rate at which token-holders' assets are diluted and may increase the incentive for staking participation.
-
-#### Notes
-
-The effective rate of inflation tends to be different than the set rate of inflation because inflation is dependent upon the number of blocks produced per year. If blocks are produced more slowly than 6.50 seconds per block, then fewer than the assumed 4,855,015 will be produced per year, and effectively inflation will be lower than the set rate. If blocks are produced more quickly than 6.50 seconds per block, then more than the assumed 4,855,015 will be produced per year, and effectively inflation will be higher than the set rate.
-
-### `inflation_min`
-
-**The minimum rate that the Cosmos Hub can mint new ATOMs, proportional to the supply.**
-
-- on-chain value:
-- `cosmoshub-4` default: `0.070000000000000000`
-- `cosmoshub-3` default: `0.070000000000000000`
-
-The minimum rate that the Cosmos Hub can be set to mint new ATOMs is determined by `inflation_min`, which is 7% (`0.070000000000000000`) of the ATOM supply per year and based on the assumption that there are 4,855,015 blocks produced per year (see [`blocks_per_year`](#blocks_per_year)). If the Cosmos Hub's staking ratio (ie. the number of ATOMs staked vs total supply) remains above [`goal_bonded`](#goal_bonded)(67%) for long enough, its inflation setting will eventually reach this minimum.
-
-#### Decreasing the value of `inflation_min`
-
-Decreasing the value of the `inflation_min` parameter will lower the minimum rate that the Cosmos Hub produces new ATOMs and reduce the rate at which the ATOM supply expands. This will reduce the rate at which token-holders' assets are diluted and may reduce the incentive for staking participation.
-
-#### Increasing the value of `inflation_min`
-
-Increasing the value of the `inflation_min` parameter will raise the minimum rate that the Cosmos Hub produces new ATOMs and raise the rate at which the ATOM supply expands. This will increase the rate at which token-holders' assets are diluted and may increase the incentive for staking participation.
-
-#### Notes
-
-The effective rate of inflation tends to be different than the set rate of inflation because inflation is dependent upon the number of blocks produced per year. If blocks are produced more slowly than 6.50 seconds per block, then fewer than the assumed 4,855,015 will be produced per year, and effectively inflation will be lower than the set rate. If blocks are produced more quickly than 6.50 seconds per block, then more than the assumed 4,855,015 will be produced per year, and effectively inflation will be higher than the set rate.
-
-### `goal_bonded`
-
-**The target proportion of staking participation, relative to the ATOM supply.**
-
-- on-chain value:
-- `cosmoshub-4` default: `0.670000000000000000`
-- `cosmoshub-3` default: `0.670000000000000000`
-
-`goal_bonded` is the target proportion of staking participation, relative to the ATOM supply. Currently the goal of the system's design is to have 67% (`0.670000000000000000`) of the total ATOM supply bonded and participating in staking. When over 67% of the supply is staked, the inflation set rate begins decreasing at a maximum yearly rate of [`inflation_rate_change`](#inflation_rate_change) until it reaches and remains at the [`inflation_min`](#inflation_min) of 7%. When under 67% of the supply is staked, the inflation set rate begins increasing at a maximum yearly rate of [`inflation_rate_change`](#inflation_rate_change) until it reaches and remains at the [`inflation_max`](#inflation_max) of 20%.
-
-#### Decreasing the value of `goal_bonded`
-
-Decreasing the value of the `goal_bonded` parameter will cause the Cosmos Hub's inflation setting to begin decreasing at a lower participation rate, and this may reduce the incentive for staking participation.
-
-#### Increasing the value of `goal_bonded`
-
-Increasing the value of the `goal_bonded` parameter will cause the Cosmos Hub's inflation setting to begin increasing at a lower participation rate, and this may increase the incentive for staking participation.
-
-### `blocks_per_year`
-
-**The system's assumed number of blocks that the Cosmos Hub will produce in one year.**
-
-- on-chain value:
-- `cosmoshub-4` default: `4360000`
-- [Proposal 30](https://www.mintscan.io/cosmos/proposals/30) change to `4360000`
-- `cosmoshub-3` default: `4855015`
-
-`blocks_per_year` is the setting for the system's assumed number of blocks that the Cosmos Hub will produce in one year. `blocks_per_year` is currently and the network's inflationary behaviour will be aligned with its settings when the average block time is 7.24 seconds (see [Proposal 30](https://www.mintscan.io/cosmos/proposals/30)) seconds over one year. `blocks_per_year` is most notably used in by the system to determine the rate that new ATOMs are minted, which can vary if block times vary from 6.50 seconds per block, since effectively a different number of blocks will be produced in one year and ATOMs are minted each block.
-
-#### Changing the `blocks_per_year` parameter
-
-Changing the `blocks_per_year` parameter will change the assumption that system makes about how many Cosmos Hub blocks will be produced per year. If block times are greater than 6.50 seconds, then this parameter should be decreased to make the Cosmos Hub's inflationary behaviour more aligned with its settings. If block times are less than 6.50 seconds, then this parameter should be increased to make the Cosmos Hub's behaviour more aligned with its settings.
-
-#### Notes
-
-The calculation for seconds in one year:
-
-365.24 (days) _ 24 (hours) _ 60 (minutes) \* 60 (seconds) = 31556736 seconds
-
-**Example:** If block times are 7.12 seconds per block and 31556736 seconds per year:
-
-31556736 / 7.12 = ~4432126 blocks per year
diff --git a/docs/docs/governance/proposal-types/changes-archive/Slashing.mdx b/docs/docs/governance/proposal-types/changes-archive/Slashing.mdx
deleted file mode 100644
index 8102de09ec3..00000000000
--- a/docs/docs/governance/proposal-types/changes-archive/Slashing.mdx
+++ /dev/null
@@ -1,156 +0,0 @@
----
-title: x/slashing
----
-
-```shell
-gaiad q slashing params
-```
-
-import { KeyValueTable } from '@site/src/js/KeyValueTable';
-import { Var } from '@site/src/js/Var';
-import { currentParams } from '@site/docs/governance/current-parameters.js';
-
-The `slashing` module is responsible for enabling the Cosmos Hub to penalize any validator for an attributable violation of protocol rules by slashing (ie. partially destroying) the bonded ATOMs of their stake-backing. Penalties may include a) burning some amount of a staked bond and b) removing the ability to vote on future blocks and governance proposals for a period of time. Parameters include:
-
-
-
-## Governance notes on parameters
-
-### `signed_blocks_window`
-
-**Window for being offline without being slashed, in blocks.**
-
-- on-chain value:
-- `cosmoshub-4` default: `0.200000000000000000`
-- `cosmoshub-3` default: `0.200000000000000000`
-
-If a validator in the active set is offline for too long, the validator will be slashed by [`slash_fraction_downtime`](#slash_fraction_downtime) and temporarily removed from the active set for at least the [`downtime_jail_duration`](#downtime_jail_duration), which is 10 minutes.
-
-How long is being offline for too long? There are two components: `signed_blocks_window` and [`min_signed_per_window`](#min_signed_per_window). Since `min_signed_per_window` is 5% and `signed_blocks_window` is 10,000, a validator must have signed at least 5% of 10,000 blocks (500 out of 10,000) at any given time to comply with protocol rules. That means a validator that misses 9,500 consecutive blocks will be considered by the system to have committed a liveness violation. The time window for being offline without breaking system rules is proportional to this parameter.
-
-More about liveness [here](https://docs.cosmos.network/main/modules/slashing#signing-info-liveness).
-
-#### Decreasing the value of `signed_blocks_window`
-
-Decreasing the value of the `signed_blocks_window` parameter will decrease the window for complying with the system's liveness rules. This will make it more likely that offline validators will be slashed by [`slash_fraction_downtime`](#slash_fraction_downtime) and temporarily removed from the active set for at least [`downtime_jail_duration`](#downtime_jail_duration). While out of the active set, the votes of the validator and its delegators do not count toward governance proposals.
-
-**Example:**
-
-If we pass a proposal to cut `signed_blocks_window` in half from 10,000 to 5,000 blocks, what happens?
-
-Validators must now sign at least 5% of 5,000 blocks, which is 250 blocks. That means that a validator that misses 4,750 consecutive blocks will be considered by the system to have committed a liveness violation, where previously 9,500 consecutive blocks would need to have been missed to violate these system rules.
-
-That's ~9.25 hours instead of ~18.5 hours, assuming 7s block times.
-
-#### Increasing the value of `signed_blocks_window`
-
-Increasing the value of the `signed_blocks_window` parameter will increase the window for complying with the system's liveness rules. This will make it less likely that offline validators will be slashed by [`slash_fraction_downtime`](#slash_fraction_downtime) and temporarily removed from the active set for at least [`downtime_jail_duration`](#downtime_jail_duration).
-
-**Example:**
-
-If we pass a proposal to double `signed_blocks_window` from 10,000 to 20,000 blocks, what happens?
-
-Validators must now sign at least 5% of 20,000 blocks, which is 1000 blocks. That means that a validator that misses 19,000 consecutive blocks will be considered by the system to have committed a liveness violation, where previously 9,500 consecutive blocks would need to have been missed to violate these system rules.
-
-That's ~37 hours instead of ~18.5 hours, assuming 7s block times.
-
-### `min_signed_per_window`
-
-**Minimum proportion of blocks signed per window without being slashed.**
-
-- on-chain value:
-- `cosmoshub-4` default: `0.050000000000000000`
-- `cosmoshub-3` default: `0.050000000000000000`
-
-If a validator in the active set is offline for too long, the validator will be slashed by [`slash_fraction_downtime`](#slash_fraction_downtime) and temporarily removed from the active set for at least the [`downtime_jail_duration`](#downtime_jail_duration), which is 10 minutes.
-
-How long is being offline for too long? There are two components: [`signed_blocks_window`](#signed_blocks_window) and `min_signed_per_window`. Since `min_signed_per_window` is 5% and `signed_blocks_window` is 10,000, a validator must have signed at least 5% of 10,000 blocks (500 out of 10,000) at any given time to comply with protocol rules. That means a validator that misses 9,500 consecutive blocks will be considered by the system to have committed a liveness violation. The threshold-proportion of blocks is determined by this parameter, so the greater that `min_signed_per_window` is, the lower the tolerance for missed blocks by the system.
-
-More about liveness [here](https://docs.cosmos.network/main/modules/slashing#signing-info-liveness).
-
-#### Decreasing the value of `min_signed_per_window`
-
-Decreasing the value of the `min_signed_per_window` parameter will increase the threshold for complying with the system's liveness rules. This will make it less likely that offline validators will be slashed by [`slash_fraction_downtime`](#5-slash_fraction_downtime) and temporarily removed from the active set for at least [`downtime_jail_duration`](#3-downtime_jail_duration). While out of the active set, the votes of the validator and its delegators do not count toward governance proposals.
-
-**Example:**
-
-If we pass a proposal to cut `min_signed_per_window` in half from `0.050000000000000000` (5%) to `0.025000000000000000` (2.5%), what happens?
-
-Validators must now sign at least 2.5% of 10,000 blocks, which is 250 blocks. That means that a validator that misses 9,750 consecutive blocks will be considered by the system to have committed a liveness violation, where previously 9,500 consecutive blocks would need to have been missed to violate these system rules.
-
-That's ~19 hours instead of ~18.5 hours, assuming 7s block times.
-
-#### Increasing the value of `min_signed_per_window`
-
-Increasing the value of the `min_signed_per_window` parameter will decrease the threshold for complying with the system's liveness rules. This will make it more likely that offline validators will be slashed by [`slash_fraction_downtime`](#slash_fraction_downtime) and temporarily removed from the active set for at least [`downtime_jail_duration`](#downtime_jail_duration). While out of the active set, the votes of the validator and its delegators do not count toward governance proposals.
-
-**Example:**
-
-If we pass a proposal to double the `min_signed_per_window` from `0.050000000000000000` (5%) to `0.100000000000000000` (10%), what happens?
-
-Validators must now sign at least 10% of 10,000 blocks, which is 1000 blocks. That means that a validator that misses 9,000 consecutive blocks will be considered by the system to have committed a liveness violation, where previously 9,500 consecutive blocks would need to have been missed to violate these system rules.
-
-That's ~17.5 hours instead of ~18.5 hours, assuming 7s block times.
-
-### `downtime_jail_duration`
-
-**The suspension time (aka jail time) for a validator that is offline too long, in nanoseconds.**
-
-- on-chain value:
-- `cosmoshub-4` default: `600000000000`
-- `cosmoshub-3` default: `600000000000`
-
-A validator in the active set that's offline for too long, besides being slashed, will be temporarily removed from the active set (aka "[jailed](https://docs.cosmos.network/main/modules/slashing#unjail)") for at least [`downtime_jail_duration`](#downtime_jail_duration), which is 10 minutes (`600000000000` nanoseconds). During this time, a validator is not able to sign blocks and its delegators will not earn staking rewards. After the `downtime_jail_duration` period has passed, the validator operator may send an "[unjail](https://docs.cosmos.network/main/modules/slashing#unjail)" transaction to resume validator operations.
-
-More about liveness [here](https://docs.cosmos.network/main/modules/slashing#signing-info-liveness).
-
-#### Decreasing the value of `downtime_jail_duration`
-
-Decreasing the value of the `downtime_jail_duration` parameter will require a validator to wait less time before resuming validator operations. During this time, a validator is not able to sign blocks and its delegators will not earn staking rewards.
-
-#### Increasing the value of `downtime_jail_duration`
-
-Increasing the value of the `downtime_jail_duration` parameter will require a validator to wait more time before resuming validator operations. During this time, a validator is not able to sign blocks and its delegators will not earn staking rewards.
-
-### `slash_fraction_double_sign`
-
-**Proportion of stake-backing that is bruned for equivocation (aka double-signing).**
-
-- on-chain value:
-- `cosmoshub-4` default: `0.050000000000000000`
-- `cosmoshub-3` default: `0.050000000000000000`
-
-A validator proven to have signed two blocks at the same height is considered to have committed equivocation, and the system will then permanently burn ("slash") that validator's total delegations (aka stake-backing) by `0.050000000000000000` (5%). All delegators to an offending validator will lose 5% of all ATOMs delegated to this validator. At this point the validator will be "[tombstoned](https://docs.cosmos.network/main/modules/slashing#staking-tombstone)," which means the validator will be permanently removed from the active set of validators, and the validator's stake-backing will only be slashed one time (regardless of how many equivocations).
-
-#### Decreasing the value of `slash_fraction_double_sign`
-
-Decreasing the value of the `slash_fraction_double_sign` parameter will lessen the penalty for equivocation, and offending validators will have a smaller proportion of their stake-backing burned. This may reduce the motivation for operators to ensure that their validators are secure.
-
-#### Increasing the value of `slash_fraction_double_sign`
-
-Increasing the value of the `slash_fraction_double_sign` parameter will heighten the penalty for equivocation, and offending validators will have a larger proportion of their stake-backing burned. This may increase the motivation for operators to ensure that their validators are secure.
-
-### `slash_fraction_downtime`
-
-**Proportion of stake that is slashed for being offline too long.**
-
-- on-chain value:
-- `cosmoshub-4` default: `0.000100000000000000`
-- `cosmoshub-3` default: `0.000100000000000000`
-
-If a validator in the active set is offline for too long, the system will permanently burn ("slash") that validator's total delegations (aka stake-backing) by a `slash_fraction_downtime` of `0.000100000000000000` (0.01%). All delegators to an offending validator will lose 0.01% of all ATOMs delegated to this validator. At this point the validator will be "[jailed](https://docs.cosmos.network/main/modules/slashing#unjail)," which means the validator will be temporarily removed from the active set of validators so the validator's stake-backing will only be slashed one time.
-
-#### Decreasing the value of `slash_fraction_downtime`
-
-Decreasing the value of the `slash_fraction_downtime` parameter will lessen the penalty for liveness violations, and offending validators will have a smaller proportion of their stake-backing burned. This may reduce the motivation for operators to ensure that their validators are online.
-
-#### Increasing the value of `slash_fraction_downtime`
-
-Increasing the value of the `slash_fraction_downtime` parameter will heighten the penalty for liveness violations, and offending validators will have a larger proportion of their stake-backing burned. This may increase the motivation for operators to ensure that their validators are online.
-
-### `MaxEvidenceAge`
-
-- deprecated in `cosmoshub-4`
-- `cosmoshub-3` default: `1814400000000000`
-
-This parameter was present in `cosmoshub-3`, but was [deprecated](https://github.com/cosmos/cosmos-sdk/pull/5952) for `cosmoshub-4` genesis.
diff --git a/docs/docs/governance/proposal-types/changes-archive/Staking.mdx b/docs/docs/governance/proposal-types/changes-archive/Staking.mdx
deleted file mode 100644
index 7f65dd7b39a..00000000000
--- a/docs/docs/governance/proposal-types/changes-archive/Staking.mdx
+++ /dev/null
@@ -1,118 +0,0 @@
----
-title: x/staking
----
-
-```shell
-gaiad q staking params
-```
-
-import { KeyValueTable } from '@site/src/js/KeyValueTable';
-import { Var } from '@site/src/js/Var';
-import { currentParams } from '@site/docs/governance/current-parameters.js';
-
-The `staking` module is responsible for the proof of stake (PoS) layer of the Cosmos Hub blockchain. It includes the following parameters:
-
-
-
-The `staking` module is responsible for supporting an advanced Proof of Stake (PoS) system. In this system, holders of the native staking token of the chain can become validators and can delegate tokens to validators, ultimately determining the effective validator set for the system.
-
-## Governance notes on parameters
-
-### `unbonding_time`
-
-**The time duration required for bonded ATOMs to unbond and become transferrable, in nanoseconds.**
-
-- on-chain value:
-- `cosmoshub-4` default: `1814400000000000`
-- `cosmoshub-3` default: `1814400000000000`
-
-In order to participate as a Cosmos Hub validator or delegator, ATOMs must be bonded (also known as staking). Once bonded, ATOMs are locked by the protocol and are no longer transferrable. When ATOM unbonding is initiated, the `unbonding_time` of 1814400000000000 nanoseconds (21 days) duration must pass before the ATOMs will be unlocked and transferrable.
-
-ATOMs are used as a bond when staking. A bond may be slashed (ie. partially destroyed) when a validator has been proven to have broken protocol rules. Why? Primarily as a solution to the "[nothing-at-stake](https://medium.com/coinmonks/understanding-proof-of-stake-the-nothing-at-stake-theory-1f0d71bc027)" problem. In the scenario of an accidental or malicious attempt to rewrite history and reverse a transaction, a new chain ("fork") may be created in parallel with the primary chain. Without the risk of losing this bond, the optimal strategy for any validator is to validate blocks on both chains so that the validator gets their reward no matter which fork wins. A bond makes it more likely that the optimal strategy for validators will be to only validate blocks for the true ("canonical") chain.
-
-Why is `unbonding_time` so long? It can take time to discover that a validator has committed equivocation ie. signed two blocks at the same block height. If a validator commits equivocation and then unbonds before being caught, the protocol can no longer slash (ie. partially destroy) the validator's bond.
-
-#### Decreasing the value of `unbonding_time`
-
-Decreasing the value of the `unbonding_time` parameter will reduce the time it takes to unbond ATOMs. This will make it less likely for a validator's bond to be slashed after committing equivocation (aka double-signing).
-
-#### Increasing the value of `unbonding_time`
-
-Increasing the value of the `unbonding_time` parameter will increase the time it takes to unbond ATOMs. This will make it more likely for a validator's bond to be slashed after committing equivocation (aka double-signing).
-
-#### Notes
-
-The ability to punish a validator for committing equivocation is associated with the strength of the protocol's security guarantees.
-
-1 second is equal to 1,000,000,000 nanoseconds.
-
-## `max_validators`
-
-**The maximum number of validators that may participate in validating blocks, earning rewards, and governance voting.**
-
-- on-chain value:
-- `cosmoshub-4` default: `125`
-- `cosmoshub-3` default: `125`
-
-Validators are ranked by stake-backing based upon the sum of their delegations, and only the top 125 are designated to be active (aka "the active set"). The active set may change any time delegation amounts change. Only active validators may participate in validating blocks, earning rewards, and governance voting. ATOM-holders may participate in staking by delegating their bonded ATOMs to one or more validators in the active set. Delegators may only earn rewards and have their governance votes count if they are delegating to an active validator, the set of which is capped by `max_validators`.
-
-#### Decreasing the value of `max_validators`
-
-Decreasing the value of the `max_validators` parameter will likely reduce the number of validators actively participating in validating blocks, earning rewards, and governance voting for the Cosmos Hub. This may decrease the time it takes to produce each new Cosmos Hub block.
-
-#### Increasing the value of `max_validators`
-
-Increasing the value of the `max_validators` parameter will likely increase the number of validators actively participating in validating blocks, earning rewards, and governance voting for the Cosmos Hub. This may increase the time it takes to produce each new Cosmos Hub block.
-
-#### Notes
-
-Prior to `cosmoshub-3`, the Cosmos Hub had a maximum set of 100 active validators. Text-based governance proposal [Prop10](https://cosmoshub-2.bigdipper.live/proposals/10) signalled agreement that the active set be increased to 125 validators. Block times were ~6.94 seconds/block with 100 validators, and are now ~7.08 seconds/block with 125 validators.
-
-It may be argued that after the Cosmos creators, the validator cohort may be the largest group of contributors to the Cosmos Hub community. Changes to the number of active validator participants may also affect the non-validator contributions to the Cosmos Hub.
-
-### `KeyMaxEntries`
-
-- **The maximum number of unbondings between a delegator and validator within the [unbonding period](#unbonding_time).**
-- **A delegator's maximum number of simultaneous redelegations from one validator to another validator within the [unbonding period](#1-unbonding_time).**
-
-- on-chain value:
-- `cosmoshub-4` default: `7`
-- `cosmoshub-3` default: `7`
-
-Each delegator has a limited number of times that they may unbond ATOM amounts from a unique validator within the [unbonding period](#unbondingtime). Each delegator also has a limited number of times that they may redelegate from one unique validator to another unique validator within the unbonding period. This limit is set by the parameter `KeyMaxEntries`, which is currently `7`. To be clear, this limit does not apply to a delegator that is redelegating from one validator to different validators.
-
-#### Decreasing the value of `KeyMaxEntries`
-
-Decreasing the value of the `KeyMaxEntries` parameter will, within the unbonding period, decrease the number of times that a delegator may unbond ATOM amounts from a single, unique validator. It will also decrease the number of redelegations a delegator may initiate between two unique validators. Since this activity across many accounts can affect the performance of the Cosmos Hub, decreasing this parameter's value decreases the likelihood of a performance reduction in the network.
-
-#### Increasing the value of `KeyMaxEntries`
-
-Increasing the value of the `KeyMaxEntries` parameter will, within the unbonding period, increase the number of times that a delegator may unbond ATOM amounts from a single, unique validator. It will also increase the number of redelegations a delegator may initiate between two unique validators. Since this activity across many accounts can affect the performance of the Cosmos Hub, increasing this parameter's value may increase the likelihood of a performance reduction in the network.
-
-### Notes
-
-Aleksandr (All in Bits; Fission Labs) wrote more about `KeyMaxEntries` [here in this article](https://blog.cosmos.network/re-delegations-in-the-cosmos-hub-7d2f5ea59f56).
-
-### `bond_denom`
-
-**The unit and denomination for the asset bonded in the system.**
-
-- on-chain value:
-- `cosmoshub-4` default: `uatom`
-- `cosmoshub-3` default: `uatom`
-
-When using an asset as a bond on the Cosmos Hub, the unit and denomination of the asset is denoted as the `uatom`, or micro-ATOM, where 1 ATOM is considered 1000000uatom. The protocol doesn't use ATOM for bonds, only uatom.
-
-#### Changing the value of `bond_denom`
-
-Changing the `bond_denom` parameter will make any bond transactions with `uatom` fail and will require the new `bond_denom` parameter string in order for bond transactions to be successful. Changing this parameter is likely to have breaking changes for applications that offer staking and delegation functionality.
-
-### `historical_entries`
-
-**The number of historical_entries to keep.**
-
-- on-chain value:
-- `cosmoshub-4` default: `10000`
-- Did not exist in `cosmoshub-3` genesis
-
-Read [ADR-17](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-017-historical-header-module.md) for more on the Historical Header Module.
diff --git a/docs/docs/governance/proposal-types/changes-archive/param-index.mdx b/docs/docs/governance/proposal-types/changes-archive/param-index.mdx
deleted file mode 100644
index 2158e310b6e..00000000000
--- a/docs/docs/governance/proposal-types/changes-archive/param-index.mdx
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: Legacy subspace parameters
-order: 1
----
-
-import { KeyValueTable } from "@site/src/js/KeyValueTable";
-import { Var } from "@site/src/js/Var";
-import { currentParams } from "@site/docs/governance/current-parameters.js";
-
-## Querying legacy on-chain parameters
-
-Given a subspace and an associated key, you can query on chain parameters using the CLI.
-
-```bash
-gaiad query params subspace --node --chain-id
-```
-
-For more information on specific modules, refer to the [Cosmos SDK documentation on modules](https://docs.cosmos.network/main/modules).
diff --git a/docs/docs/governance/proposal-types/param-change.md b/docs/docs/governance/proposal-types/param-change.md
index 12c4a8c52cc..f9b27c4bb5f 100644
--- a/docs/docs/governance/proposal-types/param-change.md
+++ b/docs/docs/governance/proposal-types/param-change.md
@@ -57,15 +57,3 @@ Because parameters dictate some of the ways in which the chain operates, changin
For example, reducing the unbonding period might seem like the only effect is in how quickly delegators can liquidate their assets. It might also have a much greater impact on the overall security of the network that would be hard to realize at first glance.
This is one of the reasons that having a thorough discussion before going on-chain is so important - talking through the impacts of a proposal is a great way to avoid unintended effects.
-
-## Credits
-
-This documentation was originally created by Gavin Birch ([Figment Networks](https://figment.io)). Its development was supported by funding approved on January 29, 2020 by the Cosmos Hub via Community Spend [Proposal 23](https://cosmoshub-3.bigdipper.live/proposals/23) ([full Proposal PDF here](https://ipfs.io/ipfs/QmSMGEoY2dfxADPfgoAsJxjjC6hwpSNx1dXAqePiCEMCbY)). In late 2021 and early 2022 significant updates were made by [Hypha Worker Co-op](https://hypha.coop/), especially @dcwalk and @lexaMichaelides. π
-
-**Special thanks** to the following for providing credible information:
-- Aleks (All in Bits; Fission Labs) for answering countless questions about these parameters
-- Alessio (All in Bits) for explaining how [`SigVerifyCostED25519`](./changes-archive/Auth.mdx#sig_verify_cost_ed25519) & [`SigVerifyCostSecp256k1`](./changes-archive/Auth.mdx#sig_verify_cost_secp256k1) work, and detailed answers to my many questions
-- Vidor for volunteering to explain [`ConstantFee`](./changes-archive//Crisis.mdx#constantfee) and answering my many questions in detail
-- Hyung (B-Harvest) for volunteering how [`InflationRateChange`](./changes-archive/Mint.mdx#inflation_rate_change) works
-- Joe (Chorus One) for explaining the security details involved with using full nodes for transactions
-- Sunny (All in Bits; Sikka) for volunteering an explanation of the purpose of [`withdrawaddrenabled`](./changes-archive/Distribution.mdx#withdrawaddrenabled)
diff --git a/docs/docs/index.md b/docs/docs/index.md
index 2a40f4985d4..b925b87f138 100644
--- a/docs/docs/index.md
+++ b/docs/docs/index.md
@@ -79,8 +79,7 @@ ator-setup).
Have questions, comments, or new ideas? Participate in the Cosmos community through one of the following channels.
-* [Cosmos Community Discord](https://discord.gg/cosmosnetwork)
-* [Cosmos Community Telegram](https://t.me/cosmosproject)
+* [Discord](https://discord.gg/interchain)
* [Cosmos Forum](https://forum.cosmos.network)
* [Cosmos on Reddit](https://reddit.com/r/cosmosnetwork)
diff --git a/docs/docs/validators/overview.mdx b/docs/docs/validators/overview.mdx
index 1984e601405..d0c08c08e98 100644
--- a/docs/docs/validators/overview.mdx
+++ b/docs/docs/validators/overview.mdx
@@ -8,13 +8,13 @@ import { currentParams } from '@site/docs/governance/current-parameters.js';
## Introduction
-The [Cosmos Hub](/validators/README.md) is based on [CometBFT](https://docs.cometbft.com/v0.34/introduction/what-is-cometbft) that relies on a set of validators that are responsible for committing new blocks in the blockchain. These validators participate in the consensus protocol by broadcasting votes that contain cryptographic signatures signed by each validator's private key.
+The Cosmos Hub is based on [CometBFT](https://docs.cometbft.com/v0.37/introduction/what-is-cometbft) that relies on a set of validators that are responsible for committing new blocks in the blockchain. These validators participate in the consensus protocol by broadcasting votes that contain cryptographic signatures signed by each validator's private key.
-Validator candidates can bond their own ATOM and have ATOM ["delegated"](/delegators/delegator-guide-cli), or staked, to them by token holders. The Cosmos Hub has validators, see Proposal , but over time the number of validators can be increased with governance proposals. The validators are determined by the total number of ATOM tokens delegated to them β the top validator candidates with the most voting power are the current Cosmos validators.
+Validator candidates can bond their own ATOM and have ATOM ["delegated"](../delegators/delegator-guide-cli.md), or staked, to them by token holders. The Cosmos Hub has validators, see Proposal , but over time the number of validators can be increased with governance proposals. The validators are determined by the total number of ATOM tokens delegated to them β the top validator candidates with the most voting power are the current Cosmos validators.
Validators and their delegators earn ATOM as block provisions and tokens as transaction fees through execution of the Tendermint consensus protocol. Note that validators can set a commission percentage on the fees their delegators receive as additional incentive. You can find an overview of all current validators and their voting power on [Mintscan](https://www.mintscan.io/cosmos/validators).
-If validators double sign or are offline for an [extended period](/validators/validator-faq#what-are-the-slashing-conditions), their staked ATOM (including ATOM of users that delegated to them) can be slashed. The penalty depends on the severity of the violation.
+If validators double sign or are offline for an [extended period](./validator-faq.md#what-are-the-slashing-conditions), their staked ATOM (including ATOM of users that delegated to them) can be slashed. The penalty depends on the severity of the violation.
## Hardware
@@ -22,11 +22,11 @@ For validator key management, validators must set up a physical operation that i
Validators are expected to equip their datacenter location with redundant power, connectivity, and storage backups. Expect to have several redundant networking boxes for fiber, firewall, and switching and then small servers with redundant hard drive and failover.
-You can find the minimum hardware requirements on the instructions for [joining the Cosmos Hub mainnet](/hub-tutorials/join-mainnet). As the network grows, bandwidth, CPU, and memory requirements rise. Large hard drives are recommended for storing years of blockchain history, as well as significant RAM to process the increasing amount of transactions.
+You can find the minimum hardware requirements on the instructions for [joining the Cosmos Hub mainnet](../hub-tutorials/join-mainnet.md). As the network grows, bandwidth, CPU, and memory requirements rise. Large hard drives are recommended for storing years of blockchain history, as well as significant RAM to process the increasing amount of transactions.
## Create a Validator Website
-To get started as a validator, create your dedicated validator website and signal your intention to become a validator in the [Cosmos Discord](https://discord.gg/cosmosnetwork). Posting your validator website is essential because delegators want to have information about the entity they are delegating their ATOM to.
+To get started as a validator, create your dedicated validator website and signal your intention to become a validator in the [Interchain Discord](https://discord.gg/interchain). Posting your validator website is essential because delegators want to have information about the entity they are delegating their ATOM to.
## Seek Legal Advice
@@ -36,5 +36,5 @@ As always, do your own research and seek legal advice if you intend to run a val
Discuss the finer details of being a validator on our community Discord and sign up for the Cosmos newsletter to get regular updates:
-* [Cosmos Developers Discord](https://discord.gg/cosmosnetwork)
+* [Discord](https://discord.gg/interchain)
* [Newsletter](https://cosmos.network/updates/signup/)
diff --git a/docs/docs/validators/validator-faq.md b/docs/docs/validators/validator-faq.md
index 3bed91ee124..9829c8a5238 100644
--- a/docs/docs/validators/validator-faq.md
+++ b/docs/docs/validators/validator-faq.md
@@ -12,7 +12,7 @@ This is work in progress. Mechanisms and values are susceptible to change.
### What is a Cosmos validator?
-The [Cosmos Hub](/getting-started/what-is-gaia) is based on [CometBFT](https://docs.cometbft.com/v0.34/introduction/what-is-cometbft) that relies on a set of validators to secure the network. The role of validators is to run a full node and participate in consensus by broadcasting votes that contain cryptographic signatures signed by the validator's private key. Validators commit new blocks in the blockchain and receive revenue in exchange for their work. Validators must also participate in governance by voting on proposals. Validators are weighted according to their total stake.
+The Cosmos Hub is based on [CometBFT](https://docs.cometbft.com/v0.37/introduction/what-is-cometbft) that relies on a set of validators to secure the network. The role of validators is to run a full node and participate in consensus by broadcasting votes that contain cryptographic signatures signed by the validator's private key. Validators commit new blocks in the blockchain and receive revenue in exchange for their work. Validators must also participate in governance by voting on proposals. Validators are weighted according to their total stake.
### What is staking?
@@ -294,7 +294,7 @@ The `ValidatorBond` message converts the full balance delegated to a validator i
A modest level of hardware specifications is initially required and rises as network use increases. Participating in the testnet is the best way to learn more. You can find the current hardware recommendations in the [Joining Mainnet documentation](../hub-tutorials/join-mainnet.md).
-Validators are recommended to set up [sentry nodes](https://docs.cometbft.com/v0.34/core/validators) to protect your validator node from DDoS attacks.
+Validators are recommended to set up [sentry nodes](https://docs.cometbft.com/v0.37/core/validators) to protect your validator node from DDoS attacks.
### What are software requirements?
@@ -327,7 +327,7 @@ Running an effective operation is key to avoiding unexpected unbonding or slashi
Validators are expected to perform regular software updates to accommodate chain upgrades and bug fixes. It is suggested to consider using [Cosmovisor](https://docs.cosmos.network/v0.45/run-node/cosmovisor.html) to partially automate this process.
-During an chain upgrade, progress is discussed in a private channel in the [Cosmos Developer Discord](https://discord.gg/cosmosnetwork). If your validator is in the active set we encourage you to request access to that channel by contacting a moderator.
+During an chain upgrade, progress is discussed in a private channel in the [Interchain Discord](https://discord.gg/cosmosnetwork). If your validator is in the active set we encourage you to request access to that channel by contacting a moderator.
### How can validators protect themselves from denial-of-service attacks?
@@ -341,4 +341,4 @@ Validator nodes are expected to connect only to full nodes they trust because th
Sentry nodes can be quickly spun up or change their IP addresses. Because the links to the sentry nodes are in private IP space, an internet-based attack cannot disturb them directly. This strategy ensures that validator block proposals and votes have a much higher chance to make it to the rest of the network.
-For more sentry node details, see the [CometBFT Documentation](https://docs.cometbft.com/v0.34/core/validators) or the [Sentry Node Architecture Overview](https://forum.cosmos.network/t/sentry-node-architecture-overview/454) on the forum.
+For more sentry node details, see the [CometBFT Documentation](https://docs.cometbft.com/v0.37/core/validators) or the [Sentry Node Architecture Overview](https://forum.cosmos.network/t/sentry-node-architecture-overview/454) on the forum.
diff --git a/docs/docs/validators/validator-setup.md b/docs/docs/validators/validator-setup.md
index d8d0f3051ad..1a8b27669f8 100644
--- a/docs/docs/validators/validator-setup.md
+++ b/docs/docs/validators/validator-setup.md
@@ -131,7 +131,7 @@ the block.
## Advanced configuration
-You can find more advanced information about running a node or a validator on the [CometBFT Core documentation](https://docs.cometbft.com/v0.34/core/validators).
+You can find more advanced information about running a node or a validator on the [CometBFT Core documentation](https://docs.cometbft.com/v0.37/core/validators).
## Common Problems
diff --git a/docs/static/img/banner.jpg b/docs/static/img/banner.jpg
index 9d8219317f7..2c3cb5cf7c9 100755
Binary files a/docs/static/img/banner.jpg and b/docs/static/img/banner.jpg differ