Documentation Corrections

docs/architecture/README.md

@@ -44,5 +44,5 @@ To suggest an ADR, please make use of the [ADR template](@site/architecture/adr.
 | [011](./adr-011-transfer-total-escrow-state-entry.md) | ICS20 state entry for total amount of tokens in escrow | Accepted |
 | [015](./adr-015-ibc-packet-receiver.md) | IBC Packet Routing | Accepted |
 | [025](./adr-025-ibc-passive-channels.md) | IBC passive channels | Deprecated |
-| [026](./adr-026-ibc-client-recovery-mechanisms.md) | IBC client recovery mechansisms | Accepted |
+| [026](./adr-026-ibc-client-recovery-mechanisms.md) | IBC client recovery mechanisms | Accepted |
 | [027](./adr-027-ibc-wasm.md) | Wasm based light clients | Accepted |

docs/architecture/adr-001-coin-source-tracing.md

@@ -14,7 +14,7 @@ Accepted, Implemented
 The specification for IBC cross-chain fungible token transfers
 ([ICS20](https://github.com/cosmos/ibc/tree/master/spec/app/ics-020-fungible-token-transfer)), needs to
 be aware of the origin of any token denomination in order to relay a `Packet` which contains the sender
-and recipient addressed in the
+and recipient addresses in the
 [`FungibleTokenPacketData`](https://github.com/cosmos/ibc/tree/master/spec/app/ics-020-fungible-token-transfer#data-structures).
 
 The Packet relay sending works based in 2 cases (per

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

@@ -10,7 +10,7 @@ Accepted
 
 ## Context
 
-The IBC module was originally developed in the Cosmos SDK and released during with the Stargate release series (v0.42).
+The IBC module was originally developed in the Cosmos SDK and released during the Stargate release series (v0.42).
 It was subsequently migrated to its own repository, ibc-go.
 The first official release on ibc-go was v1.0.0.
 v1.0.0 was decided to be used instead of v0.1.0 primarily for the following reasons:
@@ -74,7 +74,7 @@ This prevents the Go module version from being incremented with breaking changes
 It also requires all extended functions to live in the same Go module, disrupting the existing code structure.
 
 The version that implements this change will still be incompatible with previous versions, but future versions could be imported together without namespace collisions.
-For example, lets say this solution is implemented in v3. Then
+For example, let's say this solution is implemented in v3. Then
 
 `github.com/cosmos/ibc-go/v2` cannot be imported with any other ibc-go version
 

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

@@ -45,7 +45,7 @@ ctx.EventManager().EmitEvents(sdk.Events{
     sdk.NewAttribute(types.AttributeKeyHops, strings.Join(connectionHops, ",")),
     sdk.NewAttribute(types.AttributeKeyOrder, order.String()),
     sdk.NewAttribute(types.AttributeKeySrcPort, portID),
-    sdk.NewAttribute(types.AttributeKeySrcChannel, chanenlID),
+    sdk.NewAttribute(types.AttributeKeySrcChannel, channelID),
     sdk.NewAttribute(types.AttributeKeySrcVersion, version),
     sdk.NewAttribute(types.AttributeKeyDstPort, counterparty.GetPortID()),
     sdk.NewAttribute(types.AttributeKeyDstChannel, counterparty.GetChannelID()),

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

@@ -48,7 +48,7 @@ We elect not to deal with chains which have actually halted, which is necessaril
 1. Add a new governance proposal with `MsgRecoverClient`.
     1. Create a new Msg with two client identifiers (`string`) and a signer.
     1. The first client identifier is the proposed client to be updated. This client must be either frozen or expired.
-    1. The second client is a substitute client. It carries all the state for the client which may be updated. It must have identitical client and chain parameters to the client which may be updated (except for latest height, frozen height, and chain-id). It should be continually updated during the voting period.
+    1. The second client is a substitute client. It carries all the state for the client which may be updated. It must have identical client and chain parameters to the client which may be updated (except for latest height, frozen height, and chain-id). It should be continually updated during the voting period.
     1. If this governance proposal passes, the client on trial will be updated to the latest state of the substitute.
     1. The signer must be the authority set for the ibc module.
 

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

@@ -11,7 +11,7 @@
 
 ## Abstract
 
-In the Cosmos SDK light clients are current hardcoded in Go. This makes upgrading existing IBC light clients or
+In the Cosmos SDK light clients are currently hardcoded in Go. This makes upgrading existing IBC light clients or
 adding support for new light client a multi step process involving on-chain governance which is time-consuming.
 
 To remedy this, we are proposing a Wasm VM to host light client bytecode, which allows easier upgrading of

docs/dev/project-structure.md

@@ -25,8 +25,8 @@ This folder contains implementations for the IBC TAO (`core`), IBC applications
 
 ### `light-clients`
 
-- `06-solomachine`: This package implement 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 implement 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).
+- `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).
 
 ## `proto`
 

docs/dev/release-management.md

@@ -31,7 +31,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.
+1. Add the `backport-to-v1.0.x` 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 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:
 

docs/requirements/channel-upgradability-requirements.md

@@ -70,7 +70,7 @@ A normal flow for upgrades:
 
 1. Governance proposal with `MsgChannelUpgradeInit` proposing to upgrade channel version to `{"fee_version":"ics29-1","app_version":"ics20-1"}` is submitted on chain A.
 2. Governance proposal passes and `MsgChannelUpgradeInit` executes successfully on chain A.
-3. Governance of chain B updates the list of allowed connections for channel upgrades, so that `channel-0` is allowed to be upgraded permissionlesly.
+3. Governance of chain B updates the list of allowed connections for channel upgrades, so that `channel-0` is allowed to be upgraded permissionlessly.
 4. Relayer submits `MsgChannelUpgradeTry` on chain B proposing to upgrade channel version to `{"fee_version":"ics29-1","app_version":"ics20-1"}`.
 5. Execution of `MsgChannelUpgradeTry` succeeds on chain B. Chain B specifies a timeout for chain A before which all packets on its side should be flushed.
 6. Relayer starts flushing in-flight packets from chain B to chain A.
@@ -113,7 +113,7 @@ The crossing hello flow for upgrades happens when a governance proposal on both
 
 Sample exception flows:
 
-- If two different relayers detect execution of `MsgChannelUpgradeInit` on both chain A and chain B and they submit `MsgChannelUpgradeTry` on the counterparty, then the handshake will finish `MsgChannelUpgradeOpen` after both chains execute `MsgChannelUpgradeAck` and all in-flight packets has been flushed (i.e. it is not needed to execute `MsgChannelUpgradeConfirm`).
+- If two different relayers detect execution of `MsgChannelUpgradeInit` on both chain A and chain B and they submit `MsgChannelUpgradeTry` on the counterparty, then the handshake will finish `MsgChannelUpgradeOpen` after both chains execute `MsgChannelUpgradeAck` and all in-flight packets have been flushed (i.e. it is not needed to execute `MsgChannelUpgradeConfirm`).
 
 # Functional requirements
 

e2e/README.md

@@ -51,8 +51,8 @@ options specified in your config file.
 | Environment Variable | Description                               | Default Value |
 |----------------------|-------------------------------------------|---------------|
 | CHAIN_IMAGE          | The image that will be used for the chain | ibc-go-simd   |
-| CHAIN_A_TAG          | The tag used for chain B                  | latest        |
-| CHAIN_B_TAG          | The tag used for chain A                  | latest        |
+| CHAIN_A_TAG          | The tag used for chain A                  | latest        |
+| CHAIN_B_TAG          | The tag used for chain B                  | latest        |
 | CHAIN_BINARY         | The binary used in the container          | simd          |
 | RELAYER_TAG          | The tag used for the relayer              | main          |
 | RELAYER_ID           | The type of relayer to use (rly/hermes)   | hermes        |