Fix typos

docs/cosmwasm/cosmwasm-verify-contract.md

@@ -34,7 +34,7 @@ osmosisd query wasm contract-state raw osmo1mpf0guu0t363xrshhedandypq003ahzaxvsx
 ```
 What in the world is `636F6E74726163745F696E666F`? 😕 
 
-ContractInfo is must be stored under "contract_info" key which translates to "636F6E74726163745F696E666F" in hex format. As documented [here](https://lib.rs/crates/cw2).
+ContractInfo must be stored under "contract_info" key which translates to "636F6E74726163745F696E666F" in hex format. As documented [here](https://lib.rs/crates/cw2).
 
 Output:
 

docs/cosmwasm/cw-orch.md

@@ -9,7 +9,7 @@ sidebar_position: 9
 cw-orchestrator is the most advanced scripting, testing, and deployment framework for CosmWasm smart-contracts. It makes it easy to write cross-environment compatible code for [cw-multi-test](https://github.com/CosmWasm/cw-multi-test), [Osmosis Test Tube](https://github.com/osmosis-labs/test-tube), [Starship](https://github.com/cosmology-tech/starship) (alpha), and **live networks**, significantly reducing code duplication and test-writing time. 
 
 
-Get ready to change the way you interact with contracts and simplify you smart-contracts journey. The following steps will allow you to integrate `cw-orch` and write clean code such as:
+Get ready to change the way you interact with contracts and simplify your smart-contracts journey. The following steps will allow you to integrate `cw-orch` and write clean code such as:
 
 ```rust
 counter.upload()?;
