docs: remove repetitive words

applications/CoinFabrik_On_Ink_Integration_Tests_2.md

@@ -157,7 +157,7 @@ After finishing the Milestone 1: Execution and Further Analysis, we will submit
 | Number | Deliverable | Specification |
 | ----- | ----------- | ------------- |
 | 0a. | License | MIT
-| 0b. | Documentation | We will write a comprehensive report that compares the functionalities of integration tests and E2E (End-to-End) tests. This report will focus on the the functions to be implemented in this milestone, corresponding to issues 3-invoke_contract_delegate(), 4-invoke_contract(), 6-set_code_hash(), 8-caller_is_origin(),  9-code_hash(), 10-own_code_hash().<br/><br/>Our report will also document the implementation of any missing functionalities, or correct implementation differences, for the 13 functions with issues 12 through 24. For this group, we will document any additional work that was required in order to ensure consistency between integration and e2e tests.<br/><br/>If applicable, we will suggest additional tests outside of the scope of this milestone. Particularly, for functions declared outside of the env_access.rs file, but that could be related to integration or e2e testing.
+| 0b. | Documentation | We will write a comprehensive report that compares the functionalities of integration tests and E2E (End-to-End) tests. This report will focus on thefunctions to be implemented in this milestone, corresponding to issues 3-invoke_contract_delegate(), 4-invoke_contract(), 6-set_code_hash(), 8-caller_is_origin(),  9-code_hash(), 10-own_code_hash().<br/><br/>Our report will also document the implementation of any missing functionalities, or correct implementation differences, for the 13 functions with issues 12 through 24. For this group, we will document any additional work that was required in order to ensure consistency between integration and e2e tests.<br/><br/>If applicable, we will suggest additional tests outside of the scope of this milestone. Particularly, for functions declared outside of the env_access.rs file, but that could be related to integration or e2e testing.
 | 0c. | Testing and Testing Guide | The newly developed functionalities will be documented and tested following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md). A testing guide will be included. 
 | 0d. | Docker | Does not apply at this stage.
 | 0e. | Article | We will publish an updated report summary in our blog at https://blog.coinfabrik.com/.

applications/CoinFabrik_On_Ink_Integration_Tests_3.md

@@ -135,7 +135,7 @@ To address this issue, we will submit an initial report to the ink! development
 | Number | Deliverable | Specification |
 | ----- | ----------- | ------------- |
 | 0a. | License | MIT
-| 0b. | Documentation | We will write a comprehensive report that compares the functionalities of integration tests and E2E (End-to-End) tests. This report will focus on the the functions to be implemented in this milestone, corresponding to issues `3-invoke_contract_delegate()`, `4-invoke_contract()`, `6-set_code_hash()`, `8-caller_is_origin()`,  `9-code_hash()`, `10-own_code_hash()`, and `17-balance()`.<br/><br/>In the first week of this milestone, we will contact the ink! development team to provide an initial report on `14-weight_to_fee()`, documenting our efforts to identify the source of its implementation issues and seeking collaboration to assess the feasibility of resolving them. We will document any progress and implementations related to `14-weight_to_fee()` in our final milestone report.<br/><br/>We will document any additional work that was required in order to ensure consistency between integration and e2e tests.<br/><br/>If applicable, we will suggest additional tests outside of the scope of this milestone. Particularly, for functions declared outside of the `env_access.rs` file, but that could be related to integration or e2e testing.
+| 0b. | Documentation | We will write a comprehensive report that compares the functionalities of integration tests and E2E (End-to-End) tests. This report will focus on thefunctions to be implemented in this milestone, corresponding to issues `3-invoke_contract_delegate()`, `4-invoke_contract()`, `6-set_code_hash()`, `8-caller_is_origin()`,  `9-code_hash()`, `10-own_code_hash()`, and `17-balance()`.<br/><br/>In the first week of this milestone, we will contact the ink! development team to provide an initial report on `14-weight_to_fee()`, documenting our efforts to identify the source of its implementation issues and seeking collaboration to assess the feasibility of resolving them. We will document any progress and implementations related to `14-weight_to_fee()` in our final milestone report.<br/><br/>We will document any additional work that was required in order to ensure consistency between integration and e2e tests.<br/><br/>If applicable, we will suggest additional tests outside of the scope of this milestone. Particularly, for functions declared outside of the `env_access.rs` file, but that could be related to integration or e2e testing.
 | 0c. | Testing and Testing Guide | The newly developed functionalities will be documented and tested following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md). A testing guide will be included. 
 | 0d. | Docker | Does not apply at this stage.
 | 0e. | Article | We will publish an updated report summary in our blog at https://blog.coinfabrik.com/.

