Chore: minor spelling and grammar fixes (cosmos#1111)

* Update README.md

Correct spelling error

* Update Rollup-Integration-guide.md

Minor grammar fix

* Update UPGRADES.md

Minor spelling fix

spec/client/Rollup-Integration-guide.md

@@ -20,7 +20,7 @@ This guide is not intended to be a formal specification or Interchain Standard.
 
 **Optimistic Rollup**: Optimistic rollups post their blocks to a data availability layer and rely on a settlement layer that can adjudicate fraud proofs submitted by rollup observers. Thus, rollup blocks are accepted "optimistically" before correctness can be guaranteed but they are only considered safe and finalized once a fraud window time period has passed without any successful challenge being submitted to the settlement layer.
 
-**ZK Rollup**: A ZK rollup has a Zero-Knowledge circuit that represents its state machine. Thus, a rollup block producer can submit a ZK-SNARK proof that the submitted app hash is indeed the correct result of applying the included transactions in the block. Thus, there is no need for a settlement layer or a fraud window. THe block can be trusted and finalized as soon as the ZK proof is verified.
+**ZK Rollup**: A ZK rollup has a Zero-Knowledge circuit that represents its state machine. Thus, a rollup block producer can submit a ZK-SNARK proof that the submitted app hash is indeed the correct result of applying the included transactions in the block. Thus, there is no need for a settlement layer or a fraud window. The block can be trusted and finalized as soon as the ZK proof is verified.
 
 ### `verifyClientMessage`
 

spec/client/ics-009-loopback-cilent/README.md

@@ -82,7 +82,7 @@ Relayers supporting localhost packet flow must be adapted to submit messages fro
 
 This would require first checking the underlying connection identifier on any channel-level messages. If the underlying connection identifier is `connection-localhost`, then the relayer must construct the message and send it back to the originating chain. The message MUST be constructed with a sentinel byte for the proof (`[]byte{0x01}`), since the loopback client does not need Merkle proofs of the state of a remote ledger; the proof height in the message may be zero, since it is ignored by the loopback client.
 
-Implementations **may** choose to implement loopback such that the next message in the handshake or packet flow is automatically called without relayer-driven transactions. However, implementors must take care to ensure that automatic message execution does not cause gas consumption issues.
+Implementations **may** choose to implement loopback such that the next message in the handshake or packet flow is automatically called without relayer-driven transactions. However, implementers must take care to ensure that automatic message execution does not cause gas consumption issues.
 
 ### Client initialisation
 

spec/core/ics-004-channel-and-packet-semantics/UPGRADES.md

@@ -374,7 +374,7 @@ function openUpgradeHandshake(
 // restoreChannel will restore the channel state to its pre-upgrade state
 // and delete upgrade auxiliary state so that upgrade is aborted.
 // it writes an error receipt to state so counterparty can restore as well.
-// NOTE: this function signature may be modified by implementors to take a custom error
+// NOTE: this function signature may be modified by implementers to take a custom error
 function restoreChannel(
   portIdentifier: Identifier,
   channelIdentifier: Identifier,