docs: fix typo (#2049)

docs/RFPs/a-and-v-topology.md

@@ -9,9 +9,9 @@ This Request for Proposals is _closed_, meaning we are not looking for any more
 
 ## Project Description :page_facing_up:
 
-A part of the promise of Polkadot is to bring scalability to the blockchains. The way it achieves it is via delegating application-specific logic from layer 0 (the relay chain) to layer 1 chains (parachains). In order to achieve this efficiently yet securely, each parachain has its own block production mechanism (achieving efficienct block production), but the finalisation of candidate parachain blocks still happens with the involvement of the relay chain validators.
+A part of the promise of Polkadot is to bring scalability to the blockchains. The way it achieves it is via delegating application-specific logic from layer 0 (the relay chain) to layer 1 chains (parachains). In order to achieve this efficiently yet securely, each parachain has its own block production mechanism (achieving efficient block production), but the finalisation of candidate parachain blocks still happens with the involvement of the relay chain validators.
 
-The full mechanism is described in [the host specification](https://spec.polkadot.network/chapter-anv). In short, it is split into two parts: first, a publicly known subset of validators attests that the parachain block data is available to them (i.e., they must have it in their local storage); second, once 2/3+ of the first group have published their availability votes, a "secret" (VRF-based assignment) subset of validators checks the validitiy of the candidate, by checking its state transition against that parachain runtime, which is available on-(the relay)chain.
+The full mechanism is described in [the host specification](https://spec.polkadot.network/chapter-anv). In short, it is split into two parts: first, a publicly known subset of validators attests that the parachain block data is available to them (i.e., they must have it in their local storage); second, once 2/3+ of the first group have published their availability votes, a "secret" (VRF-based assignment) subset of validators checks the validity of the candidate, by checking its state transition against that parachain runtime, which is available on-(the relay)chain.
 
 Currently, the gossip network among the relay chain validators does not make use of the public assignment of a the first subgroup of validators to a particular parachain. Instead, the candidate block is passed around the network until it reaches 2/3+ of approvals, causing an additional delay in the process of finalization of the candidate.
 

docs/RFPs/epassport-zk-validation.md

@@ -52,6 +52,6 @@ Later, the proof is uploaded on-chain, and the chain logic performs verification
 * **Estimated Duration:** 1 month
 * **Costs:** 20,000 kUSD
 
-The Master List is expected to, albeit unfrequently, receive updates as new countries join the PKD or as they update their certificates periodically. Furhtermore, countries are expected to publish the revocations of any compromised certificates.
+The Master List is expected to, albeit unfrequently, receive updates as new countries join the PKD or as they update their certificates periodically. Furthermore, countries are expected to publish the revocations of any compromised certificates.
 
 It is important that both prover and verifier circuits are updated accordingly - else the proof won't match.

docs/RFPs/identity-directory.md

@@ -51,7 +51,7 @@ The individual events and positions in the various columns should be **linkable*
 #### Default Plugins
 
 - `basic info`: a column with basic information about an account, similar to the sidebar on Polkadot JS Apps UI. Should discern between registrars - it should list each registrar who verified this identity and the verification level they gave (i.e. KnownGood vs KnownBad etc.)
-- `governance`: a column listing all of an account's governance activity like votes, proposals, marking the times when the account was a council member, etc. It should resemble a vertical timeline, with related events referencing each other, quoted-tweet style. Events should be linkable as decribed above, i.e. `governance@477723`. The column should **clearly** mark when a user was a council member but failed to uphold their duties, i.e. there was a motion but the user did not vote, and other interesting info (i.e. the user did not do ANYTHING the council can do while being a council member).
+- `governance`: a column listing all of an account's governance activity like votes, proposals, marking the times when the account was a council member, etc. It should resemble a vertical timeline, with related events referencing each other, quoted-tweet style. Events should be linkable as described above, i.e. `governance@477723`. The column should **clearly** mark when a user was a council member but failed to uphold their duties, i.e. there was a motion but the user did not vote, and other interesting info (i.e. the user did not do ANYTHING the council can do while being a council member).
 - `treasury`: a history of an account's interactions with the treasury - tip proposals and endorsements, treasury proposals and grant wins, votes on TP motions if user was council at the time (and clear marks if the user FAILED to vote on a TP motion during his activity as councilor).
 - `validator`: showing the history/summary of the account's participation in securing the network
 #### Optional Plugins

docs/RFPs/ksm-tipping-button.md

@@ -23,7 +23,7 @@ The tip begins its closing process (a countdown) when more than a half of counci
 
 ## Proposal
 
-The Kusama Tip Button sould be a standalone embeddable snippet of HTML and JS code. When added to a website, a "Tip or Donate KSM" button should show, text customizable by website owner.
+The Kusama Tip Button should be a standalone embeddable snippet of HTML and JS code. When added to a website, a "Tip or Donate KSM" button should show, text customizable by website owner.
 
 Before the user interacts with the button, the button's embedded code should:
 

docs/RFPs/php-scale.md

@@ -15,4 +15,4 @@ The SCALE codec is the de-factor encoding method in Substrate-based chains. It i
 
 The deliverable should be a standalone SCALE codec package, hosted on Packagist. It can (but does not have to) depend on existing Base58 packages already present on Packagist.org.
 
-The package *can* also be delivered as a companion PHP **extension** but the extension should be exclusivley a performance upgrade to the existing package. In other words, the Packagist-installable library should work on its own, but can be improved by also downloading the (optional) PHP extension. If the applicant decides to also create the extension, they should submit it as a separate milestone.
+The package *can* also be delivered as a companion PHP **extension** but the extension should be exclusively a performance upgrade to the existing package. In other words, the Packagist-installable library should work on its own, but can be improved by also downloading the (optional) PHP extension. If the applicant decides to also create the extension, they should submit it as a separate milestone.

docs/RFPs/polkadot-collator-setup.md

@@ -20,7 +20,7 @@ I understand it might be tricky to bundle all the parachain launch setups into o
 1. Have a single collator ansible role, and each branch would correspond to a specific parachain
 2. Have multiple ansible roles, and the main.yml in the project root to coordinate which roles get deployed.
 
-I would lean towards the second option. While it might lead to large repo size due to multiple collator setups (and multiple networks - the setup might be different on Kusama or Polkadot), it gives more flexibility to spin up multiple collators for independant chains without meddling with git branching too much.
+I would lean towards the second option. While it might lead to large repo size due to multiple collator setups (and multiple networks - the setup might be different on Kusama or Polkadot), it gives more flexibility to spin up multiple collators for independent chains without meddling with git branching too much.
 
 ## Deliverables :nut_and_bolt:
 

docs/RFPs/staking-rewards-collector-front-end.md

@@ -14,7 +14,7 @@ This Request for Proposals is _closed_, meaning we are not looking for any more
 
 The [staking-rewards-collector](https://github.com/w3f/staking-rewards-collector) is a tool to gather staking rewards for given addresses and cross-reference those with daily price data. This is a very useful tool for every validator and nominator in the ecosystem. However, since it has currently a CLI and requires some technical knowledge to set up (git, nodejs, yarn). A front-end hosted on a website could help many users getting access to this tool and enjoy the benefits. 
 
-The backend is already written in javascript, this should make it quite easy to host as a website and develope a front-end. 
+The backend is already written in javascript, this should make it quite easy to host as a website and develop a front-end. 
 
 ## Deliverables :nut_and_bolt:
 

docs/RFPs/uncollateralized-stablecoin-research.md

@@ -59,6 +59,6 @@ The milestones below are just an initial draft. The milestones can be structured
 
 | Number | Deliverable | Specification | 
 | ------------- | ------------- | ------------- |
-| 1. | Implement PoC| Implement the previous reasearch as ink! Smart contract or pallets |  
+| 1. | Implement PoC| Implement the previous research as ink! Smart contract or pallets |  
 | 2. | UI (optional) | Implement a basic UI that can be used for testing |