applications/Dante_Network.md

@@ -173,7 +173,7 @@ We’ve published a tasting version of the dev SDK for multi-chain DApp develope
 | Number | Deliverable | Specification |
 | -----: | ----------- | ------------- |
 | 0a. | License | GPLv3  |
-| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can use the the SDK of Dante smart contract developed in ink! to build their own Omnichain DApps. At this stage, the tutorial will cover how to make message communications and contract invocations between Polkadot’s smart contract parachains and other chains(like Ethereum).|
+| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can use theSDK of Dante smart contract developed in ink! to build their own Omnichain DApps. At this stage, the tutorial will cover how to make message communications and contract invocations between Polkadot’s smart contract parachains and other chains(like Ethereum).|
 | 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. |
 | 0d. | Article | We will publish an **article** that explains what was done as part of the grant. And we will publish a series of articles that explains how Dante Protocol Stack works from a high-level perspective. The content of the articles will be consistent with the functions at this stage.
 | 1. | (ink!)smart contracts: Service expression layer | Development and testing of Service expression layer on some of Polkadot’s smart contract parachains (Astar/Edgeware); Demos for communication and interoperation between one of Polkadot’s smart contract platforms and Ethereum, Near, Avalanche.|
@@ -192,7 +192,7 @@ We’ve published a tasting version of the dev SDK for multi-chain DApp develope
 | Number | Deliverable | Specification |
 | -----: | ----------- | ------------- |
 | 0a. | License | GPLv3 |
-| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can use the the SDK of Dante smart contract developed in ink! to build their own Omnichain DApps. At this stage, the tutorial will cover how to use SQoS to balance security and scalability when making multi-chain operations. |
+| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can use theSDK of Dante smart contract developed in ink! to build their own Omnichain DApps. At this stage, the tutorial will cover how to use SQoS to balance security and scalability when making multi-chain operations. |
 | 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. |
 | 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. |
 | 0e. | Article | We will publish an **article** that explains what was done as part of the grant. And we will publish a series of articles that explains how Dante Protocol Stack works from a high-level perspective. The content of the articles will be consistent with the functions at this stage.

applications/NFT_Bridge_Protocol_for_NFT_Migration_and_Data_Exchange.md

@@ -136,7 +136,7 @@ This process is NOT a fully decentralized trustless process itself in order to a
 - If after a time-limit, either of those acknowledgement are missing, the migration is reverted : the original token can be withdrawn freely by the sender, and the migrated token is burned.
 - Checked migrations need to be possible for either EVM => EVM, *=> EVM or EVM =>* migrations.
 - Checked migrations need to allow any third party to "check" the migration and publish a standardized signed message that the migration did indeed happen.
