docs: fix typos in documentation (#8682)

* Update packet_test.go

* Update flow_test.go

* Update 06-metrics.md

* Update 07-callbacks-IBCv2.md

* Update 10-IBCv2-transfer.md

* Update 01-apps.md

* Update 00-ibcv2apps.md

* Update 00-intro.md

* Update 01-overview.md

* Update 01-overview.md

* Update 07-callbacks-IBCv2.md

* Update 10-IBCv2-transfer.md

* Update 02-developIBCv2.md

* Update 01-apps.md

* Update go-style-guide.md

---------

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

Author: viktorking7

docs/dev/go-style-guide.md

@@ -142,7 +142,7 @@ func (chain *TestChain) NextBlock() {
 ```go
 // good
 func (c *TestChain) NextBlock() {
-    // Ommitted
+    // Omitted
 ```
 
 ---

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

@@ -18,7 +18,7 @@ Communication Protocol (IBC) applications for custom use cases.
 
 Due to the modular design of the IBC protocol, IBC
 application developers do not need to concern themselves with the low-level details of clients,
-connections, and proof verification, however a brief explaination is given.  Then the document goes into detail on the abstraction layer most relevant for application
+connections, and proof verification, however a brief explanation is given. Then the document goes into detail on the abstraction layer most relevant for application
 developers (channels and ports), and describes how to define your own custom packets, and
 `IBCModule` callbacks.
 

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

@@ -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 underyling 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 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.

docs/docs/02-apps/01-transfer/10-IBCv2-transfer.md

@@ -7,7 +7,7 @@ slug: /apps/transfer/ics20-v1/ibcv2transfer
 
 # IBC v2 Transfer
 
-Much of the core business logic of sending and recieving tokens between chains is unchanged between IBC Classic and IBC v2. Some of the key differences to pay attention to are detailed below. 
+Much of the core business logic of sending and receiving tokens between chains is unchanged between IBC Classic and IBC v2. Some of the key differences to pay attention to are detailed below. 
 
 ## No Channel Handshakes, New Packet Format and Encoding Support
 
@@ -23,7 +23,7 @@ The code snippet shows the `Payload` struct.
 type Payload struct {
 	// specifies the source port of the packet, e.g. transfer
 	SourcePort string `protobuf:"bytes,1,opt,name=source_port,json=sourcePort,proto3" json:"source_port,omitempty"`
-	// specifies the destination port of the packet, e.g. trasnfer
+	// specifies the destination port of the packet, e.g. transfer
 	DestinationPort string `protobuf:"bytes,2,opt,name=destination_port,json=destinationPort,proto3" json:"destination_port,omitempty"`
 	// version of the specified application
 	Version string `protobuf:"bytes,3,opt,name=version,proto3" json:"version,omitempty"`
@@ -56,9 +56,9 @@ type FungibleTokenPacketData struct {
 
 ## Base Denoms cannot contain slashes
 
-With the new [`Denom`](https://github.com/cosmos/ibc-go/blob/main/modules/apps/transfer/types/token.pb.go#L81-L87) struct, the base denom, i.e. uatom, is seperated from the trace - the path the token has travelled. The trace is presented as an array of [`Hop`](https://github.com/cosmos/ibc-go/blob/main/modules/apps/transfer/types/token.pb.go#L136-L140)s. 
+With the new [`Denom`](https://github.com/cosmos/ibc-go/blob/main/modules/apps/transfer/types/token.pb.go#L81-L87) struct, the base denom, i.e. uatom, is separated from the trace - the path the token has travelled. The trace is presented as an array of [`Hop`](https://github.com/cosmos/ibc-go/blob/main/modules/apps/transfer/types/token.pb.go#L136-L140)s. 
 
-Because IBC v2 no longer uses channels, it is no longer possible to rely on a fixed format for an identifier so using a base denom that contains a "/" is dissallowed. 
+Because IBC v2 no longer uses channels, it is no longer possible to rely on a fixed format for an identifier so using a base denom that contains a "/" is disallowed. 
 
 ## Changes to the application module interface
 

docs/docs/04-middleware/01-callbacks/07-callbacks-IBCv2.md

@@ -15,14 +15,14 @@ Some of the interface differences are:
 
 - The callbacks middleware for IBC v2 requires the [`Underlying Application`](../01-callbacks/01-overview.md) to implement the new [`CallbacksCompatibleModuleV2`](https://github.com/cosmos/ibc-go/blob/main/modules/apps/callbacks/types/callbacks.go#L53-L58) interface. 
 - `channeltypesv2.Payload` is now used instead of `channeltypes.Packet`
-- With IBC classic, the `OnRecvPacket` callback returns the `ack`, whereas v2 returns the `recvResult` which is the [status of the packet](https://github.com/cosmos/ibc-go/blob/main/modules/core/04-channel/v2/types/packet.pb.go#L26-L38): unspecified, success, failue or asynchronous
+- With IBC classic, the `OnRecvPacket` callback returns the `ack`, whereas v2 returns the `recvResult` which is the [status of the packet](https://github.com/cosmos/ibc-go/blob/main/modules/core/04-channel/v2/types/packet.pb.go#L26-L38): unspecified, success, failure or asynchronous
 - `api.WriteAcknowledgementWrapper` is used instead of `ICS4Wrapper.WriteAcknowledgement`. It is only needed if the lower level application is going to write an asynchronous acknowledgement.
 
 ## Contract Developers
 
 The wasmd contract keeper enables cosmwasm developers to use the callbacks middleware. The [cosmwasm documentation](https://cosmwasm.cosmos.network/ibc/extensions/callbacks) provides information for contract developers. The IBC v2 callbacks implementation uses a `Payload` but reconstructs an IBC classic `Packet` to preserve the cosmwasm contract keeper interface. Additionally contracts must now handle the IBC v2 `ErrorAcknowledgement` sentinel value in the case of a failure.
 
-The callbacks middleware can be used for transfer + action workflows, for example a transfer and swap on recieve. These workflows require knowledge of the ibc denom that has been recieved. To assist with parsing the ics20 packet, [helper functions](https://github.com/cosmos/solidity-ibc-eureka/blob/a8870b023e58622fb7b3f733572c684851f8e5ee/packages/cosmwasm/ibc-callbacks-helpers/src/ics20.rs#L7-L41) can be found in the solidity-ibc-eureka repository. 
+The callbacks middleware can be used for transfer + action workflows, for example a transfer and swap on receive. These workflows require knowledge of the ibc denom that has been received. To assist with parsing the ics20 packet, [helper functions](https://github.com/cosmos/solidity-ibc-eureka/blob/a8870b023e58622fb7b3f733572c684851f8e5ee/packages/cosmwasm/ibc-callbacks-helpers/src/ics20.rs#L7-L41) can be found in the solidity-ibc-eureka repository. 
 
 ## Integration
 

docs/docs/04-middleware/02-packet-forward-middleware/01-overview.md

@@ -25,7 +25,7 @@ Packet Forward Middleware enables multi-hop token transfers by forwarding IBC pa
 The middleware can be configured to retry forwarding in the case that there was a timeout.
 - **Forwarding across multiple chains with nested memos:**
 Instructions on which route to take to forward a packet across more than one chain can be set within a nested JSON with the memo field
-- **Configurable Fee Deduction on Recieve:**
+- **Configurable Fee Deduction on Receive:**
 Integrators of PFM can choose to deduct a percentage of tokens forwarded through their chain and distribute these tokens to the community pool.
 
 ## How it works?

docs/docs/04-middleware/03-rate-limit-middleware/01-overview.md

@@ -15,13 +15,13 @@ The rate limit middleware enforces rate limits on IBC token transfers coming int
 
 - **Risk Mitigation:** In case of a bug exploit, attack or economic failure of a connected chain, it limits the impact to the in/outflow specified for a given time period. 
 - **Token Filtering:** Through the use of a blacklist, the middleware can completely block tokens entering or leaving a domain, relevant for complicance or giving asset issuers greater control over the domains token can be sent to. 
-- **Uninterupted Packet Flow:** When desired, rate limits can be bypassed by using the whitelist, to avoid any restriction on asset in or outflows. 
+- **Uninterrupted Packet Flow:** When desired, rate limits can be bypassed by using the whitelist, to avoid any restriction on asset in or outflows. 
 
 ## How it works
 
 The rate limiting middleware determines whether tokens can flow into or out of a chain. The middleware does this by: 
 
-1. Check transfer limits for an asset (Quota): When tokens are recieved or sent, the middleware determines whether the amount of tokens flowing in or out have exceeded the limit. 
+1. Check transfer limits for an asset (Quota): When tokens are received or sent, the middleware determines whether the amount of tokens flowing in or out have exceeded the limit. 
 
 2. Track in or outflow: When tokens enter or leave the chain, the amount transferred is tracked in state
 

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

@@ -19,7 +19,7 @@ Since ibc-go v10, there are two versions of the protocol in the same release: IB
 
 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/versioned_docs/version-v10.4.x/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/versioned_docs/version-v10.4.x/01-ibc/03-apps/01-apps.md

@@ -18,7 +18,7 @@ Communication Protocol (IBC) applications for custom use cases.
 
 Due to the modular design of the IBC protocol, IBC
 application developers do not need to concern themselves with the low-level details of clients,
-connections, and proof verification, however a brief explaination is given.  Then the document goes into detail on the abstraction layer most relevant for application
+connections, and proof verification, however a brief explanation is given.  Then the document goes into detail on the abstraction layer most relevant for application
 developers (channels and ports), and describes how to define your own custom packets, and
 `IBCModule` callbacks.