cosmos · p-offtermatt · Dec 11, 2023 · Dec 10, 2023 · Dec 10, 2023 · Dec 10, 2023
@@ -197,7 +197,7 @@ Pull requests are merged automatically using [`A:automerge` action](https://merg
 
 ### Pull Request Templates
 
-There are three PR templates. The [default template](./.github/PULL_REQUEST_TEMPLATE.md) contains links to the three templates. Please go the the `Preview` tab and select the appropriate sub-template:
+There are three PR templates. The [default template](./.github/PULL_REQUEST_TEMPLATE.md) contains links to the three templates. Please go to the `Preview` tab and select the appropriate sub-template:
 
 - The [production template](./.github/PULL_REQUEST_TEMPLATE/production.md) is for types `fix`, `feat`, `deps`, and `refactor`. 
 - The [docs template](./.github/PULL_REQUEST_TEMPLATE/docs.md) is for documentation changes.

@@ -142,7 +142,7 @@ Once the **final release** is cut, the new changelog section must be added to ma
 ### Release Notes
 
 Release notes will be created using the `RELEASE_NOTES.md` from the release branch. 
-Once the automated releases process is completed, please add any missing information the the release notes using Github UI.
+Once the automated releases process is completed, please add any missing information the release notes using Github UI.
 
 With every release, the `goreleaser` tool will create a file with all the build artifact checksums and upload it alongside the artifacts.
 The file is called `SHA256SUMS-{{.version}}.txt` and contains the following:

@@ -10,7 +10,7 @@ Many proposals allow for long form text to be included, usually under the key `d
 
 Beware, however, that if you are using the CLI to create a proposal, and setting `description` using a flag, the text will be [escaped](https://en.wikipedia.org/wiki/Escape_sequences_in_C) which may have undesired effects. 
 
-Formating a proposal can be a trial-and-error process, which is why first submitting to the [testnet](submitting.md#submitting-your-proposal-to-the-testnet) is recommended. 
+Formatting a proposal can be a trial-and-error process, which is why first submitting to the [testnet](submitting.md#submitting-your-proposal-to-the-testnet) is recommended. 
 <!-- markdown-link-check-enable -->
 
 The examples shown below are of the text in a `json` file packaged into a `submit-proposal` transaction sent on-chain. More details about how to submit a proposal are in the [Submitting a Governance Proposal](./submitting.md) section, but for now just be aware that the examples are the contents of a file separate from the transaction. As a general rule, any flags specific to a proposal (e.g., Title, description, deposit, parameters, recipient) can be placed in a `json` file, while flags general to a transaction of any kind (e.g., chain-id, node-id, gas, fees) can remain in the CLI.
@@ -48,7 +48,7 @@ There are five (5) components:
 4. **Amount** - the amount of funding that the recipient will receive in micro-ATOMs (uatom)
 5. **Deposit** - the amount that will be contributed to the deposit (in micro-ATOMs "uatom") from the account submitting the proposal
 
-If the description says that a certain address will receive a certain number of ATOMs, it should also be programmed to do that, but it's possible that that's not the case (accidentally or otherwise). Check that the description aligns with teh 'recipient' address.
+If the description says that a certain address will receive a certain number of ATOMs, it should also be programmed to do that, but it's possible that that's not the case (accidentally or otherwise). Check that the description aligns with the 'recipient' address.
 
 ### Real example
 The `amount` is `1000000000uatom`. 1,000,000 micro-ATOM is equal to 1 ATOM, so `recipient` address `cosmos1xf2qwf6g6xvuttpf37xwrgp08qq984244952ze` will receive 1000 ATOM if this proposal is passed.

@@ -36,7 +36,7 @@ The user is paramount. For Gaia and IBC, we see the users being:
 - Nodes on hub and zones
 - Other service providers on hubs and zones (wallets, explorers, exchanges, etc.)
 
-We will also want to be tracking outreach to the relevant users per phase to ensure that Hub utility (and IBC where appropriate) are being validated. Spotlights on experiments will continue to validate the utility of the Hub and IBC (i.e. bridge to Ethereum, AMM, etc). We will also be conducting continous outbound outreach to look for partners that are aligned with the interchain mission.
+We will also want to be tracking outreach to the relevant users per phase to ensure that Hub utility (and IBC where appropriate) are being validated. Spotlights on experiments will continue to validate the utility of the Hub and IBC (i.e. bridge to Ethereum, AMM, etc). We will also be conducting continuous outbound outreach to look for partners that are aligned with the interchain mission.
 
 3. **Communications**
 

@@ -10,7 +10,7 @@ global fees `MinimumGasPricesParam` is established at the network level through
 
 
 2. `minimum-gas-prices` in `app.toml`\
-   By adjusting the `minimum-gas-prices` parameter in `app.toml`, nodes can enforce a fee that is higher than the globally defined `MinimumGasPricesParam`. However, it's importantht to note that this configuration solely determines whether transactions are eligible to enter this specific node's mempool.
+   By adjusting the `minimum-gas-prices` parameter in `app.toml`, nodes can enforce a fee that is higher than the globally defined `MinimumGasPricesParam`. However, it's important to note that this configuration solely determines whether transactions are eligible to enter this specific node's mempool.
 
     *Please note: in this context, `minimum-gas-prices` are used to refer to the local fee requirement that nodes can set in their `app.toml`, while `MinimumGasPricesParam` is a parameter in the globalfee module, which is the fee requirement at network level.*
 
@@ -32,7 +32,7 @@ Every transaction must pay per unit of gas, **at least**, in one of the denomina
 
 Requirements for the fees include:
 - fees have to be alphabetically sorted by denom
-- fees must have non-negative amount, with a valid and unique denom (i.e. no duplicate denoms are allowed)
+- fees must have a non-negative amount, with a valid and unique denom (i.e. no duplicate denoms are allowed)
 
 There are **two exceptions** from the global fees rules that allow zero fee transactions:
 
@@ -62,7 +62,7 @@ Before gaiad `v11.0.0`, `bypass-min-fee-msg-types` can be set by each node in `a
 
 - Nodes created using Gaiad `v7.0.2` - `v10.0.x` use `["/ibc.core.channel.v1.MsgRecvPacket", "/ibc.core.channel.v1.MsgAcknowledgement","/ibc.applications.transfer.v1.MsgTransfer"]` as defaults. 
 - Nodes created using Gaiad `v11.0.x` or later use `["/ibc.core.channel.v1.MsgRecvPacket", "/ibc.core.channel.v1.MsgAcknowledgement","/ibc.applications.transfer.v1.MsgTransfer", "/ibc.core.channel.v1.MsgTimeout", "/ibc.core.channel.v1.MsgTimeoutOnClose"]` as defaults. 
-- Node Nodes with `bypass-min-fee-msg-types = []` or missing this field in `app.toml` also use default bypass message types.
+- Nodes with `bypass-min-fee-msg-types = []` or missing this field in `app.toml` also use default bypass message types.
 - Nodes created using gaiad `v7.0.1` and `v7.0.0` do not have `bypass-min-fee-msg-types` configured in `config/app.toml` - they are also using same default values as in `v7.0.2`. The `bypass-min-fee-msg-types` config option can be added to `config/app.toml` before the `[telemetry]` field.
 
 An example of `bypass-min-fee-msg-types` in `app.toml`  **before** gaiad v11.0.0:
@@ -274,7 +274,7 @@ Note that the required amount of `uatom` in globalfee is overwritten by the amou
 Also, the `1stake` in minimum-gas-prices is ignored.
 
   - msgs=["/ibc.core.channel.v1.MsgRecvPacket", "/ibc.core.client.v1.MsgUpdateClient"] with paidfee="", `pass`
-  - msgs=["/ibc.core.channel.v1.MsgRecvPacket", "/ibc.core.client.v1.MsgUpdateClient"] with with paidfee="600000 * 0.05uatom", `pass`
+  - msgs=["/ibc.core.channel.v1.MsgRecvPacket", "/ibc.core.client.v1.MsgUpdateClient"] with paidfee="600000 * 0.05uatom", `pass`
   - msgs= ["/cosmos.distribution.v1beta1.MsgWithdrawDelegatorReward"] with paidfee="", `fail`
   - msgs=["/ibc.core.channel.v1.MsgRecvPacket", "/ibc.core.client.v1.MsgUpdateClient", "/cosmos.distribution.v1beta1.MsgWithdrawDelegatorReward] with paidfee="", `fail` (transaction contains non-bypass messages)
   - msgs=["/ibc.core.channel.v1.MsgRecvPacket", "/ibc.core.client.v1.MsgUpdateClient", "/cosmos.distribution.v1beta1.MsgWithdrawDelegatorReward] with paidfee="600000 * 0.2uatom", `pass`

@@ -19,4 +19,4 @@ If you would like to search explorers for previous hub data, these are some link
 - [Cosmos Hub 2](https://cosmoshub-2.bigdipper.live/)
 - [Cosmos Hub 3](https://cosmoshub-3.bigdipper.live/)
 
-If you want to makes archives available to the community, feel free to open a PR to this file and add them.
+If you want to make archives available to the community, feel free to open a PR to this file and add them.
@@ -70,7 +70,7 @@ The application state defines the initial state of the state-machine.
 
 ### Genesis Accounts
 
-In this section, initial allocation of tokens is defined. It is possible to add accounts manually by directly editing the genesis file, but it is also possible to use the following command:
+In this section, the initial allocation of tokens is defined. It is possible to add accounts manually by directly editing the genesis file, but it is also possible to use the following command:
 
 ```bash
 // Example: gaiad add-genesis-account cosmos1qs8tnw2t8l6amtzvdemnnsq9dzk0ag0z37gh3h 10000000uatom

@@ -64,7 +64,7 @@ You can also have a look at the [Ledger support page](https://support.ledger.com
 
 ## Gaia CLI + Ledger Nano
 
-**Note: You need to [install the Cosmos app](#install-the-cosmos-ledger-application) on your Ledger Nano before using following this section**
+**Note: You need to [install the Cosmos app](#install-the-cosmos-ledger-application) on your Ledger Nano before following this section**
 
 The tool used to generate addresses and transactions on the Cosmos Hub network is `gaiad`. Here is how to get started. If using a CLI tool is unfamiliar to you, scroll down and follow instructions for using the Keplr wallet instead.
 

@@ -7,7 +7,7 @@ parent:
 
 # Previous Releases
 
-The following table below, shows the the versions of the main dependencies.
+The following table below, shows the versions of the main dependencies.
 
 | Upgrade Name        | Date          | Height    | Chain Identifier | Tm      | Cosmos SDK | Gaia                     | IBC                      |
 |---------------------|---------------|-----------|---------------|------------|------------|--------------------------|--------------------------|
@@ -26,4 +26,4 @@ The following table below, shows the the versions of the main dependencies.
 | [v11](https://github.com/cosmos/gaia/releases/tag/v11.0.0)                 | 16/08/23    | 16596000 | `cosmoshub-4` | [v0.34.x](https://github.com/cometbft/cometbft/releases/tag/v0.34.29)             | [v0.45.x](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.45.16-ics) | [v11.x](https://github.com/cosmos/gaia/releases/tag/v11.0.0)                 | [v4.4.x](https://github.com/cosmos/ibc-go/releases/tag/v4.4.2)                   |
 | [v12](https://github.com/cosmos/gaia/releases/tag/v12.0.0)                 | 13/09/23    | 16985500 | `cosmoshub-4` | [v0.34.x](https://github.com/cometbft/cometbft/releases/tag/v0.34.29)             | [v0.45.x](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.45.16-ics) | [v12.x](https://github.com/cosmos/gaia/releases/tag/v12.0.0)                 | [v4.4.x](https://github.com/cosmos/ibc-go/releases/tag/v4.4.2)                   |
 | [v13](https://github.com/cosmos/gaia/releases/tag/v13.0.0)                 | 11/10/23    | 17380000 | `cosmoshub-4` | [v0.34.x](https://github.com/cometbft/cometbft/releases/tag/v0.34.29)             | [v0.45.x](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.45.16-ics-lsm) | [v13.x](https://github.com/cosmos/gaia/releases/tag/v13.0.0)                 | [v4.4.x](https://github.com/cosmos/ibc-go/releases/tag/v4.4.2)                   |
-| [v14](https://github.com/cosmos/gaia/releases/tag/v14.1.0)                 | 11/10/23    | 18262000 | `cosmoshub-4` | [v0.34.x](https://github.com/cometbft/cometbft/releases/tag/v0.34.29)             | [v0.45.x](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.45.16-ics-lsm) | [v14.x](https://github.com/cosmos/gaia/releases/tag/v14.0.0)                 | [v4.4.x](https://github.com/cosmos/ibc-go/releases/tag/v4.4.2)                   |
+| [v14](https://github.com/cosmos/gaia/releases/tag/v14.1.0)                 | 11/10/23    | 18262000 | `cosmoshub-4` | [v0.34.x](https://github.com/cometbft/cometbft/releases/tag/v0.34.29)             | [v0.45.x](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.45.16-ics-lsm) | [v14.x](https://github.com/cosmos/gaia/releases/tag/v14.0.0)                 | [v4.4.x](https://github.com/cosmos/ibc-go/releases/tag/v4.4.2)                   |
@@ -25,7 +25,7 @@ One recommended way to mitigate these risks is for validators to carefully struc
 
 Validator nodes should only connect to full-nodes they trust because they operate them themselves or are run by other validators they know socially. A validator node will typically run in a data center. Most data centers provide direct links the networks of major cloud providers. The validator can use those links to connect to sentry nodes in the cloud. This shifts the burden of denial-of-service from the validator's node directly to its sentry nodes, and may require new sentry nodes be spun up or activated to mitigate attacks on existing ones.
 
-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 attacked cannot disturb them directly. This will ensure validator block proposals and votes always make it to the rest of the network.
+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 will ensure validator block proposals and votes always make it to the rest of the network.
 
 To setup your sentry node architecture you can follow the instructions below:
 
@@ -58,4 +58,4 @@ By default, uppercase environment variables with the following prefixes will rep
 - `BC` (for democli or basecli flags)
 
 For example, the environment variable `GA_CHAIN_ID` will map to the command line flag `--chain-id`. Note that while explicit command-line flags will take precedence over environment variables, environment variables will take precedence over any of your configuration files. For this reason, it's imperative that you lock down your environment such that any critical parameters are defined as flags on the CLI or prevent modification of any environment variables.
-
+
@@ -197,7 +197,7 @@ replace (
 	// Comet
 	github.com/tendermint/tendermint => github.com/cometbft/cometbft v0.34.29
 
-	// latest grpc doesn't work with with our modified proto compiler, so we need to enforce
+	// latest grpc doesn't work with our modified proto compiler, so we need to enforce
 	// the following version across all dependencies.
 	google.golang.org/grpc => google.golang.org/grpc v1.33.2
 )
@@ -118,7 +118,7 @@ message QueryValidatorRequest {
 
 // QueryValidatorResponse is response type for the Query/Validator RPC method
 message QueryValidatorResponse {
-  // validator defines the the validator info.
+  // validator defines the validator info.
   Validator validator = 1 [(gogoproto.nullable) = false];
 }
 
@@ -288,7 +288,7 @@ message QueryDelegatorValidatorsRequest {
 // QueryDelegatorValidatorsResponse is response type for the
 // Query/DelegatorValidators RPC method.
 message QueryDelegatorValidatorsResponse {
-  // validators defines the the validators' info of a delegator.
+  // validators defines the validators' info of a delegator.
   repeated Validator validators = 1 [(gogoproto.nullable) = false];
 
   // pagination defines the pagination in the response.
@@ -311,7 +311,7 @@ message QueryDelegatorValidatorRequest {
 // QueryDelegatorValidatorResponse response type for the
 // Query/DelegatorValidator RPC method.
 message QueryDelegatorValidatorResponse {
-  // validator defines the the validator info.
+  // validator defines the validator info.
   Validator validator = 1 [(gogoproto.nullable) = false];
 }