-- NB : This only cover the migration of NFTs to a new universe, not the redemption of the the NFT back to it's origin universe.
+- NB : This only cover the migration of NFTs to a new universe, not the redemption of theNFT back to it's origin universe.
 - Licensed under the [Unlicense](https://unlicense.org)
 
 *The main purpose of this migration process is for NFT publishers to allow their users to effortlessly migrate their tokens with the least amount of efforts required. NFT publishers could offer users to do the whole migration with a single gas spending approve() from an NFT owner and the rest trough meta-transactions by the publisher. The publisher would then sign the migration as properly done after having minted and transferred the token on the destination blockchain. By essence, most NFTs are not trustless assets as their publishers own real world IP rights to them, and it is hence acceptable to use said publishers as relayers. This is standardizing a process that would otherwise require the publisher to update their original NFT smart contracts or NFT owners to burn their original NFT token in order to get a new one minted on the destination universe.*
@@ -155,7 +155,7 @@ We will write up the ‘Trustless Migration’ process which is designed to be u
 
 - Snowfork is already building a substrate module allowing specifically for Ethereum Smart contract reading. If a Substrate-built parachain implement those reading capacities, then implementation of this process should be straightforward.
 - In the case of EVM => EVM ERC-721 migration without trustless reading, Chainbridge already exist. However, their contracts requires administrator input for new contract registration as well as lacking features that are NFT specific, such as preventing minting technically correct but legally counterfeit tokens.
-- NB : This only cover the migration of NFTs to a new universe, not the redemption of the the NFT back to it's origin universe.
+- NB : This only cover the migration of NFTs to a new universe, not the redemption of theNFT back to it's origin universe.
 - Licensed under the [Unlicense](https://unlicense.org)
 
 ### Milestone 4 — Standard and Documentation for Cross-universe Migration

applications/RainbowDAO Protocol ink Phase 1.md

@@ -284,7 +284,7 @@ The following are the details of the : RainbowDao protocol:
 
    - #####  3.DAO User Management System
 
-    It’s about the the member management of the entire RainbowDAO protocol. This management pattern can be employed in all independent DAOs, they can choose one or more parts of the system and they can combine these parts for their own use. Currently, there’re merely some simple functions there. We will develop more sophisticated ones based on the reality of RainbowDAO protocol. 
+    It’s about themember management of the entire RainbowDAO protocol. This management pattern can be employed in all independent DAOs, they can choose one or more parts of the system and they can combine these parts for their own use. Currently, there’re merely some simple functions there. We will develop more sophisticated ones based on the reality of RainbowDAO protocol. 
 
    - #####  4.DCV Management System
 

applications/Subsembly-GRANDPA.md

@@ -112,7 +112,7 @@ The team already spend time on implementing GRANDPA, by updating the Subsembly C
 
 ## Development Roadmap :nut_and_bolt:
 
-Described below is a practical approach to the implementation of the GRANDPA module along with the the other auxiliary modules that are required.
+Described below is a practical approach to the implementation of the GRANDPA module along with theother auxiliary modules that are required.
 
 1. Session
     1. Implement session period configuration (`n` number of blocks)

applications/Syncra.md

@@ -79,7 +79,7 @@ Known drawbacks are the security concerns, related with storing private keys on
 
 ### Data Model
 
-Syncra uses IPFS as well as MongoDB for storing additional data about DAOs, proposals, and user stats. The purpose is to minimise the data footprint on the blockchain itself, as storing data onchain is costly, and not very performant. Only the critical data is stored inside of the the DAO Smart Contract’s. 
+Syncra uses IPFS as well as MongoDB for storing additional data about DAOs, proposals, and user stats. The purpose is to minimise the data footprint on the blockchain itself, as storing data onchain is costly, and not very performant. Only the critical data is stored inside of theDAO Smart Contract’s. 
 
 DAOs, Proposals titles, and descriptions are stored on the IPFS, and then corresponding IPFS hashes are set on the DAO contract's storage. In this way, users can be sure that the data about the given DAO or Proposal won’t be modified, nor fade-away if the server ever goes down. The same applies to storing images, as we use web3 storage for image upload.
 

applications/Tellor.md

@@ -202,7 +202,7 @@ Details:  A new Substrate pallet will be required which includes the core oracle
 | **0c.** | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. |
 | **0d.** | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. |
 | 1 | Substrate Oracle pallet design and integration | We will provide the Substrate oracle pallet |
-| 2 | Tests and a guide for testing functionallity of the the pallet with integration of a mock project on selected parachains| We will provide tests and a guide to test cross functionality of the system for interactions between the EVM chain and consumer chain and oracle pallet (meaning test the functinallity between milestone 1 and 2 delivarable 1 -  solidity contracts, pallet, XCM)|
+| 2 | Tests and a guide for testing functionallity of thepallet with integration of a mock project on selected parachains| We will provide tests and a guide to test cross functionality of the system for interactions between the EVM chain and consumer chain and oracle pallet (meaning test the functinallity between milestone 1 and 2 delivarable 1 -  solidity contracts, pallet, XCM)|
 | 3 | Documentation/ Usage Examples| We will provide documenatation and usage examples for the system.                                                                                               |