Fix: typos (#1822)

* Fix: typos

Fix: typos

* Fix: typos

Fix: typos

* Fix: typo

Fix: typo

* Fix: typos

Fix: typos

* Fix: typos

Fix: typos

bridges/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.
 

bridges/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.