Docs fix spelling issues

docs/architecture/adr-002-ibc-relayer.md

@@ -45,12 +45,12 @@ IBC protocol defines the minimal data set that must be made available to relayer
 #### Query Functionality
 IBC host state machines MUST expose an interface for inspecting their state. For Cosmos/Tendermint chains this means:
 - the IBC modules on chain correctly implement and respond to queries
-  - [IBC-Modules-Rust] an implementation for some queries currently exist in Cosmos-SDK and same and more need to be implemented in Rust. The full requirements are detailed in section Relayer Queries.
+  - [IBC-Modules-Rust] an implementation for some queries currently exists in Cosmos-SDK and the same and more need to be implemented in Rust. The full requirements are detailed in section Relayer Queries.
 - the relayer needs the ability to send rpc/http ABCI queries to and receive replies from Tendermint/Cosmos-SDK
   - [[ABCI Rust](https://github.com/tendermint/rust-abci)] - ABCI Rust implementation
   - [IBC-Modules-Rust] identifier validation is required (ICS-024)
   - [IBC-Modules-Rust] requires Rust types for all query responses
-  - [[Merkle-Proofs-Rust](https://github.com/confio/ics23/tree/master/rust)] (candidate implementation) - some query responses include proofs and included in IBC transactions by the relayer (some may be validated, TBD)
+  - [[Merkle-Proofs-Rust](https://github.com/confio/ics23/tree/master/rust)] (candidate implementation) - some query responses include proofs and are included in IBC transactions by the relayer (some may be validated, TBD)
 
 #### IBC Messages
 The relayer creates transactions that include IBC messages to manage clients, connections and channels, and send application packets to destination chains. These messages must be defined in the IBC Rust implementation [IBC-Modules-Rust].

docs/architecture/adr-003-handler-implementation.md

@@ -369,7 +369,7 @@ to deal with chain-specific datatypes, such as `Header`, `ClientState`, and
 To abstract over chain-specific datatypes, we introduce a trait which specifies
 both which types we need to abstract over, and their interface.
 
-For the ICS 002 Client submodule, this trait looks as follow:
+For the ICS 002 Client submodule, this trait looks as follows:
 
 ```rust
 pub trait ClientDef {
@@ -379,7 +379,7 @@ pub trait ClientDef {
 }
 ```
 
-The `ClientDef` trait specifies three datatypes, and their corresponding interface, which is provided
+The `ClientDef` trait specifies three datatypes, and their corresponding interface, which are provided
 via a trait defined in the same submodule.
 
 A production implementation of this interface would instantiate these types with the concrete
@@ -632,4 +632,4 @@ Proposed
 
 ### Neutral
 
-## References
+## References

docs/architecture/adr-004-relayer-domain-decomposition.md

@@ -91,7 +91,7 @@ Channel datagrams are built similarly. Packet datagrams are triggered by events,
 
 ### IBC Module
 
-For every a transaction in a block of height H:
+For every transaction in a block of height H:
 
 - call appropriate handler (this is realized by ICS26 routing sub-module),
 - If handler succeeds (transaction does not abort), then
@@ -236,7 +236,7 @@ fn main() -> Result<(), Box<dyn Error>> {
     let src_chain = ChainRuntime::new();
     let dst_chain = ChainRuntime::new();
 
-    /// chains expose handlers for commuicating with the chain related runtime
+    /// chains expose handlers for communicating with the chain related runtime
     /// which move into their own threads
     let src_chain_handle = src_chain.handle();
     thread::spawn(move || {

docs/architecture/adr-006-hermes-v0.2-usecases.md

@@ -80,7 +80,7 @@ connection, or reuse a connection in the creation of a new channel).
 
 #### Patterns
 
-We propose two basic patterns that Hermes should be able to fulfil.
+We propose two basic patterns that Hermes should be able to fulfill.
 
 1. Simple invocations to perform basic actions.
     - By _action_ here we mean doing the complete handshake for an object from