Fix spelling errors

spec/app/ics-020-fungible-token-transfer/README.md

@@ -603,7 +603,7 @@ function onAcknowledgePacket(
     } else {
       // the forwarded packet has failed, thus the funds have been refunded to the forwarding address.
       // we must revert the changes that came from successfully receiving the tokens on our chain
-      // before propogating the error acknowledgement back to original sender chain
+      // before propagating the error acknowledgement back to original sender chain
       revertInFlightChanges(packet, prevPacket)
       // write error acknowledgement
       FungibleTokenPacketAcknowledgement ack = FungibleTokenPacketAcknowledgement{false, "forwarded packet failed"}
@@ -635,7 +635,7 @@ function onTimeoutPacket(packet: Packet) {
   if prevPacket != nil {
     // the forwarded packet has failed, thus the funds have been refunded to the forwarding address.
     // we must revert the changes that came from successfully receiving the tokens on our chain
-    // before propogating the error acknowledgement back to original sender chain
+    // before propagating the error acknowledgement back to original sender chain
     revertInFlightChanges(packet, prevPacket)
     // write error acknowledgement
     FungibleTokenPacketAcknowledgement ack = FungibleTokenPacketAcknowledgement{false, "forwarded packet timed out"}

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

@@ -255,7 +255,7 @@ function onChanOpenConfirm(
 }
 ```
 
-NOTE: Middleware that does not need to negotiate with a counterparty middleware on the remote stack will not implement the version unmarshaling and negotiation, and will simply perform its own custom logic on the callbacks without relying on the counterparty behaving similarly.
+NOTE: Middleware that does not need to negotiate with a counterparty middleware on the remote stack will not implement the version unmarshalling and negotiation, and will simply perform its own custom logic on the callbacks without relying on the counterparty behaving similarly.
 
 #### Packet Callbacks
 

spec/core/ics-003-connection-semantics/README.md

@@ -573,7 +573,7 @@ function queryClientConnections(id: Identifier): Set<Identifier> {
 
 ## Backwards Compatibility
 
-In the latest specification of the connection handshake, `connOpenTry` and `connOpenAck` will no longer validate that the counterparty's clien state and consensus state is a valid client of the executing chain's consensus protocol. Thus, `clientState`, `proofClient`, `proofConsensus` and `consensusHeight` fields in the `ConnOpenTry` and `ConnOpenACk` datagrams are deprecated and will eventually be removed.
+In the latest specification of the connection handshake, `connOpenTry` and `connOpenAck` will no longer validate that the counterparty's client state and consensus state is a valid client of the executing chain's consensus protocol. Thus, `clientState`, `proofClient`, `proofConsensus` and `consensusHeight` fields in the `ConnOpenTry` and `ConnOpenACk` datagrams are deprecated and will eventually be removed.
 
 ## Forwards Compatibility
 

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

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