@@ -133,7 +133,7 @@ Learn more about the content of the interface creation specifics in the [`cw-orc
 
 ### Interaction helpers
 
-cw-orchestrator provides a additional macros that simplify contract calls and queries. The macro implements functions on the interface for each variant of the contract's `ExecuteMsg` and `QueryMsg`.
+cw-orchestrator provides an additional macros that simplify contract calls and queries. The macro implements functions on the interface for each variant of the contract's `ExecuteMsg` and `QueryMsg`.
 
 Enabling this functionality is very straightforward. Find your `ExecuteMsg` and `QueryMsg` definitions (in `msg.rs` in our example) and add the `ExecuteFns` and `QueryFns` derive macros to them like below:
 

docs/cosmwasm/javascript.md

@@ -163,7 +163,7 @@ The output should look like this:
 ![](contract_details.png)
 
 ## Get the count from the contract
-The contract we are interacting with has a few simple functions. 'get_count', 'increment' and 'reset'. These two functions can be called via by using the `queryContractSmart` method. 
+The contract we are interacting with has a few simple functions. 'get_count', 'increment' and 'reset'. These two functions can be called by using the `queryContractSmart` method. 
 
 :::tip
 Please note there is a complete guide on how to upload the example contract on localOsmosis [here](./local/localosmosis.md).

docs/cosmwasm/testnet/cosmwasm-beaker.md

@@ -6,7 +6,7 @@ sidebar_position: 2
 # Cosmwasm & Beaker
 ## Deploying Cosmwasm Contracts to the testnet with Beaker
 
-The following guide will show you how to create and deploy a Cosmwasm smart contract to the Osmosis testnet. The testnet is permisonless by default to allow developers to test their contracts on a live environment. The Osmosis mainnet is permissioned meaning that you will need to submit a governance proposal in order to deploy to it. 
+The following guide will show you how to create and deploy a Cosmwasm smart contract to the Osmosis testnet. The testnet is permissionless by default to allow developers to test their contracts on a live environment. The Osmosis mainnet is permissioned meaning that you will need to submit a governance proposal in order to deploy to it. 
 
 ### Requirements
 - [Rust](https://www.rust-lang.org/tools/install)
@@ -33,15 +33,15 @@ For detailed information about Beaker [click here](https://github.com/osmosis-la
 
 ### Your first CosmWasm contract with Beaker
 
-After that we can create new contract (the command uses template from [cw-template](https://github.com/InterWasm/cw-template))
+After that we can create a new contract (the command uses template from [cw-template](https://github.com/InterWasm/cw-template))
 
 ```sh
 cd counter-dapp
 beaker wasm new counter
 ```
 
-### Deploy contract on permisionless network
-The testnet is permisionless by default in order to allow developers to easily deploy contracts. 
+### Deploy contract on permissionless network
+The testnet is permissionless by default in order to allow developers to easily deploy contracts. 
 
 ```sh
 beaker wasm deploy counter --signer-account test1 --network testnet --no-wasm-opt --raw '{ "count": 0 }' --label 'My first Beaker Contract'
@@ -128,10 +128,10 @@ https://testnet.mintscan.io/osmosis-testnet/proposals/196
 https://lcd-test.osmosis.zone/cosmos/gov/v1beta1/proposals/196
 ```
 
-Note how the min_deposit was `500000000uosmo` that's why our prop.yml had `500000000uosmo`. If the deposit requirement is not met, then additional funds need to be send to the proposal. 
+Note how the min_deposit was `500000000uosmo` that's why our prop.yml had `500000000uosmo`. If the deposit requirement is not met, then additional funds need to be sent to the proposal. 
 
 #### Proposal period 
-On the testnet the voting period is very short to allow developers to move quickly with their testing, as you can see in this case it's `3 minutes`. This means you must vote within the next 3 minutes for your proposal to pass. In mainet the voting period is usually several days. If you take longer than 3 minutes, then you will get an error letting you know that the voting period has passed. 
+On the testnet the voting period is very short to allow developers to move quickly with their testing, as you can see in this case it's `3 minutes`. This means you must vote within the next 3 minutes for your proposal to pass. In mainnet the voting period is usually several days. If you take longer than 3 minutes, then you will get an error letting you know that the voting period has passed. 
 
 ```
     ├── voting_start_time: 2022-07-06T18:45:06Z
@@ -149,7 +149,7 @@ Run the following command to vote from beaker
 beaker wasm proposal vote --option yes counter --signer-account test1 --network testnet
 ```
 
-Even though the testnet is configured as permisionless, it's important to understanding the voting process. We need validators to vote  for your proposal in order to reach the quorum. We created a simple utility in our faucet that will allow you to request a validator with enough voting power to vote for your proposal as well. 
+Even though the testnet is configured as permissionless, it's important to understand the voting process. We need validators to vote for your proposal in order to reach the quorum. We created a simple utility in our faucet that will allow you to request a validator with enough voting power to vote for your proposal as well. 
 
 Please visit: 
 
@@ -170,7 +170,7 @@ In the examples above we used the test1 account to sign transactions. However, B
 - `--signer-keyring` use the OS secure store as backend to securely store your key. To manage them, you can find more information [here](../../beaker/commands/beaker_key).
 
 ### Using the OS keyring
-Let's dive a little deeper on how to use the OS keyring in order to sing a transaction with your OS keyring. 
+Let's dive a little deeper on how to use the OS keyring in order to sign a transaction with your OS keyring. 
 
 First of all you can import an account by running:
 

docs/cosmwasm/testnet/cosmwasm-deployment.md

@@ -1,5 +1,5 @@
 # Cosmwasm testnet deployment
-The following is a quick guide that shows the basics of deploying a contract to a Osmosis Testnet (`osmo-test-5`). It covers:
+The following is a quick guide that shows the basics of deploying a contract to an Osmosis Testnet (`osmo-test-5`). It covers:
 
 - Initial Setup
     - Setup Rust
@@ -20,13 +20,13 @@ The following is a quick guide that shows the basics of deploying a contract to
     - Execute the contract
 
 :::tip
-Please note this a detailed guide on how to deploy via `osmosisd`, it also covers additional tooling and useful tips.  You can also deploy to testnet with [Beaker](./cosmwasm-beaker.md) with a couple of commands. 
+Please note this is a detailed guide on how to deploy via `osmosisd`, it also covers additional tooling and useful tips.  You can also deploy to testnet with [Beaker](./cosmwasm-beaker.md) with a couple of commands. 
 :::
 
 
 ## Initial Setup
 
-This tutorial uses a Osmosis specific development tools to deploy contracts to Osmosis Testnet(`osmo-test-5`).
+This tutorial uses an Osmosis specific development tools to deploy contracts to Osmosis Testnet(`osmo-test-5`).
 
 ### Setup Rust
 
@@ -95,7 +95,7 @@ You need some tokens named `OSMO`(`uosmo`) in your address to interact with the
 You can request tokens from the official faucet at [faucet.osmosis.zone](https://faucet.osmosis.zone) 
 
 #### Discord Faucet
-Youcan also participate in the [Osmosis discord](https://discord.com/invite/osmosis) to request a faucet of the Osmosis Testnet. After gaining access to the testnet channel on the `#roles` channel of the discord, you can request a testnet token by sending the following message on the `#faucet` channel:
+You can also participate in the [Osmosis discord](https://discord.com/invite/osmosis) to request a faucet of the Osmosis Testnet. After gaining access to the testnet channel on the `#roles` channel of the discord, you can request a testnet token by sending the following message on the `#faucet` channel:
 
 ```bash
 $request <address>
@@ -325,4 +325,4 @@ In the Write Contract section, type `increment` messages and the OSMO to pay and
 
 ![](https://user-images.githubusercontent.com/70956926/172300485-4d66b5a9-1082-48da-ba1c-b979206f277e.png)
 
-Congratulations! Now you deployed your wasm smart contract on Osmosis Testnet successfully.
+Congratulations! Now you deployed your wasm smart contract on Osmosis Testnet successfully.

docs/osmosis-core/guides/create-ibc-pool.md

@@ -5,9 +5,9 @@ sidebar_position: 9
 
 # How to create a new pool with IBC assets
 
-Osmosis is a automated market maker blockchain. This means any IBC-enabled zone can add its token as an asset to be traded on Osmosis AMM completely permissionlessly. Because Osmosis is fundamentally designed as an IBC-native AMM that trades IBC tokens, rather than tokens issued on the Osmosis zone, there are additional nuances to understand and steps to be taken in order to ensure your asset is supported by Osmosis.
+Osmosis is an automated market maker blockchain. This means any IBC-enabled zone can add its token as an asset to be traded on Osmosis AMM completely permissionlessly. Because Osmosis is fundamentally designed as an IBC-native AMM that trades IBC tokens, rather than tokens issued on the Osmosis zone, there are additional nuances to understand and steps to be taken in order to ensure your asset is supported by Osmosis.
 
-This document lays out the prerequisites and the  process that's needed to ensure that your token meets the interchain UX standards set by Osmosis.
+This document lays out the prerequisites and the process that's needed to ensure that your token meets the interchain UX standards set by Osmosis.
 
 ### Prerequisites
 1. Zone must have IBC token transferred enabled (ICS20 standard).
@@ -39,7 +39,7 @@ Make a PR to add your chain's entry to the [Cosmos Chain Registry](https://githu
 Make sure to include at least one reliable RPC, gRPC, REST endpoint behind https. Refer to the [Osmosis entry](https://github.com/cosmos/chain-registry/blob/master/osmosis/chain.json) as an example.
 
 ### 2. Setting up and operating relayer to Osmosis
-Relayers are responsible of transferring IBC packets between Osmosis chain and the native chain of an asset. All Osmosis 'deposits' and 'withdrawals' are IBC transfers which dedicated relayers process.
+Relayers are responsible for transferring IBC packets between Osmosis chain and the native chain of an asset. All Osmosis 'deposits' and 'withdrawals' are IBC transfers which dedicated relayers process.
 
 To ensure fungibility amongst IBC assets, the frontend will assume social consensus have been achieved and designate one specific channel between Osmosis and the native chain as the primary channel for all IBC token transfers. Multiple relayers can be active on the same channel, and for the sake of redundancy and increased resilience we recommend having multiple relayers actively relaying packets. It is recommended to initialize the channel as an unordered IBC channel, rather than an ordered IBC channel.
 

docs/osmosis-core/modules/ibc-rate-limit/README.md

@@ -201,7 +201,7 @@ The contract also supports quotas on a custom channel called "any" that is check
 transfer channel or the "any" channel have a quota that has been filled, the transaction will be rate limited.
 
 #### Notes on Denom
-We always use the the denom as represented on Osmosis. For native assets that is the local denom, and for non-native 
+We always use the denom as represented on Osmosis. For native assets that is the local denom, and for non-native 
 assets it's the "ibc" prefix and the sha256 hash of the denom trace (`ibc/...`).
 
 ##### Sends
@@ -304,4 +304,4 @@ Not yet highlighted
    * Could imagine tieng it into looking at AMM volatility, or off-chain oracles
       * but these are both things we should be wary of security bugs in.
       * Maybe [constraint based programming with tracking of provenance](https://youtu.be/HB5TrK7A4pI?t=2852) as a solution
-* Analyze changing denom-based rate limits, to just overall withdrawal amount for Osmosis
+* Analyze changing denom-based rate limits, to just overall withdrawal amount for Osmosis

docs/osmosis-core/modules/incentives/README.md

@@ -10,9 +10,9 @@ Anyone can create gauge and add rewards to the gauge, there is no way to take it
 
 There are two kinds of `gauges`, perpetual and non-perpetual ones.
 
-- Non perpetual ones get removed from active queue after the the distribution period finish but perpetual ones persist.
+- Non perpetual ones get removed from active queue after the distribution period finish but perpetual ones persist.
 - For non perpetual ones, they distribute the tokens equally per epoch during the `gauge` is in the active period.
-- For perpetual ones, it distribute all the tokens at a single time and somewhere else put the tokens regularly to distribute the tokens, it's mainly used to distribute minted OSMO tokens to LP token stakers.
+- For perpetual ones, it distributes all the tokens at a single time and somewhere else put the tokens regularly to distribute the tokens, it's mainly used to distribute minted OSMO tokens to LP token stakers.
 
 ## Contents
 
@@ -74,7 +74,7 @@ message QueryCondition {
 
 message Gauge {
   uint64 id = 1; // unique ID of a Gauge
-  QueryCondition distribute_to = 2; // distribute condition of a lock which meet one of these conditions
+  QueryCondition distribute_to = 2; // distribute condition of a lock which meets one of these conditions
   repeated cosmos.base.v1beta1.Coin coins = 3; // can distribute multiple coins
   google.protobuf.Timestamp start_time = 4; // condition for lock start time, not valid if unset value
   uint64 num_epochs_paid_over = 5; // number of epochs distribution will be done
@@ -279,7 +279,7 @@ The incentives module contains the following parameters:
 | -------------------- | ------ | -------- |
 | DistrEpochIdentifier | string | "weekly" |
 
-Note: DistrEpochIdentifier is a epoch identifier, and module distribute
+Note: DistrEpochIdentifier is an epoch identifier, and module distribute
 rewards at the end of epochs. As `epochs` module is handling multiple
 epochs, the identifier is required to check if distribution should be
 done at `AfterEpochEnd` hook

docs/osmosis-core/modules/superfluid/README.md

@@ -160,16 +160,16 @@ SyntheticLockups are synthetic forms of PeriodLocks, but different in the
 sense that they store suffix, which is a combination of
 bonding/unbonding status + validator address. This is mainly used to
 track whether an individual lock that has been superfluid staked has an
-bonding status or a unbonding status from the staking delegations.
+bonding status or an unbonding status from the staking delegations.
 
 ### Intermediary Account
 
 Intermediary Accounts establish the connections between the superfluid
 staked locks and delegations to the validator. Intermediary accounts
-exists for every denom + validator combination, so that it would group
+exist for every denom + validator combination, so that it would group
 locks with the same denom + validator selection. Superfluid staking a
 lock would mint equivalent amount of OSMO of the lock and send it to the
-intermediary account and the intermediarry accounts would be delegating
+intermediary account and the intermediary accounts would be delegating
 to the specified validator.
 
 ### Intermediary Account Connection
@@ -194,7 +194,7 @@ Lots of questions to be answered here
 
 ### Dedicated Gauges
 
-Each intermediary account has has dedicated gauge where it sends the
+Each intermediary account has a dedicated gauge where it sends the
 delegation rewards to. Gauges are distributing the rewards to end users
 at the end of the epoch.
 
@@ -340,7 +340,7 @@ This message does all the functionality of `MsgSuperfluidUndelegate` but
 also starts unbonding the underlying lock as well, allowing both the
 unstaking and unlocking to complete at the same time. Without using this
 function, a user will not be able to start unbonding their underlying
-lock until after the the unstaking has finished.
+lock until after the unstaking has finished.
 
 **State Modifications:**
 
@@ -612,7 +612,7 @@ currently contains:
 - `MinimumRiskFactor` which is an sdk.Dec that represents the discount
   to apply to all superfluid staked modules when calculating their
   staking power. For example, if a specific denom has an OSMO
-  equivalent value of 100 OSMO, but the the `MinimumRiskFactor` param
+  equivalent value of 100 OSMO, but the `MinimumRiskFactor` param
   is 0.05, then the denom will only get 95 OSMO worth of staking power
   when staked.
 
@@ -984,4 +984,4 @@ the `IntermediaryAccount` will be slashed by less than the
 
 TODO - expand on this Uses `lockup` accumulator to find total amount of
 synthetic locks for a given `IntermediaryAccount` (Superfluid Asset +
-Validator pair)
+Validator pair)