docs: fix typos

docs/architecture/adr-002-go-module-versioning.md

@@ -47,7 +47,7 @@ Thus, bumping the import versioning causes the protobuf definitions to be genera
 When registering these types at compile time, the go compiler will panic.
 The generated types need to be registered against the proto codec, but there exist two definitions for the same name.
 
-The protobuf conflict policy can be overriden via the environment variable `GOLANG_PROTOBUF_REGISTRATION_CONFLICT`, but it is possible this could lead to various runtime errors or unexpected behaviour (see [here](https://github.com/protocolbuffers/protobuf-go/blob/master/reflect/protoregistry/registry.go#L46)).
+The protobuf conflict policy can be overridden via the environment variable `GOLANG_PROTOBUF_REGISTRATION_CONFLICT`, but it is possible this could lead to various runtime errors or unexpected behaviour (see [here](https://github.com/protocolbuffers/protobuf-go/blob/master/reflect/protoregistry/registry.go#L46)).
 More information [here](https://developers.google.com/protocol-buffers/docs/reference/go/faq#namespace-conflict) on namespace conflicts for protobuf versioning.
 
 ### Potential solutions

docs/architecture/adr-003-ics27-acknowledgement.md

@@ -88,7 +88,7 @@ If the `sdk.TxMsgData.Data` field is not empty then the format for v0.45 was use
 
 #### Decision
 
-Replicate the transaction response format as provided by the current SDK verison.
+Replicate the transaction response format as provided by the current SDK version.
 When the SDK version changes, adjust the transaction response format to use the updated transaction response format.
 Include the transaction response bytes in the result channel acknowledgement.
 

docs/architecture/adr-009-v6-ics27-msgserver.md

@@ -27,7 +27,7 @@ To minimize disruption to developers working on the original design of the ICS 2
 
 ### Msg server
 
-To acheive this, as stated by [@damiannolan](https://github.com/cosmos/ibc-go/issues/2026#issue-1341640594), it was proposed to:
+To achieve this, as stated by [@damiannolan](https://github.com/cosmos/ibc-go/issues/2026#issue-1341640594), it was proposed to:
 
 > Add a new `MsgServer` to `27-interchain-accounts` which exposes two distinct rpc endpoints:
 >
@@ -78,9 +78,9 @@ See issue [#2145](https://github.com/cosmos/ibc-go/issues/2145)
 ### Future considerations
 
 [ADR 008](https://github.com/cosmos/ibc-go/pull/1976) proposes the creation of a middleware which enables callers of an IBC packet send to perform application logic in conjunction with the IBC application.
-The underlying application can be removed at the availablity of such a middleware as that will be the preferred method for executing application logic upon a ICS 27 packet send.
+The underlying application can be removed at the availability of such a middleware as that will be the preferred method for executing application logic upon a ICS 27 packet send.
 
-### Miscellanous
+### Miscellaneous
 
 In order to avoid import cycles, the genesis types have been moved to their own directory.
 A new protobuf package has been created for the genesis types.

docs/architecture/adr-010-light-clients-as-sdk-modules.md

@@ -93,7 +93,7 @@ Once it is possible to route to SDK modules, a `ClientState` type could expose t
 ### Positive
 
 - use a single approach for interacting with callbacks
-- greater flexibilty and control for IBC light clients
+- greater flexibility and control for IBC light clients
 - does not require developing another routing system
 
 ### Negative

docs/architecture/adr-015-ibc-packet-receiver.md

@@ -176,7 +176,7 @@ logic, whereas application can misbehave(in terms of IBC protocol) by
 mistake.
 
 The `ProofVerificationDecorator` should come right after the default sybil attack
-resistent layer from the current `auth.NewAnteHandler`:
+resistant layer from the current `auth.NewAnteHandler`:
 
 ```go
 // add IBC ProofVerificationDecorator to the Chain of

docs/architecture/adr-025-ibc-passive-channels.md

@@ -138,4 +138,4 @@ More IBC events are exposed.
 
 ## References
 
-- The Agoric VM's IBC handler currently [accomodates `attemptChanOpenTry`](https://github.com/Agoric/agoric-sdk/blob/904b3a0423222a1b32893453e44bbde598473960/packages/cosmic-swingset/lib/ag-solo/vats/ibc.js#L546)
+- The Agoric VM's IBC handler currently [accommodates `attemptChanOpenTry`](https://github.com/Agoric/agoric-sdk/blob/904b3a0423222a1b32893453e44bbde598473960/packages/cosmic-swingset/lib/ag-solo/vats/ibc.js#L546)

docs/architecture/adr-026-ibc-client-recovery-mechanisms.md

@@ -54,11 +54,11 @@ We elect not to deal with chains which have actually halted, which is necessaril
 
     Previously, `AllowUpdateAfterExpiry` and `AllowUpdateAfterMisbehaviour` were used to signal the recovery options for an expired or frozen client, and governance proposals were not allowed to overwrite the client if these parameters were set to false. However, this has now been deprecated because a code migration can overwrite the client and consensus states regardless of the value of these parameters. If governance would vote to overwrite a client or consensus state, it is likely that governance would also be willing to perform a code migration to do the same.
 
-    In addition, `TrustingPeriod` was initally not allowed to be updated by a client upgrade proposal. However, due to the number of situations experienced in production where the `TrustingPeriod` of a client should be allowed to be updated because of ie: initial misconfiguration for a canonical channel, governance should be allowed to update this client parameter.
+    In addition, `TrustingPeriod` was initially not allowed to be updated by a client upgrade proposal. However, due to the number of situations experienced in production where the `TrustingPeriod` of a client should be allowed to be updated because of ie: initial misconfiguration for a canonical channel, governance should be allowed to update this client parameter.
 
     In versions older than ibc-go v8, `MsgRecoverClient` was a governance proposal type `ClientUpdateProposal`. It has been removed and replaced by `MsgRecoverClient` in the migration from governance v1beta1 to governance v1.
 
-    Note that this should NOT be lightly updated, as there may be a gap in time between when misbehaviour has occured and when the evidence of misbehaviour is submitted. For example, if the `UnbondingPeriod` is 2 weeks and the `TrustingPeriod` has also been set to two weeks, a validator could wait until right before `UnbondingPeriod` finishes, submit false information, then unbond and exit without being slashed for misbehaviour. Therefore, we recommend that the trusting period for the 07-tendermint client be set to 2/3 of the `UnbondingPeriod`.
+    Note that this should NOT be lightly updated, as there may be a gap in time between when misbehaviour has occurred and when the evidence of misbehaviour is submitted. For example, if the `UnbondingPeriod` is 2 weeks and the `TrustingPeriod` has also been set to two weeks, a validator could wait until right before `UnbondingPeriod` finishes, submit false information, then unbond and exit without being slashed for misbehaviour. Therefore, we recommend that the trusting period for the 07-tendermint client be set to 2/3 of the `UnbondingPeriod`.
 
 Note that clients frozen due to misbehaviour must wait for the evidence to expire to avoid becoming refrozen.
 

docs/architecture/adr-027-ibc-wasm.md

@@ -129,7 +129,7 @@ func (c *ClientState) CheckProposedHeaderAndUpdateState(context sdk.Context, mar
     return nil, nil, sdkerrors.Wrapf(ErrUnableToUnmarshalPayload, fmt.Sprintf("underlying error: %s", err.Error()))
   }
   if !output.Result.IsValid {
-    return nil, nil, fmt.Errorf("%s error ocurred while updating client state", output.Result.ErrorMsg)
+    return nil, nil, fmt.Errorf("%s error occurred while updating client state", output.Result.ErrorMsg)
   }
   output.resetImmutables(c)
   return output.NewClientState, output.NewConsensusState, nil

docs/dev/release-management.md

@@ -32,7 +32,7 @@ In order to alleviate the burden for a single person to have to cherry-pick and
 Current release is `v1.0.2`. We then maintain a (living) branch `release/v1.0.x`, given `x` as the next patch release number (currently `v1.0.3`) for the `v1.0` release series. As bugs are fixed and PRs are merged into `main`, if a contributor wishes the PR to be released into the `v1.0.x` point release, the contributor must:
 
 1. Add the `backport-to-v1.0x` label to the PR.
-2. Once the PR is merged, the Mergify GitHub application will automatically copy the changes into another branch and open a new PR agains the desired `release/v1.0.x` branch.
+2. Once the PR is merged, the Mergify GitHub application will automatically copy the changes into another branch and open a new PR against the desired `release/v1.0.x` branch.
 3. If the following has not been discussed in the original PR, then update the backport PR's description and ensure it contains the following information:
 
 - **[Impact]** explanation of how the bug affects users or developers.

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

@@ -27,7 +27,7 @@ channel, as well as how they will encode/decode it. This process is not specifie
 to each application module to determine how to implement this agreement. However, for most
 applications this will happen as a version negotiation during the channel handshake. While more
 complex version negotiation is possible to implement inside the channel opening handshake, a very
-simple version negotation is implemented in the [ibc-transfer module](https://github.com/cosmos/ibc-go/tree/main/modules/apps/transfer/module.go).
+simple version negotiation is implemented in the [ibc-transfer module](https://github.com/cosmos/ibc-go/tree/main/modules/apps/transfer/module.go).
 
 Thus, a module must define its custom packet data structure, along with a well-defined way to
 encode and decode it to and from `[]byte`.

docs/docs/02-apps/01-transfer/08-authorizations.md

@@ -18,7 +18,7 @@ It takes:
 
 - a `SourcePort` and a `SourceChannel` which together comprise the unique transfer channel identifier over which authorized funds can be transferred.
 
-- a `SpendLimit` that specifies the maximum amount of tokens the grantee can transfer. The `SpendLimit` is updated as the tokens are transfered, unless the sentinel value of the maximum value for a 256-bit unsigned integer (i.e. 2^256 - 1) is used for the amount, in which case the `SpendLimit` will not be updated (please be aware that using this sentinel value will grant the grantee the privilege to transfer **all** the tokens of a given denomination available at the granter's account). The helper function `UnboundedSpendLimit` in the `types` package of the `transfer` module provides the sentinel value that can be used. This `SpendLimit` may also be updated to increase or decrease the limit as the granter wishes.
+- a `SpendLimit` that specifies the maximum amount of tokens the grantee can transfer. The `SpendLimit` is updated as the tokens are transferred, unless the sentinel value of the maximum value for a 256-bit unsigned integer (i.e. 2^256 - 1) is used for the amount, in which case the `SpendLimit` will not be updated (please be aware that using this sentinel value will grant the grantee the privilege to transfer **all** the tokens of a given denomination available at the granter's account). The helper function `UnboundedSpendLimit` in the `types` package of the `transfer` module provides the sentinel value that can be used. This `SpendLimit` may also be updated to increase or decrease the limit as the granter wishes.
 
 - an `AllowList` list that specifies the list of addresses that are allowed to receive funds. If this list is empty, then all addresses are allowed to receive funds from the `TransferAuthorization`.
 

docs/docs/02-apps/02-interchain-accounts/02-development.md

@@ -22,7 +22,7 @@ If you wish to consume and execute custom logic in the packet callbacks, then pl
 ## Redirection to a smart contract
 
 It may be desirable to allow smart contracts to control an interchain account.
-To faciliate such an action, the controller submodule may be provided an underlying application which redirects to smart contract callers.
+To facilitate such an action, the controller submodule may be provided an underlying application which redirects to smart contract callers.
 An improved design has been suggested in [ADR 008](https://github.com/cosmos/ibc-go/pull/1976) which performs this action via middleware.
 
 Implementors of this use case are recommended to follow the ADR 008 approach.

docs/docs/02-apps/02-interchain-accounts/10-legacy/01-auth-modules.md

@@ -134,7 +134,7 @@ func (im IBCModule) OnChanCloseInit(
 }
 
 // OnRecvPacket implements the IBCModule interface. A successful acknowledgement
-// is returned if the packet data is succesfully decoded and the receive application
+// is returned if the packet data is successfully decoded and the receive application
 // logic returns without error.
 func (im IBCModule) OnRecvPacket(
   ctx sdk.Context,

docs/docs/04-middleware/01-ics29-fee/01-overview.md

@@ -35,7 +35,7 @@ To achieve the stated requirements, the **fee middleware module has two main gro
 
   This is described in the [Fee messages section](03-msgs.md).
 
-We complete the introduction by giving a list of definitions of relevant terminolgy.
+We complete the introduction by giving a list of definitions of relevant terminology.
 
 `Forward relayer`: The relayer that submits the `MsgRecvPacket` message for a given packet (on the destination chain).
 

docs/docs/04-middleware/02-callbacks/03-interfaces.md

@@ -66,7 +66,7 @@ Since middlewares do not have packet types, they do not need to implement this i
 
 ### `ContractKeeper`
 
-The callbacks middleware requires the secondary application to implement the [`ContractKeeper`](https://github.com/cosmos/ibc-go/blob/v7.3.0/modules/apps/callbacks/types/expected_keepers.go#L11-L83) interface. The contract keeper will be invoked at each step of the packet lifecycle. When a packet is sent, if callback information is provided, the contract keeper will be invoked via the `IBCSendPacketCallback`. This allows the contract keeper to prevent packet sends when callback information is provided, for example if the sender is unauthroized to perform callbacks on the given information. If the packet send is successful, the contract keeper on the destination (if present) will be invoked when a packet has been received and the acknowledgement is written, this will occur via `IBCReceivePacketCallback`. At the end of the packet lifecycle, when processing acknowledgements or timeouts, the source contract keeper will be invoked either via `IBCOnAcknowledgementPacket` or `IBCOnTimeoutPacket`. Once a packet has been sent, each step of the packet lifecycle can be processed given that a relayer sets the gas limit to be more than or equal to the required `CommitGasLimit`. State changes performed in the callback will only be committed upon successful execution.
+The callbacks middleware requires the secondary application to implement the [`ContractKeeper`](https://github.com/cosmos/ibc-go/blob/v7.3.0/modules/apps/callbacks/types/expected_keepers.go#L11-L83) interface. The contract keeper will be invoked at each step of the packet lifecycle. When a packet is sent, if callback information is provided, the contract keeper will be invoked via the `IBCSendPacketCallback`. This allows the contract keeper to prevent packet sends when callback information is provided, for example if the sender is unauthorized to perform callbacks on the given information. If the packet send is successful, the contract keeper on the destination (if present) will be invoked when a packet has been received and the acknowledgement is written, this will occur via `IBCReceivePacketCallback`. At the end of the packet lifecycle, when processing acknowledgements or timeouts, the source contract keeper will be invoked either via `IBCOnAcknowledgementPacket` or `IBCOnTimeoutPacket`. Once a packet has been sent, each step of the packet lifecycle can be processed given that a relayer sets the gas limit to be more than or equal to the required `CommitGasLimit`. State changes performed in the callback will only be committed upon successful execution.
 
 ```go
 // ContractKeeper defines the entry points exposed to the VM module which invokes a smart contract

docs/docs/05-migrations/04-v2-to-v3.md

@@ -136,7 +136,7 @@ type AnteDecorator struct {
 
 The `OnChanOpenTry` application callback has been modified.
 The return signature now includes the application version.
-IBC applications must perform application version negoitation in `OnChanOpenTry` using the counterparty version.
+IBC applications must perform application version negotiation in `OnChanOpenTry` using the counterparty version.
 The negotiated application version then must be returned in `OnChanOpenTry` to core IBC.
 Core IBC will set this version in the TRYOPEN channel.
 

docs/docs/05-migrations/07-v5-to-v6.md

@@ -97,7 +97,7 @@ app.UpgradeKeeper.SetUpgradeHandler(
 
 In previous releases of ibc-go, chain developers integrating the ICS27 interchain accounts controller functionality were expected to create a custom `Base Application` referred to as an authentication module, see the section [Building an authentication module](../02-apps/02-interchain-accounts/03-auth-modules.md) from the documentation.
 
-The `Base Application` was intended to be composed with the ICS27 controller submodule `Keeper` and faciliate many forms of message authentication depending on a chain's particular use case.
+The `Base Application` was intended to be composed with the ICS27 controller submodule `Keeper` and facilitate many forms of message authentication depending on a chain's particular use case.
 
 Prior to ibc-go v6 the controller submodule exposed only these two functions (to which we will refer as the legacy APIs):
 

docs/events/events.md

@@ -5,7 +5,7 @@ This document is unmaintained and may be out of date!
 :::
 
 The IBC module emits the following events. It can be expected that the type `message`,
-with an attirbute key of `action` will represent the first event for each message
+with an attribute key of `action` will represent the first event for each message
 being processed as emitted by the SDK's baseapp. Each IBC TAO message will
 also emit its module name in the format 'ibc_sub-modulename'.
 

docs/requirements/ics29-v1-requirements.md

@@ -103,7 +103,7 @@ See section [Definitions](https://github.com/cosmos/ibc/tree/main/spec/app/ics-0
 
 | ID  | Description | Verification | Status |
 | --- | ----------- | ------------ | ------ |
-| 5.01 | Fee distribution shall occurr on the source chain from which packets originate. | Either in [`OnAcknowledgementPacket`](https://github.com/cosmos/ibc-go/blob/v4.0.0/modules/apps/29-fee/ibc_middleware.go#L288) or in [`OnTimeoutPacket`](https://github.com/cosmos/ibc-go/blob/v4.0.0/modules/apps/29-fee/ibc_middleware.go#L330). | `Verified` |
+| 5.01 | Fee distribution shall occur on the source chain from which packets originate. | Either in [`OnAcknowledgementPacket`](https://github.com/cosmos/ibc-go/blob/v4.0.0/modules/apps/29-fee/ibc_middleware.go#L288) or in [`OnTimeoutPacket`](https://github.com/cosmos/ibc-go/blob/v4.0.0/modules/apps/29-fee/ibc_middleware.go#L330). | `Verified` |
 
 #### `OnAcknowledgementPacket`
 

docs/src/css/custom.css

@@ -1,5 +1,5 @@
 /*
-  Slighlty modified version of https://github.com/ignite/cli/blob/develop/docs/src/css/custom.css
+  Slightly modified version of https://github.com/ignite/cli/blob/develop/docs/src/css/custom.css
 */
 
 @import "tailwindcss/base";

docs/versioned_docs/version-v4.5.x/01-ibc/03-apps/05-packets_acks.md

@@ -27,7 +27,7 @@ channel, as well as how they will encode/decode it. This process is not specifie
 to each application module to determine how to implement this agreement. However, for most
 applications this will happen as a version negotiation during the channel handshake. While more
 complex version negotiation is possible to implement inside the channel opening handshake, a very
-simple version negotation is implemented in the [ibc-transfer module](https://github.com/cosmos/ibc-go/tree/main/modules/apps/transfer/module.go).
+simple version negotiation is implemented in the [ibc-transfer module](https://github.com/cosmos/ibc-go/tree/main/modules/apps/transfer/module.go).
 
 Thus, a module must define its custom packet data structure, along with a well-defined way to
 encode and decode it to and from `[]byte`.

docs/versioned_docs/version-v4.5.x/02-apps/02-interchain-accounts/02-auth-modules.md

@@ -141,7 +141,7 @@ func (im IBCModule) OnChanCloseInit(
 }
 
 // OnRecvPacket implements the IBCModule interface. A successful acknowledgement
-// is returned if the packet data is succesfully decoded and the receive application
+// is returned if the packet data is successfully decoded and the receive application
 // logic returns without error.
 func (im IBCModule) OnRecvPacket(
     ctx sdk.Context,