Fix: typos (#1822)

* Fix: typos

Fix: typos

* Fix: typos

Fix: typos

* Fix: typo

Fix: typo

* Fix: typos

Fix: typos

* Fix: typos

Fix: typos

docs/high-level-overview.md

@@ -35,7 +35,7 @@ about the source chain headers which have been finalized. This is useful for hig
 
 The pallet tracks current GRANDPA authorities set and only accepts finality proofs (GRANDPA justifications),
 generated by the current authorities set. The GRANDPA protocol itself requires current authorities set to
-generate explicit justificaion for the header that enacts next authorities set. Such headers and their finality
+generate explicit justification for the header that enacts next authorities set. Such headers and their finality
 proofs are called mandatory in the pallet and relayer pays no fee for such headers submission.
 
 The pallet does not require all headers to be imported or provided. The relayer itself chooses which headers
@@ -123,7 +123,7 @@ The relay connects to the source _relay_ chain and the target chain nodes. It do
 tracked parachain nodes. The relay looks at the [`Heads`](https://github.com/paritytech/polkadot/blob/1a034bd6de0e76721d19aed02a538bcef0787260/runtime/parachains/src/paras/mod.rs#L642)
 map of the [`paras` pallet](https://github.com/paritytech/polkadot/tree/1a034bd6de0e76721d19aed02a538bcef0787260/runtime/parachains/src/paras)
 in source chain, and compares the value with the best parachain head, stored in the bridge parachains pallet at
-the taget chain. If new parachain head appears at the relay chain block `B`, the relay process **waits**
+the target chain. If new parachain head appears at the relay chain block `B`, the relay process **waits**
 until header `B` or one of its ancestors appears at the target chain. Once it is available, the storage
 proof of the map entry is generated and is submitted to the target chain.
 

docs/polkadot-kusama-bridge-overview.md

@@ -21,8 +21,8 @@ The runtime will have minimal set of non-bridge pallets, so there's not much you
 ## Connecting Parachains
 
 You won't be able to directly use bridge hub transactions to send XCM messages over the bridge. Instead, you'll need
-to use other parachains transactions, which will use HRMP to deliver message to the Bridge Hub. The Bridge Hub will
-just queue this messages in its outbound lane, which is dedicated to deliver messages between two parachains.
+to use other parachains transactions, which will use HRMP to deliver messages to the Bridge Hub. The Bridge Hub will
+just queue these messages in its outbound lane, which is dedicated to deliver messages between two parachains.
 
 Our first planned bridge will connect the Polkadot' Statemint and Kusama' Statemine. Bridge between those two
 parachains would allow Statemint accounts to hold wrapped KSM tokens and Statemine accounts to hold wrapped DOT
@@ -107,7 +107,7 @@ is not used to cover rewards of bridging with some other Polkadot Parachain.
 Our goal is to incentivize running honest relayers. But we have no relayers sets, so at any time anyone may submit
 message delivery transaction, hoping that the cost of this transaction will be compensated. So what if some message is
 currently queued and two relayers are submitting two identical message delivery transactions at once? Without any
-special means, the cost of first included transacton will be compensated and the cost of the other one won't. A honest,
+special means, the cost of first included transaction will be compensated and the cost of the other one won't. A honest,
 but unlucky relayer will lose some money. In addition, we'll waste some portion of block size and weight, which
 may be used by other useful transactions.
 

modules/messages/README.md

@@ -94,7 +94,7 @@ In our Substrate-to-Substrate bridge we're using runtime storage proofs. Other b
 transaction proofs, Substrate header digests or anything else that may be proved.
 
 **IMPORTANT NOTE**: everything below in this chapter describes details of the messages module
-configuration. But if you interested in well-probed and relatively easy integration of two
+configuration. But if you're interested in well-probed and relatively easy integration of two
 Substrate-based chains, you may want to look at the
 [bridge-runtime-common](../../bin/runtime-common/) crate. This crate is providing a lot of
 helpers for integration, which may be directly used from within your runtime. Then if you'll decide
@@ -153,7 +153,7 @@ The last type is the `pallet_bridge_messages::Config::DeliveryConfirmationPaymen
 transaction is received, we call the `pay_reward()` method, passing the range of delivered messages.
 You may use the [`pallet-bridge-relayers`](../relayers/) pallet and its
 [`DeliveryConfirmationPaymentsAdapter`](../relayers/src/payment_adapter.rs) adapter as a possible
-implementation. It allows you to pay fixed reward for relaying the message and some its portion
+implementation. It allows you to pay fixed reward for relaying the message and some of its portion
 for confirming delivery.
 
 ### I have a Messages Module in my Runtime, but I Want to Reject all Outbound Messages. What shall I do?
@@ -183,7 +183,7 @@ implements all required traits and will simply reject all transactions, related
 
 ### What about other Constants in the Messages Module Configuration Trait?
 
-Two setttings that are used to check messages in the `send_message()` function. The
+Two settings that are used to check messages in the `send_message()` function. The
 `pallet_bridge_messages::Config::ActiveOutboundLanes` is an array of all message lanes, that
 may be used to send messages. All messages sent using other lanes are rejected. All messages that have
 size above `pallet_bridge_messages::Config::MaximalOutboundPayloadSize` will also be rejected.

relays/finality/README.md

@@ -19,20 +19,20 @@ More: [GRANDPA Finality Relay Sequence Diagram](../../docs/grandpa-finality-rela
 ## How to Use the Finality Relay
 
 The most important trait is the [`FinalitySyncPipeline`](./src/lib.rs), which defines the basic primitives of the
-source chain (like block hash and number) and the type of finality proof (GRANDPA jusitfication or MMR proof). Once
+source chain (like block hash and number) and the type of finality proof (GRANDPA justification or MMR proof). Once
 that is defined, there are two other traits - [`SourceClient`](./src/finality_loop.rs) and
 [`TarggetClient`](./src/finality_loop.rs).
 
-The `SourceClient` represents the Substrate node client that connects to the source chain. The client need to
+The `SourceClient` represents the Substrate node client that connects to the source chain. The client needs to
 be able to return the best finalized header number, finalized header and its finality proof and the stream of
 finality proofs.
 
 The `TargetClient` implementation must be able to craft finality delivery transaction and submit it to the target
 node. The transaction is then tracked by the relay until it is mined and finalized.
 
 The main entrypoint for the crate is the [`run` function](./src/finality_loop.rs), which takes source and target
-clients and [`FinalitySyncParams`](./src/finality_loop.rs) parameters. The most imporant parameter is the
-`only_mandatory_headers` - it it is set to `true`, the relay will only submit mandatory headers. Since transactions
+clients and [`FinalitySyncParams`](./src/finality_loop.rs) parameters. The most important parameter is the
+`only_mandatory_headers` - it is set to `true`, the relay will only submit mandatory headers. Since transactions
 with mandatory headers are fee-free, the cost of running such relay is zero (in terms of fees).
 
 ## Finality Relay Metrics
@@ -55,4 +55,4 @@ change chain names. So the metrics are:
   breaks) this shall not happen and the metric will have `0` value.
 
 If relay operates properly, you should see that the `Rialto_to_Millau_Sync_best_source_at_target_block_number`
-tries to reach the `Rialto_to_Millau_Sync_best_source_block_number`. And the latter one always increases.
+tries to reach the `Rialto_to_Millau_Sync_best_source_block_number`. And the latter one always increases.

relays/parachains/README.md

@@ -24,7 +24,7 @@ finality delivery transaction to the target node.
 
 The main entrypoint for the crate is the [`run` function](./src/parachains_loop.rs), which takes source and target
 clients and [`ParachainSyncParams`](./src/parachains_loop.rs) parameters. The most imporant parameter is the
-`parachains` - it it the set of parachains, which relay tracks and updates. The other important parameter that
+`parachains` - it is the set of parachains, which relay tracks and updates. The other important parameter that
 may affect the relay operational costs is the `strategy`. If it is set to `Any`, then the finality delivery
 transaction is submitted if at least one of tracked parachain heads is updated. The other option is `All`. Then
 the relay waits until all tracked parachain heads are updated and submits them all in a single finality delivery