docs: fix typos (#17831)

docs/learn/advanced/00-baseapp.md

@@ -187,7 +187,7 @@ During `FinalizeBlock`, the `finalizeBlockState` is set for use during transacti
 `finalizeBlockState` is based off of the last committed state from the root store and is branched.
 Note, the `finalizeBlockState` is set to `nil` on [`Commit`](#commit).
 
-The state flow for transcation execution is nearly identical to `CheckTx` except state transitions occur on
+The state flow for transaction execution is nearly identical to `CheckTx` except state transitions occur on
 the `finalizeBlockState` and messages in a transaction are executed. Similarly to `CheckTx`, state transitions
 occur on a doubly branched state -- `finalizeBlockState`. Successful message execution results in
 writes being committed to `finalizeBlockState`. Note, if message execution fails, state transitions from
@@ -324,7 +324,7 @@ to do the following checks:
    with the transaction is superior to a minimum reference gas amount based on the raw transaction size,
    in order to avoid spam with transactions that provide 0 gas.
 
-`CheckTx` does **not** process `sdk.Msg`s -  they only need to be processed when the canonical state need to be updated, which happens during `FinalizeBlock`.
+`CheckTx` does **not** process `sdk.Msg`s -  they only need to be processed when the canonical state needs to be updated, which happens during `FinalizeBlock`.
 
 Steps 2. and 3. are performed by the [`AnteHandler`](../beginner/04-gas-fees.md#antehandler) in the [`RunTx()`](#runtx-antehandler-and-runmsgs)
 function, which `CheckTx()` calls with the `runTxModeCheck` mode. During each step of `CheckTx()`, a
@@ -410,7 +410,7 @@ First, it retrieves the `sdk.Msg`'s fully-qualified type name, by checking the `
 
 ### PostHandler
 
-`PostHandler` is similar to `AnteHandler`, but it, as the name suggests, executes custom post tx processing logic after [`RunMsgs`](#runmsgs) is called. `PostHandler` receives the `Result` of the the `RunMsgs` in order to enable this customizable behavior.
+`PostHandler` is similar to `AnteHandler`, but it, as the name suggests, executes custom post tx processing logic after [`RunMsgs`](#runmsgs) is called. `PostHandler` receives the `Result` of the `RunMsgs` in order to enable this customizable behavior.
 
 Like `AnteHandler`s, `PostHandler`s are theoretically optional.
 
@@ -528,7 +528,7 @@ Each CometBFT `query` comes with a `path`, which is a `string` which denotes wha
 
 ### ExtendVote
 
-`ExtendVote` allows an application to extend a pre-commit vote with arbitrary data. This process does NOT have be deterministic and the data returned can be unique to the validator process.
+`ExtendVote` allows an application to extend a pre-commit vote with arbitrary data. This process does NOT have to be deterministic and the data returned can be unique to the validator process.
 
 In the Cosmos-SDK this is implemented as a NoOp:
 
@@ -538,7 +538,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/baseapp/abci_utils.go#
 
 ### VerifyVoteExtension
 
-`VerifyVoteExtension` allows an application to verify that the data returned by `ExtendVote` is valid. This process does NOT have be deterministic and the data returned can be unique to the validator process.
+`VerifyVoteExtension` allows an application to verify that the data returned by `ExtendVote` is valid. This process does NOT have to be deterministic and the data returned can be unique to the validator process.
 
 In the Cosmos-SDK this is implemented as a NoOp:
 

docs/learn/advanced/01-transactions.md

@@ -98,7 +98,7 @@ create the final transaction by appending a fee. Note that the fee payer of the
 
 #### Custom Sign modes
 
-There is the the opportunity to add your own custom sign mode to the Cosmos-SDK.  While we can not accept the implementation of the sign mode to the repository, we can accept a pull request to add the custom signmode to the SignMode enum located [here](https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/proto/cosmos/tx/signing/v1beta1/signing.proto#L17)
+There is the opportunity to add your own custom sign mode to the Cosmos-SDK.  While we can not accept the implementation of the sign mode to the repository, we can accept a pull request to add the custom signmode to the SignMode enum located [here](https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/proto/cosmos/tx/signing/v1beta1/signing.proto#L17)
 
 ## Transaction Process
 
@@ -145,7 +145,7 @@ As there are currently two sign modes for signing transactions, there are also t
 * [wrapper](https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/auth/tx/builder.go#L26-L43) for creating transactions for `SIGN_MODE_DIRECT`,
 * [StdTxBuilder](https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/auth/migrations/legacytx/stdtx_builder.go#L14-L17) for `SIGN_MODE_LEGACY_AMINO_JSON`.
 
-However, the two implementation of `TxBuilder` should be hidden away from end-users, as they should prefer using the overarching `TxConfig` interface:
+However, the two implementations of `TxBuilder` should be hidden away from end-users, as they should prefer using the overarching `TxConfig` interface:
 
 ```go reference
 https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/client/tx_config.go#L24-L34

docs/learn/advanced/02-context.md

@@ -62,7 +62,7 @@ explicitly pass a context `ctx` as the first argument of a process.
 
 ## Store branching
 
-The `Context` contains a `MultiStore`, which allows for branchinig and caching functionality using `CacheMultiStore`
+The `Context` contains a `MultiStore`, which allows for branching and caching functionality using `CacheMultiStore`
 (queries in `CacheMultiStore` are cached to avoid future round trips).
 Each `KVStore` is branched in a safe and isolated ephemeral storage. Processes are free to write changes to
 the `CacheMultiStore`. If a state-transition sequence is performed without issue, the store branch can

docs/learn/advanced/04-store.md

@@ -168,7 +168,7 @@ The documentation on the IAVL Tree is located [here](https://github.com/cosmos/i
 
 ### `DbAdapter` Store
 
-`dbadapter.Store` is a adapter for `dbm.DB` making it fulfilling the `KVStore` interface.
+`dbadapter.Store` is an adapter for `dbm.DB` making it fulfilling the `KVStore` interface.
 
 ```go reference
 https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/store/dbadapter/store.go#L13-L16
@@ -269,7 +269,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/store/prefix/store.go#
 
 When `Store.{Get, Set}()` is called, the store forwards the call to its parent, with the key prefixed with the `Store.prefix`.
 
-When `Store.Iterator()` is called, it does not simply prefix the `Store.prefix`, since it does not work as intended. In that case, some of the elements are traversed even they are not starting with the prefix.
+When `Store.Iterator()` is called, it does not simply prefix the `Store.prefix`, since it does not work as intended. In that case, some of the elements are traversed even if they are not starting with the prefix.
 
 ### `ListenKv` Store
 

docs/learn/advanced/05-encoding.md

@@ -164,7 +164,7 @@ err := cdc.Unmarshal(profilebz, &myProfile)
 fmt.Printf("%T\n", myProfile.Account)                  // Prints "Any"
 fmt.Printf("%T\n", myProfile.Account.GetCachedValue()) // Prints "BaseAccount", "ContinuousVestingAccount" or whatever was initially packed in the Any.
 
-// Get the address of the accountt.
+// Get the address of the account.
 accAddr := myProfile.Account.GetCachedValue().(AccountI).GetAddress()
 ```
 
@@ -191,8 +191,8 @@ The above `Profile` example is a fictive example used for educational purposes.
 
 * the `cryptotypes.PubKey` interface for encoding different types of public keys,
 * the `sdk.Msg` interface for encoding different `Msg`s in a transaction,
-* the `AccountI` interface for encodinig different types of accounts (similar to the above example) in the x/auth query responses,
-* the `Evidencei` interface for encoding different types of evidences in the x/evidence module,
+* the `AccountI` interface for encoding different types of accounts (similar to the above example) in the x/auth query responses,
+* the `EvidenceI` interface for encoding different types of evidences in the x/evidence module,
 * the `AuthorizationI` interface for encoding different types of x/authz authorizations,
 * the [`Validator`](https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/staking/types/staking.pb.go#L340-L377) struct that contains information about a validator.
 

docs/learn/advanced/06-grpc_rest.md

@@ -94,7 +94,7 @@ Some CometBFT RPC endpoints are directly related to the Cosmos SDK:
     * `/store/{storeName}/subspace`: this will directly query the named store for key/value pairs in which the key has the value of the `data` parameter as a prefix.
     * `/p2p/filter/addr/{port}`: this will return a filtered list of the node's P2P peers by address port.
     * `/p2p/filter/id/{id}`: this will return a filtered list of the node's P2P peers by ID.
-* `/broadcast_tx_{aync,async,commit}`: these 3 endpoint will broadcast a transaction to other peers. CLI, gRPC and REST expose [a way to broadcast transations](./01-transactions.md#broadcasting-the-transaction), but they all use these 3 CometBFT RPCs under the hood.
+* `/broadcast_tx_{aync,async,commit}`: these 3 endpoints will broadcast a transaction to other peers. CLI, gRPC and REST expose [a way to broadcast transactions](./01-transactions.md#broadcasting-the-transaction), but they all use these 3 CometBFT RPCs under the hood.
 
 ## Comparison Table
 

docs/learn/advanced/07-cli.md

@@ -172,7 +172,7 @@ Flags are added to commands directly (generally in the [module's CLI file](../..
 
 ## Environment variables
 
-Each flag is bound to it's respecteve named environment variable. Then name of the environment variable consist of two parts - capital case `basename` followed by flag name of the flag. `-` must be substituted with `_`. For example flag `--home` for application with basename `GAIA` is bound to `GAIA_HOME`. It allows reducing the amount of flags typed for routine operations. For example instead of:
+Each flag is bound to its respective named environment variable. Then name of the environment variable consist of two parts - capital case `basename` followed by flag name of the flag. `-` must be substituted with `_`. For example flag `--home` for application with basename `GAIA` is bound to `GAIA_HOME`. It allows reducing the amount of flags typed for routine operations. For example instead of:
 
 ```shell
 gaia --home=./ --node=<node address> --chain-id="testchain-1" --keyring-backend=test tx ... --from=<key name>
@@ -193,7 +193,7 @@ gaia tx ... --from=<key name>
 
 ## Configurations
 
-It is vital that the root command of an application uses `PersistentPreRun()` cobra command property for executing the command, so all child commands have access to the server and client contexts. These contexts are set as their default values initially and maybe modified, scoped to the command, in their respective `PersistentPreRun()` functions. Note that the `client.Context` is typically pre-populated with "default" values that may be useful for all commands to inherit and override if necessary.
+It is vital that the root command of an application uses `PersistentPreRun()` cobra command property for executing the command, so all child commands have access to the server and client contexts. These contexts are set as their default values initially and may be modified, scoped to the command, in their respective `PersistentPreRun()` functions. Note that the `client.Context` is typically pre-populated with "default" values that may be useful for all commands to inherit and override if necessary.
 
 Here is an example of an `PersistentPreRun()` function from `simapp`:
 
@@ -206,7 +206,7 @@ The `SetCmdClientContextHandler` call reads persistent flags via `ReadPersistent
 The `InterceptConfigsPreRunHandler` call creates a viper literal, default `server.Context`, and a logger and sets that on the root command's `Context`. The `server.Context` will be modified and saved to disk. The internal `interceptConfigs` call reads or creates a CometBFT configuration based on the home path provided. In addition, `interceptConfigs` also reads and loads the application configuration, `app.toml`, and binds that to the `server.Context` viper literal. This is vital so the application can get access to not only the CLI flags, but also to the application configuration values provided by this file.
 
 :::tip
-When willing to configure which logger is used, do not to use `InterceptConfigsPreRunHandler`, which sets the default SDK logger, but instead use `InterceptConfigsAndCreateContext` and set the server context and the logger manually:
+When willing to configure which logger is used, do not use `InterceptConfigsPreRunHandler`, which sets the default SDK logger, but instead use `InterceptConfigsAndCreateContext` and set the server context and the logger manually:
 
 ```diff
 -return server.InterceptConfigsPreRunHandler(cmd, customAppTemplate, customAppConfig, customCMTConfig)