docs: fix spelling errors in documentation

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/docs/00-intro.md

@@ -12,14 +12,14 @@ 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
 
 For a high level overview of IBC v2, please refer to [this blog post.](https://ibcprotocol.dev/blog/ibc-v2-announcement) For a more detailed understanding of the IBC v2 protocol, please refer to the [IBC v2 protocol specification.](https://github.com/cosmos/ibc/tree/main/spec/IBC_V2)
 
-If you are interested in using the cannonical deployment of IBC v2, connecting Cosmos chains and Ethereum, take a look at the [IBC Eureka](https://docs.skip.build/go/eureka/eureka-overview) documentation to get started.
+If you are interested in using the canonical deployment of IBC v2, connecting Cosmos chains and Ethereum, take a look at the [IBC Eureka](https://docs.skip.build/go/eureka/eureka-overview) documentation to get started.
 
 ## High-level overview of IBC Classic
 

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 acknowledgment, a constant ackErr is returned. 
 
 ## Routing
 

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

@@ -77,11 +77,11 @@ The middleware must have access to the underlying application, and be called bef
 
 > Middleware **may** choose not to call the underlying application's callback at all. Though these should generally be limited to error cases.
 
-The `IBCModule` interface consists of the packet callbacks where cutom logic is performed. 
+The `IBCModule` interface consists of the packet callbacks where custom logic is performed. 
 
 ### 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`
 
@@ -257,4 +257,4 @@ The least intrusive middleware is stateless. They simply read the ICS26 callback
 
 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 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 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.

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

docs/versioned_docs/version-v10.4.x/01-ibc/03-apps/01-apps.md

@@ -8,7 +8,7 @@ slug: /ibc/apps/apps
 # IBC Applications
 
 :::warning
-This page is relevant for IBC Classic, naviagate to the IBC v2 applications page for information on v2 apps
+This page is relevant for IBC Classic, navigate to the IBC v2 applications page for information on v2 apps
 :::
 
 Learn how to configure your application to use IBC and send data packets to other chains.

docs/versioned_docs/version-v7.8.x/03-light-clients/01-developer-guide/04-updates-and-misbehaviour.md

@@ -30,7 +30,7 @@ type ClientMessage interface {
 }
 ```
 
-The `ClientMessage` will be passed to the client to be used in [`UpdateClient`](https://github.com/cosmos/ibc-go/blob/57da75a70145409247e85365b64a4b2fc6ddad2f/modules/core/02-client/keeper/client.go#L53), which retrieves the `ClientState` by client ID (available in `MsgUpdateClient`). This `ClientState` implements the [`ClientState` interface](02-client-state.md) for its specific consenus type (e.g. Tendermint).
+The `ClientMessage` will be passed to the client to be used in [`UpdateClient`](https://github.com/cosmos/ibc-go/blob/57da75a70145409247e85365b64a4b2fc6ddad2f/modules/core/02-client/keeper/client.go#L53), which retrieves the `ClientState` by client ID (available in `MsgUpdateClient`). This `ClientState` implements the [`ClientState` interface](02-client-state.md) for its specific consensus type (e.g. Tendermint).
 
 `UpdateClient` will then handle a number of cases including misbehaviour and/or updating the consensus state, utilizing the specific methods defined in the relevant `ClientState`.
 

docs/versioned_docs/version-v8.5.x/03-light-clients/01-developer-guide/04-updates-and-misbehaviour.md

@@ -30,7 +30,7 @@ type ClientMessage interface {
 }
 ```
 
-The `ClientMessage` will be passed to the client to be used in [`UpdateClient`](https://github.com/cosmos/ibc-go/blob/v7.0.0/modules/core/02-client/keeper/client.go#L48), which retrieves the `ClientState` by client ID (available in `MsgUpdateClient`). This `ClientState` implements the [`ClientState` interface](02-client-state.md) for its specific consenus type (e.g. Tendermint).
+The `ClientMessage` will be passed to the client to be used in [`UpdateClient`](https://github.com/cosmos/ibc-go/blob/v7.0.0/modules/core/02-client/keeper/client.go#L48), which retrieves the `ClientState` by client ID (available in `MsgUpdateClient`). This `ClientState` implements the [`ClientState` interface](02-client-state.md) for its specific consensus type (e.g. Tendermint).
 
 `UpdateClient` will then handle a number of cases including misbehaviour and/or updating the consensus state, utilizing the specific methods defined in the relevant `ClientState`.
 

e2e/testsuite/codec.go

@@ -110,7 +110,7 @@ func MustProtoMarshalJSON(msg proto.Message) []byte {
 	anyResolver := codectypes.NewInterfaceRegistry()
 
 	// EmitDefaults is set to false to prevent marshalling of unpopulated fields (memo)
-	// OrigName and the anyResovler match the fields the original SDK function would expect
+	// OrigName and the anyResolver match the fields the original SDK function would expect
 	// in order to minimize changes.
 
 	// OrigName is true since there is no particular reason to use camel case