fix typos in documentation files

spec/app/ics-028-cross-chain-validation/methods.md

@@ -772,7 +772,7 @@ function InitGenesis(gs: ConsumerGenesisState): [ValidatorUpdate] {
     abortSystemUnless(gs.initialValSet == gs.providerConsensusState.validatorSet)
   }
   if gs.transferChannelId != "" {
-      // - if transferChannelId is provided, it must the ID
+      // - if transferChannelId is provided, it must be the ID
       //   of a channel connected to the "transfer" port
       channelEnd = provableStore.get("channelEnds/ports/transfer/channels/{gs.transferChannelId}")
       abortSystemUnless(channelEnd != nil)
@@ -1186,7 +1186,7 @@ function StopConsumerChain(chainId: string, lockUnbonding: Bool) {
   vscSendTimestamps.Remove((chainId, *))
 
   if !lockUnbonding {
-    // remove chainId form all outstanding unbonding operations
+    // remove chainId from all outstanding unbonding operations
     foreach id IN vscToUnbondingOps[(chainId, _)] {
       unbondingOps[id].unbondingChainIds.Remove(chainId)
       // if the unbonding operation has unbonded on all consumer chains

spec/app/ics-029-fee-payment/README.md

@@ -227,7 +227,7 @@ In this way, custom fee-handling logic can be hooked up to the IBC packet flow l
 
 #### Fee Protocol Negotiation
 
-The fee middleware will negotiate its fee protocol version with the counterparty module by including its own version next to the application version. The channel version will be a string of a JSON struct containing the fee middleware version and the application version. The application version may as well be a JSON-encoded string, possibly including further middleware and app versions, if the application stack consists of multiple milddlewares wrapping a base application.
+The fee middleware will negotiate its fee protocol version with the counterparty module by including its own version next to the application version. The channel version will be a string of a JSON struct containing the fee middleware version and the application version. The application version may as well be a JSON-encoded string, possibly including further middleware and app versions, if the application stack consists of multiple middlewares wrapping a base application.
 
 Channel Version: 
 

spec/app/ics-030-middleware/README.md

@@ -48,7 +48,7 @@ In order to function as IBC Middleware, a module must implement the IBC applicat
 
 When nesting an application, the module must make sure that it is in the middle of communication between core IBC and the application in both directions. Developers should do this by registering the top-level module directly with the IBC router (not any nested applications). The nested applications in turn, must be given access only to the middleware's `WriteAcknowledgement` and `SendPacket` rather than to the core IBC handlers directly.
 
-Additionally, the middleware must take care to ensure that the application logic can execute its own version negotiation without interference from the nesting middleware. In order to do this, the middleware will format the version in a JSON-encoded string containing the middleware version and the application version (and potentially also other custom parameter fields). The application version may as well be a JSON-encoded string, possibly including further middleware and app versions, if the application stack consists of multiple milddlewares wrapping a base application.  The format of the version string is as follows:
+Additionally, the middleware must take care to ensure that the application logic can execute its own version negotiation without interference from the nesting middleware. In order to do this, the middleware will format the version in a JSON-encoded string containing the middleware version and the application version (and potentially also other custom parameter fields). The application version may as well be a JSON-encoded string, possibly including further middleware and app versions, if the application stack consists of multiple middlewares wrapping a base application.  The format of the version string is as follows:
 
 ```json
 {

spec/core/ics-003-connection-semantics/client-validation-removal.md

@@ -8,7 +8,7 @@ Client validation was initially included in the connection handshake handlers in
 
 IBC relies on locally unique identifiers for each chain's client, connection and channel identifiers. Thus, the identifiers, connection struct and channel struct are not unique to a chain. The only thing that uniquely identifies a chain is its consensus. Specifically, the tuple of `(height, chainID, validatorSet)` is unique for an honest chain. This tuple is committed to by the headers a validator set produces. Thus, if a chain A has a client with a consensus state that is committing to a tuple uniquely identifying chain B; then chain B can be sure that the client on chain A is a client of itself. Thus any connection on chain A built on top of that client is meant to connect to chain B.
 
-The IBC connection handshake used this fact to ensure that the connection handshake only completes for the chains that are directly pointing to one another. If a relayer misconfigured the connection handshake by choosing the wrong counterparty client identifer on `ConnOpenInit`, the handshake would fail on `ConnOpenAck` when the counterparty client is proven to not be a valid client of the initializing chain. Thus, misconfigured connection attempts are blocked from completing. When a connection moves to `OPEN`, we can be sure that only the two chains in question are connected to each other.
+The IBC connection handshake used this fact to ensure that the connection handshake only completes for the chains that are directly pointing to one another. If a relayer misconfigured the connection handshake by choosing the wrong counterparty client identifier on `ConnOpenInit`, the handshake would fail on `ConnOpenAck` when the counterparty client is proven to not be a valid client of the initializing chain. Thus, misconfigured connection attempts are blocked from completing. When a connection moves to `OPEN`, we can be sure that only the two chains in question are connected to each other.
 
 Without this check, it is possible in very unlucky circumstances to have two chains that are validly connected to each other and also have misconfigured third-party chains that believe they are connected to a chain that is not connected back to them. For an example of this situation, see the attached [diagram](./client-validation-removal.png). In this case, the validly connected chains will have communication between them that follows IBC's correctness and integrity properties. However, the chains that are misconfigured may misinterpret messages sent to other chains as messages intended for them. In this case, the only connection ends that are affected are the misconfigured connection ends that do not correlate to a valid connection end on the intended counterparty. In order for this situation to arise, there would need to not only be relayer error, but also a coincidence in identifiers and handshake message timing. Thus, this is an unlikely situation to arise in practice and the only effect is invalid message processing on misconfigured connections and channel ends.
 
@@ -17,7 +17,7 @@ Without this check, it is possible in very unlucky circumstances to have two cha
 While it is beneficial that misconfigured connection attempts are blocked from completing, the client validation in the connection handshake introduced a lot of problems for the upgradability and flexibility of the protocol.
 
 - Not all chains have the ability to introspect their own consensus, specifically their own consensus history which is required to validate a counterparty's previous consensus state.
-- Explicit verification of a counterparty client state and consensus state makes adding new implementions of the same consensus difficult since the validation of any new client implementations must be supported on the counterparty you want to use it with. Thus, the structure of `ClientState` and `ConsensusState` is very difficult to change without interchain coordination.
+- Explicit verification of a counterparty client state and consensus state makes adding new implementations of the same consensus difficult since the validation of any new client implementations must be supported on the counterparty you want to use it with. Thus, the structure of `ClientState` and `ConsensusState` is very difficult to change without interchain coordination.
 - Similarly, the proofs rely on ICS24 paths for the `ClientState` and `ConsensusState`. Thus, changing the key paths to a more efficient representation is very difficult without interchain coordination.
 
 ## Social Consensus