chore: polishing docs and comments (#25093)

docs/docs/build/building-apps/03-app-upgrade.md

@@ -94,7 +94,7 @@ Here is a sample code to set store migrations with an upgrade:
 
 ```go
 // this configures a no-op upgrade handler for the "my-fancy-upgrade" upgrade
-app.UpgradeKeeper.SetUpgradeHandler("my-fancy-upgrade",  func(ctx context.Context, plan upgrade.Plan) {
+app.UpgradeKeeper.SetUpgradeHandler("my-fancy-upgrade", func(ctx context.Context, plan upgrade.Plan) {
  // upgrade changes here
 })
 upgradeInfo, err := app.UpgradeKeeper.ReadUpgradeInfoFromDisk()

docs/docs/build/building-modules/01-module-manager.md

@@ -5,7 +5,7 @@ sidebar_position: 1
 # Module Manager
 
 :::note Synopsis
-Cosmos SDK modules need to implement the [`AppModule` interfaces](#application-module-interfaces), in order to be managed by the application's [module manager](#module-manager). The module manager plays an important role in [`message` and `query` routing](../../learn/advanced/00-baseapp.md#routing), and allows application developers to set the order of execution of a variety of functions like [`PreBlocker`](../../learn/beginner/00-app-anatomy.md#preblocker) and [`BeginBlocker` and `EndBlocker`](../../learn/beginner/00-app-anatomy.md#begingblocker-and-endblocker).
+Cosmos SDK modules need to implement the [`AppModule` interfaces](#application-module-interfaces), in order to be managed by the application's [module manager](#module-manager). The module manager plays an important role in [`message` and `query` routing](../../learn/advanced/00-baseapp.md#routing), and allows application developers to set the order of execution of a variety of functions like [`PreBlocker`](../../learn/beginner/00-app-anatomy.md#preblocker) and [`BeginBlocker` and `EndBlocker`](../../learn/beginner/00-app-anatomy.md#beginblocker-and-endblocker).
 :::
 
 :::note Pre-requisite Readings

docs/docs/build/building-modules/02-messages-and-queries.md

@@ -39,7 +39,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/proto/cosmos/bank/v1be
 
 ### `sdk.Msg` Interface
 
-`sdk.Msg` is a alias of `proto.Message`. 
+`sdk.Msg` is an alias of `proto.Message`. 
 
 To attach a `ValidateBasic()` method to a message then you must add methods to the type adhering to the `HasValidateBasic`.
 

docs/docs/build/building-modules/03-msg-services.md

@@ -53,7 +53,7 @@ It is recommended to implement all validation checks in a separate function that
 ```go
 ValidateMsgA(msg MsgA, now Time, gm GasMeter) error {
 	if now.Before(msg.Expire) {
-		return sdkerrrors.ErrInvalidRequest.Wrap("msg expired")
+		return sdkerrors.ErrInvalidRequest.Wrap("msg expired")
 	}
 	gm.ConsumeGas(1000, "signature verification")
 	return signatureVerification(msg.Prover, msg.Data)

docs/docs/build/building-modules/05-protobuf-annotations.md

@@ -64,7 +64,7 @@ option (cosmos_proto.implements_interface) = "cosmos.auth.v1beta1.AccountI";
 
 ## Method,Field,Message Added In
 
-`method_added_in`, `field_added_in` and `message_added_in` are annotations to denotate to clients that a field has been supported in a later version. This is useful when new methods or fields are added in later versions and that the client needs to be aware of what it can call.
+`method_added_in`, `field_added_in` and `message_added_in` are annotations to denote to clients that a field has been supported in a later version. This is useful when new methods or fields are added in later versions and that the client needs to be aware of what it can call.
 
 The annotation should be worded as follow:
 

docs/docs/learn/advanced/00-baseapp.md

@@ -469,7 +469,7 @@ When the underlying consensus engine receives a block proposal, each transaction
 Before the first transaction of a given block is processed, a [volatile state](#state-updates) called `finalizeBlockState` is initialized during FinalizeBlock. This state is updated each time a transaction is processed via `FinalizeBlock`, and committed to the [main state](#main-state) when the block is [committed](#commit), after what it is set to `nil`.
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/baseapp/baseapp.go#LL772-L807
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/baseapp/baseapp.go#L772-L807
 ```
 
 Transaction execution within `FinalizeBlock` performs the **exact same steps as `CheckTx`**, with a little caveat at step 3 and the addition of a fifth step:

docs/docs/learn/advanced/01-transactions.md

@@ -99,7 +99,7 @@ If you wish to learn more, please refer to [ADR-050](../../build/architecture/ad
 
 #### Custom Sign modes
 
-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.53.0/proto/cosmos/tx/signing/v1beta1/signing.proto#L17)
+There is an 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.53.0/proto/cosmos/tx/signing/v1beta1/signing.proto#L17)
 
 ## Transaction Process
 

docs/docs/learn/advanced/05-encoding.md

@@ -268,7 +268,7 @@ message MsgSubmitEvidence {
 }
 ```
 
-The Cosmos SDK `codec.Codec` interface provides support methods `MarshalInterface` and `UnmarshalInterface` to easy encoding of state to `Any`.
+The Cosmos SDK `codec.Codec` interface provides support methods `MarshalInterface` and `UnmarshalInterface` for easy encoding of state to `Any`.
 
 Module should register interfaces using `InterfaceRegistry` which provides a mechanism for registering interfaces: `RegisterInterface(protoName string, iface interface{}, impls ...proto.Message)` and implementations: `RegisterImplementations(iface interface{}, impls ...proto.Message)` that can be safely unpacked from Any, similarly to type registration with Amino:
 

docs/docs/learn/advanced/09-telemetry.md

@@ -9,7 +9,7 @@ Gather relevant insights about your application and modules with custom metrics
 :::
 
 The Cosmos SDK enables operators and developers to gain insight into the performance and behavior of
-their application through the use of the `telemetry` package. To enable telemetrics, set `telemetry.enabled = true` in the app.toml config file.
+their application through the use of the `telemetry` package. To enable telemetry, set `telemetry.enabled = true` in the app.toml config file.
 
 The Cosmos SDK currently supports enabling in-memory and prometheus as telemetry sinks. In-memory sink is always attached (when the telemetry is enabled) with 10 second interval and 1 minute retention. This means that metrics will be aggregated over 10 seconds, and metrics will be kept alive for 1 minute.
 

docs/docs/user/run-node/06-run-production.md

@@ -18,7 +18,7 @@ There are many different ways to secure a server and your node, the described st
 This walkthrough assumes the underlying operating system is Ubuntu. 
 :::
 
-## Sever Setup
+## Server Setup
 
 ### User