docs: fix typos across documentation (#8773)

* Update 02-developIBCv2.md

* Update 00-ibcv2apps.md

* Update README.md

* Update CONTRIBUTING.md

* Update project-structure.md

* Update doc.go

* Update errors.go

* Update 00-ibcv2apps.md

* Update 00-intro.md

* Update 00-intro.md

* Update go-style-guide.md

* Update 02-auth-modules.md

* Update 04-integration.md

* Update 04-integration.md

* Update 04-integration.md

* Update 04-integration.md

* Update 04-integration.md

* Update grpc_query_test.go

* Update grpc_query_test.go

* Update packet.go

* Update 02-developIBCv2.md

* Update 02-auth-modules.md

* Update 05-events.md

---------

Co-authored-by: Alex | Cosmos Labs <alex@cosmoslabs.io>

Author: anim001k

CONTRIBUTING.md

@@ -61,7 +61,7 @@ Please make sure to check out our [Pull request guidelines](./docs/dev/pull-requ
 
 #### Unwanted pull requests
 
-To ensure the core maintainers time are spent well, we have certain pull requests we want to avoid:
+To ensure the core maintainers' time is spent well, we have certain pull requests we want to avoid:
 
 - Any non-minor pull requests without an **assigned** issue
 - Any non-minor bug fixes without an issue (ideally, also assigned, but we are less strict on this)

docs/README.md

@@ -84,7 +84,7 @@ make check-docs-link
 This command will run `lychee` (if you don't have it, see the [install docs](https://lychee.cli.rs/installation/)) and check all links in `./docs/docs` (i.e. it will not check versioned docs).
 
 Since a lot of our links are to github, this command easily gets rate limited, so it has been set up with a long retry sequence for links. You may need to run it multiple times to check all links.
-The results (except rate limit responses) are cached for 1 week, so once you have run it, it will not keep checking the same links twice (this is primarly to help with rate limiting).
+The results (except rate limit responses) are cached for 1 week, so once you have run it, it will not keep checking the same links twice (this is primarily to help with rate limiting).
 
 ## Updating the Documentation
 

docs/dev/go-style-guide.md

@@ -26,7 +26,7 @@ Perhaps more key for code readability than good commenting is having the right s
 
 ## Comments
 
-- Use a space after the comment deliminter (ex. `// your comment`).
+- Use a space after the comment delimiter (ex. `// your comment`).
 - Many comments are not sentences. These should begin with a lower case letter and end without a period.
 - Conversely, sentences in comments should be sentenced-cased and end with a period.
 - Comments should explain *why* something is being done rather than *what* the code is doing. For example:
@@ -342,7 +342,7 @@ testCases := []struct {
 
 ## Known Anti Patterns
 
-It's strongly recommended [not to create a custom context](https://google.github.io/styleguide/go/decisions#custom-contexts). The Cosmos SDK has it's own context that is passed around, and we should not try to work against that pattern to avoid confusion.
+It's strongly recommended [not to create a custom context](https://google.github.io/styleguide/go/decisions#custom-contexts). The Cosmos SDK has its own context that is passed around, and we should not try to work against that pattern to avoid confusion.
 
 ---
 Test outputs should include the actual value that the function returned before printing the value that was expected. A standard format for printing test outputs is YourFunc(%v) = %v, want %v. Where you would write “actual” and “expected”, prefer using the words “got” and “want”, respectively. [Reference](https://google.github.io/styleguide/go/decisions#got-before-want)

docs/dev/project-structure.md

@@ -28,7 +28,7 @@ This folder contains implementations for the IBC TAO (`core`), IBC applications
 - `06-solomachine`: This package implements the types for the Solo Machine light client specified in [ICS 06](https://github.com/cosmos/ibc/tree/main/spec/client/ics-006-solo-machine-client).
 - `07-tendermint`: This package implements the types for the Tendermint consensus light client as specified in [ICS 07](https://github.com/cosmos/ibc/tree/main/spec/client/ics-007-tendermint-client).
 - `08-wasm`: This package implements a proxy light client module that routes requests to the actual light clients uploaded as Wasm byte code, as specified in [ICS 08](https://github.com/cosmos/ibc/tree/main/spec/client/ics-008-wasm-client).
-- `09-localhost`: This package implements a localhost loopback client with the ability to send and receive IBC packets to and from the same state machine, as specified in [ICS 09](https://github.com/cosmos/ibc/tree/main/spec/client/ics-009-loopback-cilent).
+- `09-localhost`: This package implements a localhost loopback client with the ability to send and receive IBC packets to and from the same state machine, as specified in [ICS 09](https://github.com/cosmos/ibc/tree/main/spec/client/ics-009-loopback-client).
 
 ## `proto`
 

docs/docs/00-intro.md

@@ -12,7 +12,7 @@ The Inter-Blockchain Communication Protocol (IBC) is a protocol that allows bloc
 The protocol realizes this interoperability by specifying a set of data structures, abstractions, and semantics that can be implemented by any distributed ledger that satisfies a small set of requirements.
 
 :::note Notice
-Since ibc-go v10, there are two versions of the protocol in the same release: IBC classic and IBC v2. The protocols are seperate - a connection uses either IBC classic or IBC v2
+Since ibc-go v10, there are two versions of the protocol in the same release: IBC classic and IBC v2. The protocols are separate - a connection uses either IBC classic or IBC v2
 :::
 
 ## High-level overview of IBC v2

docs/docs/01-ibc/03-apps/00-ibcv2apps.md

@@ -104,7 +104,7 @@ Modules may return to the IBC handler an acknowledgement which implements the `A
 The IBC handler will then commit this acknowledgement of the packet so that a relayer may relay the
 acknowledgement back to the sender module.
 
-The state changes that occurr during this callback could be:
+The state changes that occur during this callback could be:
 
 - the packet processing was successful as indicated by the `PacketStatus_Success` and an `Acknowledgement()` will be written
 - if the packet processing was unsuccessful as indicated by the `PacketStatus_Failure` and an `ackErr` will be written
@@ -307,7 +307,7 @@ payload := channeltypesv2.NewPayload(
 )
 ```
 
-It is also possible to define your own custom success acknowledgement which will be returned to the sender if the packet is successfully recieved and is returned in the `RecvPacketResult`. Note that if the packet processing fails, it is not possible to define a custom error acknowledgment, a constant ackErr is returned. 
+It is also possible to define your own custom success acknowledgement which will be returned to the sender if the packet is successfully received and is returned in the `RecvPacketResult`. Note that if the packet processing fails, it is not possible to define a custom error acknowledgement, a constant ackErr is returned. 
 
 ## Routing
 

docs/docs/01-ibc/04-middleware/02-developIBCv2.md

@@ -81,7 +81,7 @@ The `IBCModule` interface consists of the packet callbacks where cutom logic is
 
 ### Packet callbacks
 
-The packet callbacks are where the middleware performs most of its custom logic. The middleware may read the packet flow data and perform some additional packet handling, or it may modify the incoming data before it reaches the underlying application. This enables a wide degree of usecases, as a simple base application like token-transfer can be transformed for a variety of usecases by combining it with custom middleware, for example acting as a filter for which tokens can be sent and recieved.
+The packet callbacks are where the middleware performs most of its custom logic. The middleware may read the packet flow data and perform some additional packet handling, or it may modify the incoming data before it reaches the underlying application. This enables a wide degree of usecases, as a simple base application like token-transfer can be transformed for a variety of usecases by combining it with custom middleware, for example acting as a filter for which tokens can be sent and received.
 
 #### `OnRecvPacket`
 
@@ -182,7 +182,7 @@ See [here](https://github.com/cosmos/ibc-go/blob/main/modules/apps/callbacks/v2/
 
 ### WriteAckWrapper
 
-Middleware must also wrap the `WriteAcknowledgement` interface so that any acknowledgement written by the application passes through the middleware first. This allows middleware to modify or delay writing an acknowledgment before committed to the IBC store. 
+Middleware must also wrap the `WriteAcknowledgement` interface so that any acknowledgement written by the application passes through the middleware first. This allows middleware to modify or delay writing an acknowledgement before committed to the IBC store. 
 
 ```go
 // WithWriteAckWrapper sets the WriteAcknowledgementWrapper for the middleware.
@@ -201,7 +201,7 @@ func (im *IBCMiddleware) GetWriteAckWrapper() api.WriteAcknowledgementWrapper {
 This is where the middleware acknowledgement handling is finalised. An example is shown in the [callbacks middleware](https://github.com/cosmos/ibc-go/blob/main/modules/apps/callbacks/v2/ibc_middleware.go#L369-L454)
 
 ```go
-// WriteAcknowledgement facilitates acknowledgment being written asynchronously
+// WriteAcknowledgement facilitates acknowledgement being written asynchronously
 // The call stack flows from the IBC application to the IBC core handler
 // Thus this function is called by the IBC app or a lower-level middleware
 func (im IBCMiddleware) WriteAcknowledgement(
@@ -255,6 +255,6 @@ The middleware follows a decorator pattern that wraps an underlying application'
 
 The least intrusive middleware is stateless. They simply read the ICS26 callback arguments before calling the underlying app's callback and error if the arguments are not acceptable (e.g. whitelisting packets). Stateful middleware that are used solely for erroring are also very simple to build, an example of this would be a rate-limiting middleware that prevents transfer outflows from getting too high within a certain time frame.
 
-Middleware that directly interfere with the payload or acknowledgement before passing control to the underlying app are way more intrusive to the underlying app processing. This makes such middleware more error-prone when implementing as incorrect handling can cause the underlying app to break or worse execute unexpected behavior. Moreover, such middleware typically needs to be built for a specific underlying app rather than being generic. An example of this is the packet-forwarding middleware which modifies the payload and is specifically built for transfer.
+Middleware that directly interferes with the payload or acknowledgement before passing control to the underlying app is way more intrusive to the underlying app processing. This makes such middleware more error-prone when implementing as incorrect handling can cause the underlying app to break or worse execute unexpected behavior. Moreover, such middleware typically needs to be built for a specific underlying app rather than being generic. An example of this is the packet-forwarding middleware which modifies the payload and is specifically built for transfer.
 
-Middleware that modifies the payload or acknowledgement such that it is no longer readable by the underlying application is the most complicated middleware. Since it is not readable by the underlying apps, if these middleware write additional state into payloads and acknowledgements that get committed to IBC core provable state, there MUST be an equivalent counterparty middleware that is able to parse and intepret this additional state while also converting the payload and acknowledgment back to a readable form for the underlying application on its side. Thus, such middleware requires deployment on both sides of an IBC connection or the packet processing will break. This is the hardest type of middleware to implement, integrate and deploy. Thus, it is not recommended unless absolutely necessary to fulfill the given use case.
+Middleware that modifies the payload or acknowledgement such that it is no longer readable by the underlying application is the most complicated middleware. Since it is not readable by the underlying apps, if these middleware write additional state into payloads and acknowledgements that get committed to IBC core provable state, there MUST be an equivalent counterparty middleware that is able to parse and interpret this additional state while also converting the payload and acknowledgement back to a readable form for the underlying application on its side. Thus, such middleware requires deployment on both sides of an IBC connection or the packet processing will break. This is the hardest type of middleware to implement, integrate and deploy. Thus, it is not recommended unless absolutely necessary to fulfill the given use case.

docs/docs/02-apps/01-transfer/05-events.md

@@ -39,9 +39,9 @@ slug: /apps/transfer/ics20-v1/events
 |-----------------------|-----------------|------------------|
 | fungible_token_packet | sender          | \{sender\}       |
 | fungible_token_packet | receiver        | \{receiver\}     |
-| fungible_token_packet | denom           | \{denom\}       |
-| fungible_token_packet | denom_hash      | \{denom_hash\}  |
-| fungible_token_packet | amount          | \{amount\}      |
+| fungible_token_packet | denom           | \{denom\}        |
+| fungible_token_packet | denom_hash      | \{denom_hash\}   |
+| fungible_token_packet | amount          | \{amount\}       |
 | fungible_token_packet | memo            | \{memo\}         |
 | fungible_token_packet | acknowledgement | \{ack.String()\} |
 | fungible_token_packet | success / error | \{ack.Response\} |

docs/docs/02-apps/02-interchain-accounts/04-integration.md

@@ -146,7 +146,7 @@ func initParamsKeeper(appCodec codec.BinaryCodec, legacyAmino *codec.LegacyAmino
 }
 ```
 
-If no custom athentication module is needed and a generic Cosmos SDK authentication module can be used, then from the sample integration code above all references to `ICAAuthKeeper` and `icaAuthModule` can be removed. That's it, the following code would not be needed:
+If no custom authentication module is needed and a generic Cosmos SDK authentication module can be used, then from the sample integration code above all references to `ICAAuthKeeper` and `icaAuthModule` can be removed. That's it, the following code would not be needed:
 
 ```go
 // Create your Interchain Accounts authentication module

docs/versioned_docs/version-v10.4.x/00-intro.md

@@ -12,7 +12,7 @@ The Inter-Blockchain Communication Protocol (IBC) is a protocol that allows bloc
 The protocol realizes this interoperability by specifying a set of data structures, abstractions, and semantics that can be implemented by any distributed ledger that satisfies a small set of requirements.
 
 :::note Notice
-Since ibc-go v10, there are two versions of the protocol in the same release: IBC classic and IBC v2. The protocols are seperate - a connection uses either IBC classic or IBC v2
+Since ibc-go v10, there are two versions of the protocol in the same release: IBC classic and IBC v2. The protocols are separate - a connection uses either IBC classic or IBC v2
 :::
 
 ## High-level overview of IBC v2