Corrected typos

MD/md-91/README.md

@@ -27,7 +27,7 @@ The Move Stack and Movement SDK are foundational components for Movement technol
 
 **Justification**: Categorization of Software components helps to provide consistent documentation and may aid in framing the documentation. It also provides a clear and consistent language for discussing Movement technologies.
 
-### D3: Vizualization of the Move Stack
+### D3: Visualization of the Move Stack
 
 **User Journey**: Developers can easily understand the Move Stack and its components.
 

MIP/mip-60/README.md

@@ -9,7 +9,7 @@ Cross-chain bridges allow assets to be transferred between different blockchains
 
 ## Motivation
 
-To transfer assets from Ethereum to the chain (and back), we have to employ a _bridge_. Ideally we would re-use an existing bridge, but there is no available bridge template from Ethereum to Move-based chains, so we have to design one.
+To transfer assets from Ethereum to the chain (and back), we have to employ a _bridge_. Ideally we would reuse an existing bridge, but there is no available bridge template from Ethereum to Move-based chains, so we have to design one.
 Designing a bridge between two blockchains is a complex task. As pointed out in [Bridges – Ethereum Foundation](https://ethereum.org/en/developers/docs/bridges/#integrating-bridges):
 
 > 1. **Building your own bridge** – Building a secure and reliable bridge is not easy, especially if you take a more trust-minimized route. Moreover, it requires years of experience and technical expertise related to scalability and interoperability studies. Additionally, it would require a hands-on team to maintain a bridge and attract sufficient liquidity to make it feasible.

MIP/mip-61/README.md

@@ -289,7 +289,7 @@ The BOOTSTRAP algorithm will run for both the L1 and the L2 chains. Hence we hav
 
 ```javascript
 BOOTSTRAPPING
-// Start the continuous block pocessing protocol in parrallel to this algorithm
+// Start the continuous block processing protocol in parallel to this algorithm
 START CONTINUOUS_BLOCK_PROCESSING protocol 
 SET `first_CP_block` = first processed block by CONTINUOUS_BLOCK_PROCESSING
 

MIP/mip-84/README.md

@@ -44,7 +44,7 @@ We define the following terms:
 
 - **Trusted** : A component is trusted if it is assumed to be secure and reliable. No errors in the component can occur. Nor keys can get compromised.
 - **Untrusted** : A component is untrusted if it can have bugs, or misconfigurations, or worst case gets compromised (i.e., become byzantine). The component can stop/crash or tamper with messages, results of computations. It means an entity is not assumed to be reliable, necessitating verification or safeguards.
-- **Insurance-based Untrusted** : We assume that faults or compromise is extremely unlikely. Under normal operations the component is secure and reliable. The rarity of these events permits that the operator takes care of resulting hardship. Protective measures are taken to reduce the maximally caused damage that the component can cause incase it becomes faulty / Byzantine by providing an insurance fund.
+- **Insurance-based Untrusted** : We assume that faults or compromise is extremely unlikely. Under normal operations the component is secure and reliable. The rarity of these events permits that the operator takes care of resulting hardship. Protective measures are taken to reduce the maximally caused damage that the component can cause in case it becomes faulty / Byzantine by providing an insurance fund.
 - **Approval/proof-based Untrusted** : Faults or compromise could happen frequently and at any point in time. Any action should be approved by a trusted party or require a proof of correctness.
 
 #### Soundness and Completeness