diff --git a/.github/workflows/codespell.yml b/.github/workflows/codespell.yml
new file mode 100644
index 000000000..b74b2cee9
--- /dev/null
+++ b/.github/workflows/codespell.yml
@@ -0,0 +1,28 @@
+name: Spell Check
+
+on:
+  pull_request:
+  push:
+    branches:
+      - main
+      - master
+
+jobs:
+  spellcheck:
+    name: Run codespell
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+
+      - name: Set up Python
+        uses: actions/setup-python@v5
+        with:
+          python-version: "3.x"
+
+      - name: Install codespell
+        run: pip install codespell
+
+      - name: Run codespell
+        run: codespell --skip="yarn.lock,package-lock.json,node_modules,build"
diff --git a/docs/beaker/README.md b/docs/beaker/README.md
index 0d15ab771..1e658c76e 100644
--- a/docs/beaker/README.md
+++ b/docs/beaker/README.md
@@ -225,10 +225,10 @@ To create the contract entrypoint for migration, first, define `MigrateMsg` in `
 pub struct MigrateMsg {}
 ```
 
-With MigrateMsg defined we need to update `contract.rs`. First update the import from `crate::msg` to include `MigrateMsg`:
+With MigrateMsg defined we need to update `contract.rs`. First update the import from `create::msg` to include `MigrateMsg`:
 
 ```rust
-use crate::msg::{CountResponse, ExecuteMsg, InstantiateMsg, QueryMsg, MigrateMsg};
+use create::msg::{CountResponse, ExecuteMsg, InstantiateMsg, QueryMsg, MigrateMsg};
 ```
 
 ```rust
@@ -340,7 +340,7 @@ await contract.counter.signer(account.test1).execute({ increment: {} });
 await contract.counter.query({ get_count: {} });
 ```
 
-You can find avaialable methods for the aforementioned instances here:
+You can find available methods for the aforementioned instances here:
 
 - [Account](console/classes//Account.md#methods-1)
 - [Contract](./console/classes//Contract.md#methods-1)
diff --git a/docs/beaker/commands/beaker_wasm.md b/docs/beaker/commands/beaker_wasm.md
index b0e93be55..a0855e206 100644
--- a/docs/beaker/commands/beaker_wasm.md
+++ b/docs/beaker/commands/beaker_wasm.md
@@ -218,7 +218,7 @@ Arguments:
 
 * ` <contract-name>`Name of the contract to instantiate
 
-* `-l/--label <label>`: Label for the instantiated contract for selcting migration target (default: `default`)
+* `-l/--label <label>`: Label for the instantiated contract for selecting migration target (default: `default`)
 
 * `-r/--raw <raw>`: Raw json string to use as instantiate msg
 
diff --git a/docs/beaker/commands/beaker_wasm_proposal.md b/docs/beaker/commands/beaker_wasm_proposal.md
index 9420ee279..b609b395f 100644
--- a/docs/beaker/commands/beaker_wasm_proposal.md
+++ b/docs/beaker/commands/beaker_wasm_proposal.md
@@ -26,7 +26,7 @@ Arguments:
 
 * `--title <title>`: Proposal title (default: ``)
 
-* `--description <description>`: Proposal decsription (default: ``)
+* `--description <description>`: Proposal description (default: ``)
 
 * `--deposit <deposit>`: Proposal deposit to activate voting
 
diff --git a/docs/beaker/config/global.md b/docs/beaker/config/global.md
index 78cf0fd27..354dc0e8f 100644
--- a/docs/beaker/config/global.md
+++ b/docs/beaker/config/global.md
@@ -21,7 +21,7 @@
 * **`gas_adjustment`** : f64  
   
    > 
-   > Adjusting `gas_limit` from simulated gas as a safety factor to make sure gas_limit is enought for the tx.  
+   > Adjusting `gas_limit` from simulated gas as a safety factor to make sure gas_limit is enough for the tx.  
    > When user doesn't specify `gas_limit`, `gas_limit = simulated_gas * gas_adjustment`,  
    > while `simulated_gas` is simulated gas consumption for the tx.  
    > 
diff --git a/docs/beaker/config/workspace.md b/docs/beaker/config/workspace.md
index 32fe59744..7eda8af40 100644
--- a/docs/beaker/config/workspace.md
+++ b/docs/beaker/config/workspace.md
@@ -29,7 +29,7 @@
     * **`branch`** : String  
       
        > 
-       > Brance of the repo to be used as template  
+       > Branch of the repo to be used as template  
        > 
       
       
diff --git a/docs/cosmwasm/cw-orch.md b/docs/cosmwasm/cw-orch.md
index 2344e9632..7605d3851 100644
--- a/docs/cosmwasm/cw-orch.md
+++ b/docs/cosmwasm/cw-orch.md
@@ -20,7 +20,7 @@ let count = counter.get_count()?;
 assert_eq!(count.count, 1);
 ```
 
-In this quick-start guide, we will review the necessary steps in order to integrate [`cw-orch`](https://github.com/AbstractSDK/cw-orchestrator) into a simple contract crate. [We review integration of rust-workspaces (multiple contracts) at the end of this page](#integration-in-a-workspace).
+In this quick-start guide, we will review the necessary steps in order to integrate [`cw-orch`](https://github.com/AbstractSDK/cw-orchestrator) into a simple contract create. [We review integration of rust-workspaces (multiple contracts) at the end of this page](#integration-in-a-workspace).
 
 > **NOTE**: *Quicker than the quick start*
 >
@@ -40,7 +40,7 @@ In this quick-start guide, we will review the necessary steps in order to integr
   - [Using the integration](#using-the-integration)
 - [Integration in a workspace](#integration-in-a-workspace)
   - [Handling dependencies and features](#handling-dependencies-and-features)
-  - [Creating an interface crate](#creating-an-interface-crate)
+  - [Creating an interface create](#creating-an-interface-create)
   - [Integrating single contracts](#integrating-single-contracts)
 - [More examples and scripts](#more-examples-and-scripts)
 
@@ -93,7 +93,7 @@ Then, inside that `interface.rs` file, you can define the interface for your con
 ```rust
 use cw_orch::{interface, prelude::*};
 
-use crate::msg::{ExecuteMsg, InstantiateMsg, MigrateMsg, QueryMsg};
+use create::msg::{ExecuteMsg, InstantiateMsg, MigrateMsg, QueryMsg};
 
 pub const CONTRACT_ID: &str = "counter_contract";
 
@@ -111,11 +111,11 @@ impl<Chain: CwEnv> Uploadable for CounterContract<Chain> {
     fn wrapper(&self) -> Box<dyn MockContract<Empty>> {
         Box::new(
             ContractWrapper::new_with_empty(
-                crate::contract::execute,
-                crate::contract::instantiate,
-                crate::contract::query,
+                create::contract::execute,
+                create::contract::instantiate,
+                create::contract::query,
             )
-            .with_migrate(crate::contract::migrate),
+            .with_migrate(create::contract::migrate),
         )
     }
 }
@@ -128,7 +128,7 @@ Learn more about the content of the interface creation specifics in the [`cw-orc
 >
 >    ```rust
 >    #[cfg(feature = "interface")]
->    pub use crate::interface::CounterContract;
+>    pub use create::interface::CounterContract;
 >    ```
 
 ### Interaction helpers
@@ -176,14 +176,14 @@ Find out more about the interaction helpers in the [`cw-orch` documentation](htt
 >
 >    ```rust
 >    #[cfg(feature = "interface")]
->    pub use crate::msg::{ExecuteMsgFns as CounterExecuteMsgFns, QueryMsgFns as CounterQueryMsgFns};
+>    pub use create::msg::{ExecuteMsgFns as CounterExecuteMsgFns, QueryMsgFns as CounterQueryMsgFns};
 >    ```
 
 ### Using the integration
 
 Now that all the setup is done, you can use your contract in tests, integration-tests or scripts.
 
-Start by importing your crate, with the `interface` feature enabled. Depending on your use-case this will be in `[dependencies]` or `[dev-dependencies]`:
+Start by importing your create, with the `interface` feature enabled. Depending on your use-case this will be in `[dependencies]` or `[dev-dependencies]`:
 
 ```toml
 counter-contract = { path = "../counter-contract", features = ["interface"] }
@@ -244,9 +244,9 @@ Refer above to [Adding `cw-orch` to your `Cargo.toml` file](#adding-cw-orch-to-y
 
 For instance, for the `cw20_base` contract, you need to execute those 2 steps on the `cw20-base` contract (where the `QueryMsg` are defined) as well as on the `cw20` package (where the `ExecuteMsg` are defined).
 
-### Creating an interface crate
+### Creating an interface create
 
-When using a workspace, we advise you to create a new crate inside your workspace for defining your contract's interfaces. In order to do that, use:
+When using a workspace, we advise you to create a new create inside your workspace for defining your contract's interfaces. In order to do that, use:
 
 ```shell
 cargo new interface --lib
@@ -260,7 +260,7 @@ Add the interface package to your workspace `Cargo.toml` file
 members = ["packages/*", "contracts/*", "interface"]
 ```
 
-Inside this `interface` crate, we advise to integrate all your contracts 1 by 1 in separate files. Here is the structure of the `cw-plus` integration for reference:
+Inside this `interface` create, we advise to integrate all your contracts 1 by 1 in separate files. Here is the structure of the `cw-plus` integration for reference:
 
 ```path
 interface (interface collection)
diff --git a/docs/cosmwasm/javascript.md b/docs/cosmwasm/javascript.md
index 897da57a9..755a052cf 100644
--- a/docs/cosmwasm/javascript.md
+++ b/docs/cosmwasm/javascript.md
@@ -32,7 +32,7 @@ Create a new index.ts file
 touch index.ts
 ```
 
-The class CosmWasmClient is exported from the CosmJS package @cosmjs/cosmwasm-stargate. Learn more in the [offical docs](https://cosmwasm.github.io/CosmWasmJS/clients/reading/CosmWasmClient.html).
+The class CosmWasmClient is exported from the CosmJS package @cosmjs/cosmwasm-stargate. Learn more in the [official docs](https://cosmwasm.github.io/CosmWasmJS/clients/reading/CosmWasmClient.html).
 
 ```javascript=
 import { CosmWasmClient } from "cosmwasm";
diff --git a/docs/cosmwasm/local/submit-wasm-proposal.md b/docs/cosmwasm/local/submit-wasm-proposal.md
index 7b13453d9..966b55f79 100644
--- a/docs/cosmwasm/local/submit-wasm-proposal.md
+++ b/docs/cosmwasm/local/submit-wasm-proposal.md
@@ -42,7 +42,7 @@ CONTRACT=cw20_base
 ```
 
 ## Define proposal ID
-We cannot really do this progamatically. Proposal `1` will come out after submitting it for the first time on a new chain. You can always update this manually when testing multiple times on the same state.
+We cannot really do this programmatically. Proposal `1` will come out after submitting it for the first time on a new chain. You can always update this manually when testing multiple times on the same state.
 
 ```
 PROPOSAL=1
diff --git a/docs/cosmwasm/testnet/cosmwasm-beaker.md b/docs/cosmwasm/testnet/cosmwasm-beaker.md
index d995f7bad..fb5948aa1 100644
--- a/docs/cosmwasm/testnet/cosmwasm-beaker.md
+++ b/docs/cosmwasm/testnet/cosmwasm-beaker.md
@@ -41,7 +41,7 @@ beaker wasm new counter
 ```
 
 ### Deploy contract on permisionless network
-The testnet is permisionless by default in order to allow developers to easyly deploy contracts. 
+The testnet is permisionless 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'
@@ -53,7 +53,7 @@ Note how we added `--network testnet` to tell beaker to deploy to the testnet Os
 In this example we are using `osmo1nyphwl8p5yx6fxzevjwqunsfqpcxukmtk8t60m` which is the address from the beaker test1 account as seen in the [config.rs](https://github.com/osmosis-labs/beaker/blob/main/packages/cli/src/framework/config.rs) file. 
 
 :::warning
-Please note that account test1 is publicaly available as documented [here](https://github.com/osmosis-labs/beaker/blob/main/docs/config/global.md) and only used for development purposes. Beaker will support local keyring in about 1-2 weeks. 
+Please note that account test1 is publicly available as documented [here](https://github.com/osmosis-labs/beaker/blob/main/docs/config/global.md) and only used for development purposes. Beaker will support local keyring in about 1-2 weeks. 
 :::
 
 ```
@@ -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 undertanding 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 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. 
 
 Please visit: 
 
diff --git a/docs/frontend/translating.mdx b/docs/frontend/translating.mdx
index 261808cb8..9a057cefb 100644
--- a/docs/frontend/translating.mdx
+++ b/docs/frontend/translating.mdx
@@ -5,11 +5,11 @@ Instructions to make contributions to Osmosis frontend translations.
 
 1. Fork the Osmosis frontend repo and clone the fork locally https://github.com/osmosis-labs/osmosis-frontend/fork
 
-2. Create a new branch for the new laguage 
+2. Create a new branch for the new language 
 ```
 git checkout -b "Add Spanish Language"
 ```
-3. Copy the English langauge files to the new {lang}.js files. For example from inside the Osmosis repo:  
+3. Copy the English language files to the new {lang}.js files. For example from inside the Osmosis repo:  
 
 ```
 cd packages/web/localizations/
@@ -28,7 +28,7 @@ Run Osmosis front-end locally and test the changes by running:
 yarn install
 yarn dev
 ```
-6. Commit the changes and submit a PR againts the upstream branch.
+6. Commit the changes and submit a PR against the upstream branch.
 
 Note: 
 Use the following PRs as an example: ([Spanish](https://github.com/osmosis-labs/osmosis-frontend/pull/962), [Turkish](https://github.com/osmosis-labs/osmosis-frontend/pull/966), [French](https://github.com/osmosis-labs/osmosis-frontend/pull/960), [Korean](https://github.com/osmosis-labs/osmosis-frontend/pull/953))
diff --git a/docs/localosmosis/local-osmosis-mainstate.md b/docs/localosmosis/local-osmosis-mainstate.md
index ef56a64bc..f4e7547cc 100644
--- a/docs/localosmosis/local-osmosis-mainstate.md
+++ b/docs/localosmosis/local-osmosis-mainstate.md
@@ -73,7 +73,7 @@ make localnet-build-state-export
 make localnet-start-state-export
 ```
 
-You will then go through the genesis intialization process. This will take ~15 minutes. You will then hit the first block (not block 1, but the block number after your snapshot was taken), and then you will just see a bunch of p2p error logs with some KV store logs. **This will happen for about 1 hour**, and then you will finally hit blocks at a normal pace.
+You will then go through the genesis initialization process. This will take ~15 minutes. You will then hit the first block (not block 1, but the block number after your snapshot was taken), and then you will just see a bunch of p2p error logs with some KV store logs. **This will happen for about 1 hour**, and then you will finally hit blocks at a normal pace.
 
 9. On your host machine, add this specific wallet which holds a large amount of osmo funds
 
diff --git a/docs/osmosis-core/contributing.md b/docs/osmosis-core/contributing.md
index c5954e44c..40c201d58 100644
--- a/docs/osmosis-core/contributing.md
+++ b/docs/osmosis-core/contributing.md
@@ -80,4 +80,4 @@ For v6.x, and v4.x, most PRs to them should go to main and get a "backport" labe
 
 ### How to build proto files. (rm -rf vendor/ && make build-reproducible once docker is installed)
 
-You can do rm -rf vendor and make build-reproducible to redownload all dependencies - this should pull the latest docker image of Osmo. You should also make sure to do make proto-all to auto-generate your protobuf files. Makes ure you have docker installed. If you get something like `W0503 22:16:30.068560 158 services.go:38] No HttpRule found for method: Msg.CreateBalancerPool` feel free to ignore that. Make sure to also do make all to run all the linting tests before you commit and push, as well as `gofmt`-ing the file you've modified or added to make sure everything still abides by the standards. 
+You can do rm -rf vendor and make build-reproducible to redownload all dependencies - this should pull the latest docker image of Osmo. You should also make sure to do make proto-all to auto-generate your protobuf files. Makes sure you have docker installed. If you get something like `W0503 22:16:30.068560 158 services.go:38] No HttpRule found for method: Msg.CreateBalancerPool` feel free to ignore that. Make sure to also do make all to run all the linting tests before you commit and push, as well as `gofmt`-ing the file you've modified or added to make sure everything still abides by the standards. 
diff --git a/docs/osmosis-core/guides/structure/README.md b/docs/osmosis-core/guides/structure/README.md
index a4e883ec1..501eace15 100644
--- a/docs/osmosis-core/guides/structure/README.md
+++ b/docs/osmosis-core/guides/structure/README.md
@@ -163,7 +163,7 @@ osmosisd query block 2836990 | jq '.block.data.txs[0]' | base64 -D > outfile
 ```
 
 The `outfile` will contain raw protobuf data.
-Protobuf data does not contain its own structre with it. It requires the `.proto` file to understand
+Protobuf data does not contain its own structure with it. It requires the `.proto` file to understand
 and interpret the fields, including converting them to a readable json format.
 
 Fortunately, `osmosisd` provides some basic tools for querying individual transactions. It does not,
diff --git a/docs/osmosis-core/guides/structure/arb.md b/docs/osmosis-core/guides/structure/arb.md
index b19efc918..d102deffd 100644
--- a/docs/osmosis-core/guides/structure/arb.md
+++ b/docs/osmosis-core/guides/structure/arb.md
@@ -553,5 +553,5 @@ The result was 6 transfers, represented by the 6 `coin_received` and 6 `coin_spe
 
 These align precisely with the `coin_spent` and `coin_received` entries.
 
-This specific transaction was an arbitrage transaction. With one exact swap in/out, the initator deposited 15000000uosmo and
+This specific transaction was an arbitrage transaction. With one exact swap in/out, the initiator deposited 15000000uosmo and
 received 15003605uosmo, a gain of 3605uosmo.
diff --git a/docs/osmosis-core/keys/keys-cli.md b/docs/osmosis-core/keys/keys-cli.md
index 8fdf219af..97531cfdf 100644
--- a/docs/osmosis-core/keys/keys-cli.md
+++ b/docs/osmosis-core/keys/keys-cli.md
@@ -202,7 +202,7 @@ Here is a list of the corresponding password managers in different operating sys
   - [kwallet](https://api.kde.org/frameworks/kwallet/html/index.html)
 
 ### file backend
-The `file` backend stores the encrypted keys inside the app's configuration directory. A password entry is required everytime a user access it, which may also occur multiple times of repeated password prompts in one single command.
+The `file` backend stores the encrypted keys inside the app's configuration directory. A password entry is required every time a user access it, which may also occur multiple times of repeated password prompts in one single command.
 
 ### test backend
 The `test` backend is a password-less variation of the `file` backend. It stores unencrypted keys inside the app's configuration directory. It should only be used in testing environments and never be used in production.
\ No newline at end of file
diff --git a/docs/osmosis-core/modules/concentrated-liquidity/README.md b/docs/osmosis-core/modules/concentrated-liquidity/README.md
index daebddf99..80069ac97 100644
--- a/docs/osmosis-core/modules/concentrated-liquidity/README.md
+++ b/docs/osmosis-core/modules/concentrated-liquidity/README.md
@@ -292,7 +292,7 @@ $$tickIndex = ticksPassed + ticksToBeFulfilledByExponentAtCurrentTick =
 
 Bob set his limit order at tick 36650010
 
-## Chosing an Exponent At Price One Value
+## Choosing an Exponent At Price One Value
 
 The creator of a pool cannot choose an exponenetAtPriceOne as one of the input
 parameters since it is hard coded to -6. The number can be psedo-controlled by
@@ -410,7 +410,7 @@ type MsgCreatePosition struct {
 
 - **Response**
 
-On succesful response, we receive the actual amounts of each token used to
+On successful response, we receive the actual amounts of each token used to
 create the liquidityCreated number of shares in the given range.
 
 ```go
@@ -725,7 +725,7 @@ From the user perspective, there are two ways to swap:
 2. Swap given token out for token in
    - E.g. I want to get out 3000 DAI for some amount of ETH to compute.
 
-Each case has a corresponding message discussed previosly in the `x/poolmanager`
+Each case has a corresponding message discussed previously in the `x/poolmanager`
 section.
 
 - `MsgSwapExactIn`
@@ -1335,7 +1335,7 @@ spreadRewardChargeTotal = amountIn.Mul(spreadFactor)
 3. Price impact protection makes it exit before consuming all amount remaining.
 
 The spread factor is charged on the amount in actually consumed before price impact
-protection got trigerred.
+protection got triggered.
 
 ```go
 spreadRewardChargeTotal = amountIn.Mul(spreadFactor)
@@ -1667,7 +1667,7 @@ osmosisd q gamm spot-price 1011 uosmo ibc/10E5E5B06D78FFBB61FD9F89209DEE5FD4446E
 spot_price: "0.000000000002155018"
 ```
 
-As a protocol, we need to accomodate prices that are very far apart.
+As a protocol, we need to accommodate prices that are very far apart.
 In the example above, the difference between `10**6 and 10**18`
 
 Most of the native precision is 10**6. However, most of the ETH
diff --git a/docs/osmosis-core/modules/cosmwasmpool/README.md b/docs/osmosis-core/modules/cosmwasmpool/README.md
index 8d0a26059..a3e487ca7 100644
--- a/docs/osmosis-core/modules/cosmwasmpool/README.md
+++ b/docs/osmosis-core/modules/cosmwasmpool/README.md
@@ -83,9 +83,9 @@ sequenceDiagram
 
 Currently, all existing pool types have their own way of providing liquidity and shares calculation. CosmWasm pool aims to be flexible that regards and let the contract define the way of providing liquidity. So there is no restriction here, and the contract developer can define the way of providing liquidity as they wish, potentially with execute endpoint since `MsgExecuteContract` triggers state mutating endpoint and can also attach funds to it.
 
-Common interface and later be defined for the contract to implement as spec and/or create a separated crate for that purpose.
+Common interface and later be defined for the contract to implement as spec and/or create a separated create for that purpose.
 
-It's important to note that the _**contract itselfs hold tokens that are provided by users**_.
+It's important to note that the _**contract itself hold tokens that are provided by users**_.
 
 
 ## Swap
@@ -140,7 +140,7 @@ And because sudo message can't attach funds like execute message, chain-side is
 
 ## Deactivating
 
-On contract's sudo enpoint, `SetActive` can be called to deactivate the pool. This will prevent the pool from being used for swap, and also prevent users from providing liquidity to the pool. Contract needs to check if the pool is active before performing any state mutating operation except `SetActive`.
+On contract's sudo endpoint, `SetActive` can be called to deactivate the pool. This will prevent the pool from being used for swap, and also prevent users from providing liquidity to the pool. Contract needs to check if the pool is active before performing any state mutating operation except `SetActive`.
 
 ```rs
 SetActive {
diff --git a/docs/osmosis-core/modules/downtime-detector/README.md b/docs/osmosis-core/modules/downtime-detector/README.md
index 938354186..4743d5847 100644
--- a/docs/osmosis-core/modules/downtime-detector/README.md
+++ b/docs/osmosis-core/modules/downtime-detector/README.md
@@ -5,7 +5,7 @@ For several use cases, we need a module that can detect when the chain is recove
 So for instance, you'd want to know if it has been at least 10 minutes, since the chain was down for > 30 minutes. Since you assume in such an event that it may take ~10 minutes for price oracles to be arb'd to correct.
 Suggested Design
 
-Theres a couple designs, such as:
+There's a couple designs, such as:
 
 * Iterating over block times from the last N blocks (with a heuristic filter based on average block time)
     * Implies bounds on recovery time
diff --git a/docs/osmosis-core/modules/gamm/client/docs/create-lbp-pool.md b/docs/osmosis-core/modules/gamm/client/docs/create-lbp-pool.md
index 4156d594a..fe2279319 100644
--- a/docs/osmosis-core/modules/gamm/client/docs/create-lbp-pool.md
+++ b/docs/osmosis-core/modules/gamm/client/docs/create-lbp-pool.md
@@ -30,7 +30,7 @@ the initial `weights`, pool weight shift will not begin until
 The following is an example of a liquidity bootstrapping pool. The
 weights linearly change between the initial weights provided, and the
 target weights over 72 hrs (3 days) No start time, it defaults to time
-the tx was succesfully executed on chain.
+the tx was successfully executed on chain.
 
 pool.json
 
diff --git a/docs/osmosis-core/modules/gamm/pool-models/stableswap/README.md b/docs/osmosis-core/modules/gamm/pool-models/stableswap/README.md
index 15346bc4c..1a3d6ffac 100644
--- a/docs/osmosis-core/modules/gamm/pool-models/stableswap/README.md
+++ b/docs/osmosis-core/modules/gamm/pool-models/stableswap/README.md
@@ -15,11 +15,11 @@ One key concept, is that the pool has a native concept of
 
 ### Scaling factor handling
 
-An important concept thats up to now, not been mentioned is how do we set the expected price ratio.
+An important concept that's up to now, not been mentioned is how do we set the expected price ratio.
 In the choice of curve section, we see that its the case that when `x_reserves ~= y_reserves`, that spot price is very close to `1`. However, there are a couple issues with just this in practice:
 
 1. Precision of pegged coins may differ. Suppose `1 Foo = 10^12 base units`, whereas `1 WrappedFoo = 10^6 base units`, but `1 Foo` is expected to trade near the price of `1 Wrapped Foo`.
-2. Relatedly, suppose theres a token called `TwoFoo` which should trade around `1 TwoFoo = 2 Foo`
+2. Relatedly, suppose there's a token called `TwoFoo` which should trade around `1 TwoFoo = 2 Foo`
 3. For staking derivatives, where value accrues within the token, the expected price to concentrate around dynamically changes (very slowly).
 
 To handle these cases, we introduce scaling factors. A scaling factor maps from "raw coin units" to "amm math units", by dividing.
@@ -71,7 +71,7 @@ Most operations we do only need to reason about two of the assets in a pool, and
 We wish to have a simpler CFMM function to work within these cases.
 Due to the CFMM equation $f$ being a symmetric function, we can without loss of generality reorder the arguments to the function. Thus we put the assets of relevance at the beginning of the function. So if two assets $x, y$, we write: $f(x,y, a_3, ... a_n) = xy * a_3 * ... a_n (x^2 + y^2 + a_3^2 + ... + a_n^2)$.
 
-We then take a more convenient expression to work with, via variable substition.
+We then take a more convenient expression to work with, via variable substitution.
 
 <!-- It took several very silly hacks to get github to compile this. Editors in the future, be aware of spacing in the equation wrt how it GH renders -->
 
@@ -355,7 +355,7 @@ We bound the right hand side, with the assistance of wolfram alpha. Let $a = y_{
 * When $y_{out} > 0$
   * Use solution set: $a > 0, b > \frac{2}{3} a, c > \frac{1}{99} (-299a^2 + 597ab - 297b^2)$
     * $a > 0$ by definition.
-    * $b > \frac{2}{3} a$, as thats equivalent to $y_0 > \frac{2}{3} y_{out}$. We already assume that $y_0 >= y_{out}$.
+    * $b > \frac{2}{3} a$, as that's equivalent to $y_0 > \frac{2}{3} y_{out}$. We already assume that $y_0 >= y_{out}$.
     * Set $y_{out} = .9y_0$, per our theorem assumption. So $b = .9a$. Take $c = x^2 + w = 0$. Then [we can show that](https://www.wolframalpha.com/input?i=0+%3E+-299a%5E2+%2B+597ab+-+297b%5E2%2C+when+b%3D+.90a) $(-299a^2 + 597ab - 297b^2) < 0$ for all $a$. This completes the constraint set.
 * When $y_{out} < 0$
   * Use solution set: $a < 0, b > \frac{2}{3} a, c > -a^2 + 3ab - 3b^2$
@@ -363,9 +363,9 @@ We bound the right hand side, with the assistance of wolfram alpha. Let $a = y_{
     * $b > \frac{2}{3} a$, as $y_0$ is positive.
     * $c > 0$ is by definition, so we just need to bound when $-a^2 + 3ab - 3b^2 < 0$. This is always the case as long as one of $a$ or $b$ is non-zero, per [here](https://www.wolframalpha.com/input?i=-a%5E2+%2B+3ab+-+3b%5E2+%3C+0).
 
-Tieing this all together, we have that $e_k > .01e_y$. Therefore $e_y < 100 e_k$, satisfying our theoerem!
+Tying this all together, we have that $e_k > .01e_y$. Therefore $e_y < 100 e_k$, satisfying our theoerem!
 
-To show the informal claims, the constraint that led to this 100x error blowup was trying to accomodate high $y_{out}$. When $y_{out}$ is smaller, the error is far lower. (Often to the case that $e_y < e_k$, you can convince yourself of this by setting the ratio to being greater than 1 in wolfram alpha) When $y_{out}$ is bigger than $.9y_0$, we can rely on x_f^2 + w being much larger to lower this error. In these cases, the $x_f$ term must be large relative to $y_0$, which would yield a far better error bound.
+To show the informal claims, the constraint that led to this 100x error blowup was trying to accommodate high $y_{out}$. When $y_{out}$ is smaller, the error is far lower. (Often to the case that $e_y < e_k$, you can convince yourself of this by setting the ratio to being greater than 1 in wolfram alpha) When $y_{out}$ is bigger than $.9y_0$, we can rely on x_f^2 + w being much larger to lower this error. In these cases, the $x_f$ term must be large relative to $y_0$, which would yield a far better error bound.
 
 TODO: Justify a_y << y_out. (This should be easy, assume its not, that leads to e_k being high. Ratio test probably easiest. Maybe just add a sentence to that effect)
 
diff --git a/docs/osmosis-core/modules/ibc-hooks/README.md b/docs/osmosis-core/modules/ibc-hooks/README.md
index 1955c925d..e28fa47a1 100644
--- a/docs/osmosis-core/modules/ibc-hooks/README.md
+++ b/docs/osmosis-core/modules/ibc-hooks/README.md
@@ -55,7 +55,7 @@ msg := MsgExecuteContract{
 
 ### ICS20 packet structure
 
-So given the details above, we propogate the implied ICS20 packet data structure.
+So given the details above, we propagate the implied ICS20 packet data structure.
 ICS20 is JSON native, so we use JSON for the memo format.
 
 ```json 
@@ -94,7 +94,7 @@ We consider an ICS20 packet as directed towards wasmhooks iff all of the followi
 * `memo` has at least one key, with name `"wasm"`
 
 If an ICS20 packet is not directed towards wasmhooks, wasmhooks doesn't do anything.
-If an ICS20 packet is directed towards wasmhooks, and is formated incorrectly, then wasmhooks returns an error.
+If an ICS20 packet is directed towards wasmhooks, and is formatted incorrectly, then wasmhooks returns an error.
 
 ### Execution flow
 
diff --git a/docs/osmosis-core/modules/ibc-rate-limit/README.md b/docs/osmosis-core/modules/ibc-rate-limit/README.md
index f8a0b91bd..103bbd88e 100644
--- a/docs/osmosis-core/modules/ibc-rate-limit/README.md
+++ b/docs/osmosis-core/modules/ibc-rate-limit/README.md
@@ -33,7 +33,7 @@ This stems from the idea that a 30% asset depeg is ~infinitely better than a 100
 Its _crazy_ that today these complex bridged assets can instantly go to 0 in event of bug.
 The goal of a rate limit is to raise an alert that something has potentially gone wrong, allowing validators and developers to have time to analyze, react, and protect larger portions of user funds.
 
-The thesis of this is that, it is worthwile to sacrifice liveness in the case of legitimate demand to send extreme amounts of funds, to prevent the terrible long-tail full fund risks.
+The thesis of this is that, it is worthwhile to sacrifice liveness in the case of legitimate demand to send extreme amounts of funds, to prevent the terrible long-tail full fund risks.
 Rate limits aren't the end-all of safety controls, they're merely the simplest automated one. More should be explored and added onto IBC!
 
 ## Rate limit types
@@ -71,7 +71,7 @@ Definitely needs far more ideation and iteration!
 
 ## Parameterizing the rate limit
 
-One element is we don't want any rate limit timespan thats too short, e.g. not enough time for humans to react to. So we wouldn't want a 1 hour rate limit, unless we think that if its hit, it could be assessed within an hour.
+One element is we don't want any rate limit timespan that's too short, e.g. not enough time for humans to react to. So we wouldn't want a 1 hour rate limit, unless we think that if its hit, it could be assessed within an hour.
 
 ### Handling rate limit boundaries
 
@@ -101,7 +101,7 @@ It does get more complex when the counterparty chain is itself a DEX, but this i
 
 The "Outflow" side of a rate limit is protection against a bug on Osmosis OR IBC.
 This has potential for much more user-frustrating issues, if set too low.
-E.g. if theres some event that causes many people to suddenly withdraw many STARS or many USDC.
+E.g. if there's some event that causes many people to suddenly withdraw many STARS or many USDC.
 
 So this parameterization has to contend with being a tradeoff of withdrawal liveness in high volatility periods vs being a crucial safety rail, in event of on-Osmosis bug.
 
@@ -192,8 +192,8 @@ All of these messages receive the packet from the chain and extract the necessar
 To determine if a packet should be rate limited, we need:
 
 * Channel: The channel on the Osmosis side: `packet.SourceChannel` for sends, and `packet.DestinationChannel` for receives. 
-* Denom: The denom of the token being transferred as known on the Osmosis side (more on that bellow)
-* Channel Value: The total value of the chanel denominated in `Denom` (i.e.: channel-17 is worth 10k osmo).  
+* Denom: The denom of the token being transferred as known on the Osmosis side (more on that below)
+* Channel Value: The total value of the channel denominated in `Denom` (i.e.: channel-17 is worth 10k osmo).  
 * Funds: the amount being transferred
 
 #### Notes on Channel
diff --git a/docs/osmosis-core/modules/lockup/README.md b/docs/osmosis-core/modules/lockup/README.md
index cfadce715..1e6db3e01 100644
--- a/docs/osmosis-core/modules/lockup/README.md
+++ b/docs/osmosis-core/modules/lockup/README.md
@@ -100,7 +100,7 @@ references. (`b_prefix_key`)
 3. `{KeyPrefixDenomLockDuration}{Denom}{Duration}`
 4. `{KeyPrefixAccountDenomLockDuration}{Owner}{Denom}{Duration}`
 
-If the lock is unlocking, it also stores the below referneces.
+If the lock is unlocking, it also stores the below references.
 
 1. `{KeyPrefixLockTimestamp}{LockEndTime}`
 2. `{KeyPrefixAccountLockTimestamp}{Owner}{LockEndTime}`
@@ -395,7 +395,7 @@ Lockup admin keeper provides god privilege functions to remove tokens
 from locks and create new locks.
 
 ```go
-// AdminKeeper defines a god priviledge keeper functions to remove tokens from locks and create new locks
+// AdminKeeper defines a god privilege keeper functions to remove tokens from locks and create new locks
 // For the governance system of token pools, we want a "ragequit" feature
 // So governance changes will take 1 week to go into effect
 // During that time, people can choose to "ragequit" which means they would leave the original pool
@@ -408,7 +408,7 @@ type AdminKeeper interface {
 
     // this unlock previous lockID and create a new lock with newCoins with same duration and endtime
     Relock(sdk.Context, lockID uint64, newCoins sdk.Coins) error
-    // this unlock without time check with an admin priviledge
+    // this unlock without time check with an admin privilege
     BreakLock(sdk.Context, lockID uint64) error
 }
 ```
diff --git a/docs/osmosis-core/modules/pool-incentives/README.md b/docs/osmosis-core/modules/pool-incentives/README.md
index 6ac2295c5..2fd3b9b98 100644
--- a/docs/osmosis-core/modules/pool-incentives/README.md
+++ b/docs/osmosis-core/modules/pool-incentives/README.md
@@ -32,7 +32,7 @@ selected gauges.
 
 ```go
 type GenesisState struct {
- // params defines all the paramaters of the module.
+ // params defines all the parameters of the module.
  Params            Params          
  LockableDurations []time.Duration 
  DistrInfo         *DistrInfo      
diff --git a/docs/osmosis-core/modules/superfluid/README.md b/docs/osmosis-core/modules/superfluid/README.md
index 86770b0fa..e281b821e 100644
--- a/docs/osmosis-core/modules/superfluid/README.md
+++ b/docs/osmosis-core/modules/superfluid/README.md
@@ -291,7 +291,7 @@ type MsgSuperfluidUndelegate struct {
   pair
 - Create a new `SyntheticLockup` which is unbonding
 - Calculate the amount of `Osmo` delegated on behalf of this `lock` as
-  `Osmo Equivalent Multipler` \* `# LP Shares` \*
+  `Osmo Equivalent Multiplier` \* `# LP Shares` \*
   `Risk Adjustment Factor`
   - If this amount is less than 0.000001 `Osmo`, there is no
     delegated `Osmo` to undelegate and burn
@@ -373,7 +373,7 @@ Overall Epoch sequence
     - (Currently spot price at epoch)
   - Refresh delegation amounts for all `Intermediary Accounts`
     - Calculate the expected delegation for this account as
-      `Osmo Equivalent Multipler` _`# LP Shares`_
+      `Osmo Equivalent Multiplier` _`# LP Shares`_
       `Risk adjustment`
       - If this is less than 0.000001 `Osmo` it will be rounded
         to 0
@@ -610,7 +610,7 @@ The params query returns the params for the superfluid module. This
 currently contains:
 
 - `MinimumRiskFactor` which is an sdk.Dec that represents the discount
-  to apply to all superfluid staked modules when calcultating their
+  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
   is 0.05, then the denom will only get 95 OSMO worth of staking power
@@ -784,7 +784,7 @@ message SuperfluidDelegationRecord {
 ```
 
 This query returns a list of all the superfluid delegations of a
-specific delegator. The return value includes, the validator delgated to
+specific delegator. The return value includes, the validator delegated to
 and the delegated coins (both denom and amount).
 
 The return value of the query also includes the `total_delegated_coins`
@@ -906,7 +906,7 @@ already safely handled by the Superfluid refreshing logic.
 
 The refreshing logic checks the total amount of tokens in locks to this
 denom (Reading from the lockup accumulation store), calculates how many
-osmo thats worth at the epochs new osmo worth for that asset, and then
+osmo that's worth at the epochs new osmo worth for that asset, and then
 uses that. Thus this safely handles this edge case, as it uses the new
 'live' lockup amount.
 
@@ -972,7 +972,7 @@ for the underlying asset.
 
 ### SlashLockupsForValidatorSlash (BeforeValidatorSlashed Hook)
 
-During slashing the invariant is likely to be temporraily broken if the
+During slashing the invariant is likely to be temporarily broken if the
 referenced validator has any unbonding delegations. These unbonding
 delegations are slashed first, which means that the amount delegated by
 the `IntermediaryAccount` will be slashed by less than the
diff --git a/docs/osmosis-core/modules/tokenfactory/README.md b/docs/osmosis-core/modules/tokenfactory/README.md
index 643478499..d7c8e7aaa 100644
--- a/docs/osmosis-core/modules/tokenfactory/README.md
+++ b/docs/osmosis-core/modules/tokenfactory/README.md
@@ -81,7 +81,7 @@ message MsgBurn {
 
 **State Modifications:**
 
-- Saftey check the following
+- Safety check the following
   - Check that the denom minting is created via `tokenfactory` module
   - Check that the sender of the message is the admin of the denom
 - Burn designated amount of tokens for the denom via `bank` module
diff --git a/docs/osmosis-core/relaying/ibc-relayers-list.md b/docs/osmosis-core/relaying/ibc-relayers-list.md
index a9756936a..45b3f0fdc 100644
--- a/docs/osmosis-core/relaying/ibc-relayers-list.md
+++ b/docs/osmosis-core/relaying/ibc-relayers-list.md
@@ -12,7 +12,7 @@ sidebar_position: 4
 | [BloClick](https://bloclick.com/) | bloclick@protonmail.com <br/> <img src="https://user-images.githubusercontent.com/95667791/163505650-fe08f2a7-8419-4a2f-97b7-e5182dd386e1.png" alt="Discord" width="18"/> Discord ivandiazperez#5927 | :lock: Delegate to BloClick on: Ixo, Fetch.ai, Bitcanna, Regen, AssetMantle, Desmos, Stargaze, OmniFlix, Gravity Bridge, Chronic, Umee | :heavy_dollar_sign: Offers Relaying as a Service (RaaS) (contact directly for pricing) <br/> :information_desk_person: Supports new relayers | OmniFlix, Stargaze |
 | [Bro_n_Bro](https://monitor.bronbro.io/) | <img src="https://user-images.githubusercontent.com/95667791/163506878-e7e278b2-1cf6-4dac-bc13-e92f63600ee0.png" alt="Twitter" width="18"/> Twitter [@bro_n_bro](https://twitter.com/Bro_n_Bro) <br/> <img src="https://user-images.githubusercontent.com/95667791/163506639-7d27e947-94c7-4740-bb46-8e5791e9fc6c.png" alt="Telegram" width="18"/> Telegram [Bro_n_Bro chat](https://t.me/bro_n_bro_community) | :lock: Delegate to Bro_n_Bro on: [Osmosis](https://wallet.keplr.app/#/osmosis/stake?modal=detail&chainId=osmosis-1&validator=osmovaloper13tk45jkxgf7w0nxquup3suwaz2tx483xe832ge), Bostrom, Osmo, e-Money, Juno, Stars, Microtick, Gravity, OmniFlix, Evmos | :information_desk_person: Supports new relayers | Bostrom |
 | [Cephalopod Equipment Corp](http://cephalopod.equipment) | validator@informal.systems <br/> <img src="https://user-images.githubusercontent.com/95667791/163506639-7d27e947-94c7-4740-bb46-8e5791e9fc6c.png" alt="Telegram" width="18"/> Telegram @JD_Lorax <br/> <img src="https://user-images.githubusercontent.com/95667791/163506878-e7e278b2-1cf6-4dac-bc13-e92f63600ee0.png" alt="Twitter" width="18"/> Twitter @CephalopodEquip | :lock: Delegate to Cephalopod Equipment Corp on: [Osmosis](https://wallet.keplr.app/#/osmosis/stake?modal=detail&chainId=osmosis-1&validator=osmovaloper1x20lytyf6zkcrv5edpkfkn8sz578qg5s833swz), Cosmos Hub, Regen, Ixo, Juno, Cheqd, Akash, Agoric | :heavy_dollar_sign: Offers Relaying as a Service (RaaS) (contact directly for pricing) <br/> :information_desk_person: Supports new relayers | Cosmos Hub, Sifchain, Regen, Juno, Ixo, Cheqd, Akash, Crypto.org, Persistence, Starname, e-Money, Sentinel |
-| [Cros-nest](http://cros-nest.com) | chainmaster@cros-nest.com <br/> <img src="https://user-images.githubusercontent.com/95667791/163506878-e7e278b2-1cf6-4dac-bc13-e92f63600ee0.png" alt="Twitter" width="18"/> Twitter [@crosnest_com](https://twitter.com/crosnest_com) <br/> <img src="https://user-images.githubusercontent.com/95667791/163505650-fe08f2a7-8419-4a2f-97b7-e5182dd386e1.png" alt="Discord" width="18"/> Discord [Cro's Nest](https://discord.gg/psDap3ed7C) <br/> <img src="https://user-images.githubusercontent.com/95667791/163506639-7d27e947-94c7-4740-bb46-8e5791e9fc6c.png" alt="Telegram" width="18"/> Telegram @Galadrin | :lock: Delegate to Cros-Nest on: [Osmosis](https://wallet.keplr.app/#/osmosis/stake?modal=detail&chainId=osmosis-1&validator=osmovaloper1u6jr0pztvsjpvx77rfzmtw49xwzu9kas05lk04), Cosmos Hub, Juno, e-money, Crypto.org, Evmos, Fetch.ai, Cronos, Persistance, Comdex, Lum, Chihuahua, Dig, Gravity Bridge, Kava, Ki, Konstellation, Rizon, OmniFlix, Cerberus, Provenance | :heavy_dollar_sign: Offers Relaying as a Service (RaaS) (contact directly for pricing) <br/> :information_desk_person: Supports new relayers | Cosmos Hub, Juno, e-Money, Crypto.org, Evmos, Fetch.ai, Cronos, Persistance, Comdex, Lum, Chihuahua, Dig, Gravity Bridge, Kava, Ki, Konstellation, Rizon, OmniFlix, Cerberus, Provenance, Certik |
+| [Cros-nest](http://cros-nest.com) | chainmaster@cros-nest.com <br/> <img src="https://user-images.githubusercontent.com/95667791/163506878-e7e278b2-1cf6-4dac-bc13-e92f63600ee0.png" alt="Twitter" width="18"/> Twitter [@crosnest_com](https://twitter.com/crosnest_com) <br/> <img src="https://user-images.githubusercontent.com/95667791/163505650-fe08f2a7-8419-4a2f-97b7-e5182dd386e1.png" alt="Discord" width="18"/> Discord [Cro's Nest](https://discord.gg/psDap3ed7C) <br/> <img src="https://user-images.githubusercontent.com/95667791/163506639-7d27e947-94c7-4740-bb46-8e5791e9fc6c.png" alt="Telegram" width="18"/> Telegram @Galadrin | :lock: Delegate to Cros-Nest on: [Osmosis](https://wallet.keplr.app/#/osmosis/stake?modal=detail&chainId=osmosis-1&validator=osmovaloper1u6jr0pztvsjpvx77rfzmtw49xwzu9kas05lk04), Cosmos Hub, Juno, e-money, Crypto.org, Evmos, Fetch.ai, Cronos, Persistence, Comdex, Lum, Chihuahua, Dig, Gravity Bridge, Kava, Ki, Konstellation, Rizon, OmniFlix, Cerberus, Provenance | :heavy_dollar_sign: Offers Relaying as a Service (RaaS) (contact directly for pricing) <br/> :information_desk_person: Supports new relayers | Cosmos Hub, Juno, e-Money, Crypto.org, Evmos, Fetch.ai, Cronos, Persistence, Comdex, Lum, Chihuahua, Dig, Gravity Bridge, Kava, Ki, Konstellation, Rizon, OmniFlix, Cerberus, Provenance, Certik |
 | [CryptoCrew Validators](http://ccvalidators.com) | cs@ccvalidators.com <br/> <img src="https://user-images.githubusercontent.com/95667791/163506878-e7e278b2-1cf6-4dac-bc13-e92f63600ee0.png" alt="Twitter" width="18"/> Twitter [@crypto_crew](http://twitter.com/crypto_crew) <br/> <img src="https://user-images.githubusercontent.com/95667791/163505650-fe08f2a7-8419-4a2f-97b7-e5182dd386e1.png" alt="Discord" width="18"/> Discord Claimens#3460 <br/> <img src="https://user-images.githubusercontent.com/95667791/163506639-7d27e947-94c7-4740-bb46-8e5791e9fc6c.png" alt="Telegram" width="18"/> Telegram @clemensg	| :lock: Delegate to CryptoCrew Validators on: [Osmosis](https://wallet.keplr.app/#/osmosis/stake?modal=detail&chainId=osmosis-1&validator=osmovaloper1h2c47vd943scjlfum6yc5frvu2l279lwjep5d6), Cosmos Hub, Terra, Juno, Band Protocol, Stargaze, OmniFlix, Evmos, Gravity Bridge, Comdex, Chihuahua, e-Money, Lum, Bitsong, Vidulum, Dig, Odin <br/> :pray: Donations accepted @ <sup><sub>`osmo15md2qvgma8lnvqv67w0umu2paqkqkheg332u7d`</sub></sup> | :heavy_dollar_sign: Offers Relaying as a Service (RaaS) (contact directly for pricing) <br/> :information_desk_person: Supports new relayers | Cosmos Hub, Terra, Juno, Band Protocol, Stargaze, OmniFlix, Evmos, Gravity Bridge, Comdex, Chihuahua, e-Money, Lum, Bitsong, Vidulum, Dig, Odin, Secret |
 | [Imperator.co](https://imperator.co/) | contact@imperator.co <br/> <img src="https://user-images.githubusercontent.com/95667791/163506639-7d27e947-94c7-4740-bb46-8e5791e9fc6c.png" alt="Telegram" width="18"/> Telegram @xImpe, @ibrmakaveli, @aalahyane	<br/> <img src="https://user-images.githubusercontent.com/95667791/163506878-e7e278b2-1cf6-4dac-bc13-e92f63600ee0.png" alt="Twitter" width="18"/> Twitter [@imperator_co](https://twitter.com/imperator_co) | :lock: Delegate to Imperator.co on: [Osmosis](https://wallet.keplr.app/#/osmosis/stake?modal=detail&chainId=osmosis-1&validator=osmovaloper1t8qckan2yrygq7kl9apwhzfalwzgc2429p8f0s), Cosmos Hub, Juno, Axelar, Sommelier, Stargaze, Ki, Lum, Comdex, Persistence, Likecoin, Sentinel, Iris, Akash, Medibloc, e-Money, Ixo, Bitsong, Vidulum, Rizon, BitCanna, Sifchain, Konstellation, Odin, OmniFlix, Commercio, Certik | :heavy_dollar_sign: Offers Relaying as a Service (RaaS) (contact directly for pricing) <br/> :information_desk_person: Supports new relayers | Juno, Axelar, Sommelier, Stargaze, Ki, Lum, Comdex, Persistence, Medibloc, e-Money |
 | [Interbloc](https://Interbloc.org) | <img src="https://user-images.githubusercontent.com/95667791/163505650-fe08f2a7-8419-4a2f-97b7-e5182dd386e1.png" alt="Discord" width="18"/> Discord coldchain#6999, ctrl-Felix#4505 <br/> <img src="https://user-images.githubusercontent.com/95667791/163506639-7d27e947-94c7-4740-bb46-8e5791e9fc6c.png" alt="Telegram" width="18"/> Telegram @Coldchain1, @ctrlfelix | :lock: Delegate to coldy on: [Osmosis](https://wallet.keplr.app/#/osmosis/stake?modal=detail&chainId=osmosis-1&validator=osmovaloper15004ysvmqnqzkvt7x6s4cd53flmmvgfv6t4y9y), Evmos, Bitsong, Nomic <br/> :pray: Donations accepted @ <sup><sub>`osmo1xusjpm88ltvak0nx867ejejhygpkjnaaramr0r`</sub></sup> | :heavy_dollar_sign: Offers Relaying as a Service (RaaS) (contact directly for pricing) <br/> :information_desk_person: Supports new relayers | Terra, Cosmos Hub, Bitsong, Chihuahua |
diff --git a/docs/osmosis-outpost/faq.md b/docs/osmosis-outpost/faq.md
index febc88501..6b05d439a 100644
--- a/docs/osmosis-outpost/faq.md
+++ b/docs/osmosis-outpost/faq.md
@@ -31,7 +31,7 @@ sub-operations, or sub-swaps, maybe passing through the OSMO token.
 
 ### Not allowed
 If you want to perform a swap but the swap button is disabled and says 
-"Not allowd", this means that you denied the connection of the dApp to one of 
+"Not allowed", this means that you denied the connection of the dApp to one of 
 the chains involved in the swap operations. You can allow/deny such permissions
 directly through your wallet (e.g., keplr).
 
diff --git a/docs/osmosis-outpost/user-interface-setup/frontend-platform-interface/customization-guide/customization/customizable-elements/social-configuration.md b/docs/osmosis-outpost/user-interface-setup/frontend-platform-interface/customization-guide/customization/customizable-elements/social-configuration.md
index b76ff8def..f92e20611 100644
--- a/docs/osmosis-outpost/user-interface-setup/frontend-platform-interface/customization-guide/customization/customizable-elements/social-configuration.md
+++ b/docs/osmosis-outpost/user-interface-setup/frontend-platform-interface/customization-guide/customization/customizable-elements/social-configuration.md
@@ -20,7 +20,7 @@ This is a url to add as link to the label "Analytics". We recommend you to use
 a link to your DeFi project analytics, as the one provided by the 
 [info.osmosis.zone](https://info.osmosis.zone) service.
 
-E.g., for the Osmosis project, we reccomend you to use
+E.g., for the Osmosis project, we recommend you to use
 [info.osmosis.zone/token/OSMO](https://info.osmosis.zone/token/OSMO).
 
 ```bash
@@ -32,7 +32,7 @@ NEXT_PUBLIC_ANALYTICS_LINK=
 This is a url to add as link to the label "Documentation". We recommend you to 
 use a link to your project documentation.
 
-E.g., for the Osmosis project, we reccomend you to use
+E.g., for the Osmosis project, we recommend you to use
 [docs.osmosis.zone](https://docs.osmosis.zone).
 
 ```bash
@@ -44,7 +44,7 @@ NEXT_PUBLIC_DOCS_LINK=
 This is a url to add as link to the label "GitHub". Use the link to your 
 GitHub organization/project.
 
-E.g., for the Osmosis project, we reccomend you to use
+E.g., for the Osmosis project, we recommend you to use
 [github.com/osmosis-labs](https://github.com/osmosis-labs).
 
 ```bash
diff --git a/docs/osmosis-outpost/user-interface-setup/frontend-platform-interface/customization-guide/design-customization.md b/docs/osmosis-outpost/user-interface-setup/frontend-platform-interface/customization-guide/design-customization.md
index 1d05c8cc8..32876b147 100644
--- a/docs/osmosis-outpost/user-interface-setup/frontend-platform-interface/customization-guide/design-customization.md
+++ b/docs/osmosis-outpost/user-interface-setup/frontend-platform-interface/customization-guide/design-customization.md
@@ -105,7 +105,7 @@ The logo to provide must agree the following:
 - colour: single-color **WHITE**;
 - format: **\*.svg**;
 
-We attach some exmaples (Nabla, Osmosis and Juno) of logos to give you a guideline.
+We attach some examples (Nabla, Osmosis and Juno) of logos to give you a guideline.
 Please, access this page in dark mode to have a better experience.
 
 | **nabla** |   | **Osmosis** |   | **Juno** |
diff --git a/docs/osmosis-outpost/user-interface-setup/widget/customization-guide/theme-customization.md b/docs/osmosis-outpost/user-interface-setup/widget/customization-guide/theme-customization.md
index 859306888..f4b2686ca 100644
--- a/docs/osmosis-outpost/user-interface-setup/widget/customization-guide/theme-customization.md
+++ b/docs/osmosis-outpost/user-interface-setup/widget/customization-guide/theme-customization.md
@@ -54,7 +54,7 @@ see which tokens you are able to recover, and there is a button to recover them.
 ### Settings
 You can set the *slippage tolerance* and the recovery address. You can perform 
 this action through the settings screen. Here, you can see a list of buttons 
-that allow you to select one of the default values avaliable for the slippage 
+that allow you to select one of the default values available for the slippage 
 tolerance, and a numeric input box that let you insert a custom value. In the 
 bottom of the page, you have the ability to set a valid osmosis address as the
 recovery address. Please, read carefully 
diff --git a/docs/osmosis-outpost/user-interface-setup/widget/getting-started.md b/docs/osmosis-outpost/user-interface-setup/widget/getting-started.md
index adca99187..5273ed007 100644
--- a/docs/osmosis-outpost/user-interface-setup/widget/getting-started.md
+++ b/docs/osmosis-outpost/user-interface-setup/widget/getting-started.md
@@ -22,5 +22,5 @@ all the logic necessary to integrate it in an existing dApp.
 If you are interested in customizing the style of your own widget, please 
 follow the instructions [here](./customization-guide/customizability).
 
-Otherwise, if you are interested in embedding the widget in your exising 
+Otherwise, if you are interested in embedding the widget in your existing 
 application, follow the instructions [here](./embed/installation.md).
\ No newline at end of file
diff --git a/docs/overview/educate/osmo.md b/docs/overview/educate/osmo.md
index 5a09ec8f3..774b03a95 100644
--- a/docs/overview/educate/osmo.md
+++ b/docs/overview/educate/osmo.md
@@ -15,7 +15,7 @@ Transaction fees are paid by any user to post a transaction on the chain. The fe
 Validators can choose which assets to accept for fees in the blocks that they propose, but all accepted assets are converted to OSMO before distribution.
 
 ## ProtoRev
-The ProtoRev module mints and burns the OSMO token in order to perform priviledged arbitrage transactions on chain to ensure prices are balanced across liquidity sources on chain.
+The ProtoRev module mints and burns the OSMO token in order to perform privileged arbitrage transactions on chain to ensure prices are balanced across liquidity sources on chain.
 No use for this revenue has currently been decided, but will be allocated by governance in the future.
 Protocol Revenue collected so far is currently stored in the [module address](https://www.mintscan.io/osmosis/account/osmo17qdmjdumw4xawam4g46gtwzle5rd4zwyfqvvza)
 
diff --git a/docs/overview/endpoints/index.mdx b/docs/overview/endpoints/index.mdx
index f72304d27..ed33e0e0e 100644
--- a/docs/overview/endpoints/index.mdx
+++ b/docs/overview/endpoints/index.mdx
@@ -22,7 +22,7 @@ This section serves the purpose of different endpoints for different projects on
 
 ## Mainnet Chain Endpoints
 
-These following API's are recommended for development purposes. For maximun control and reliability it's recommended to run your own node. This can be easility accomplsihed by using the get.osmosis.zone installer.
+These following API's are recommended for development purposes. For maximum control and reliability it's recommended to run your own node. This can be easility accomplsihed by using the get.osmosis.zone installer.
 
 - gRPC endpoint: [grpc.osmosis.zone:9090](grpc.osmosis.zone:9090)
 - gRPC-gateway: [https://rpc.osmosis.zone:443](https://rpc.osmosis.zone:443)
diff --git a/docs/overview/features/concentrated-liquidity.md b/docs/overview/features/concentrated-liquidity.md
index ba67e7c51..7fb1b36e0 100644
--- a/docs/overview/features/concentrated-liquidity.md
+++ b/docs/overview/features/concentrated-liquidity.md
@@ -187,7 +187,7 @@ osmosisd q gamm spot-price 1011 uosmo ibc/10E5E5B06D78FFBB61FD9F89209DEE5FD4446E
 spot_price: "0.000000000002155018"
 ```
 
-As a protocol, we need to accomodate prices that are very far apart.
+As a protocol, we need to accommodate prices that are very far apart.
 In the example above, the difference between `10**6 and 10**18`
 
 Most of the native precision is 10**6. However, most of the ETH
diff --git a/docs/overview/features/fee-abstraction.md b/docs/overview/features/fee-abstraction.md
index a4dac27d3..ee0a5a8de 100644
--- a/docs/overview/features/fee-abstraction.md
+++ b/docs/overview/features/fee-abstraction.md
@@ -20,7 +20,7 @@ Fee-abs implementation:
 
 - Fee-abs module imported to the customer chain.
 
-The implememtation also uses Osmosis swap router and async-icq module which are already deployed on Osmosis testnet.
+The implementation also uses Osmosis swap router and async-icq module which are already deployed on Osmosis testnet.
 
 ## Prototype
 
@@ -36,7 +36,7 @@ Fee-abs mechanism in a nutshell:
 
  3. Swap accumulated ibc-token fee:
 
-- The collected ibc-token users use for tx fee is periodically swaped back to customer chain's native token using osmosis.
+- The collected ibc-token users use for tx fee is periodically swapped back to customer chain's native token using osmosis.
 
 We'll goes into all the details now:
 
diff --git a/docs/overview/integrate/frontend.md b/docs/overview/integrate/frontend.md
index 8ebd1635e..78600c59f 100644
--- a/docs/overview/integrate/frontend.md
+++ b/docs/overview/integrate/frontend.md
@@ -18,4 +18,4 @@ Approval requires meeting the requirements in the assetlist repo that can be see
 
 ## Swap Page
 
-Although any asset in a liquidity pool can be traded when a user specifies the pool, an asset will only be listed on the Swap page if it is has a pool cointaining liquidity of USD $10,000.
\ No newline at end of file
+Although any asset in a liquidity pool can be traded when a user specifies the pool, an asset will only be listed on the Swap page if it is has a pool containing liquidity of USD $10,000.
\ No newline at end of file
diff --git a/docs/overview/integrate/grpc.md b/docs/overview/integrate/grpc.md
index bd9c52990..e889857d0 100644
--- a/docs/overview/integrate/grpc.md
+++ b/docs/overview/integrate/grpc.md
@@ -4,7 +4,7 @@ sidebar_position: 10
 
 # Interact with gRPC Server
 
-A gRPC endpoint is availble on the public Osmosis nodes so that you can start playing and intreacting with it right away.
+A gRPC endpoint is available on the public Osmosis nodes so that you can start playing and intreacting with it right away.
 
 ## Enabling gRPC on a node
 If you are running your own node. It's also possible to enable them by editing  `~/.osmosisd/config/app.toml`: 
diff --git a/docs/overview/integrate/incentives.md b/docs/overview/integrate/incentives.md
index 6e67de9d5..c579005c9 100644
--- a/docs/overview/integrate/incentives.md
+++ b/docs/overview/integrate/incentives.md
@@ -7,7 +7,7 @@ Liquidity Providers on Osmosis receive swap fees by default, but can receive add
 
 * [External Incentives](#external-incentives)
 
-	Osmosis allows for the permissionless creation of external liquidity mining gauges, allowing projects to add thier own rewards to further incentivize users to provide liquidity into a pool.
+	Osmosis allows for the permissionless creation of external liquidity mining gauges, allowing projects to add their own rewards to further incentivize users to provide liquidity into a pool.
 
 * [Internal Incentives](#internal-incentives)
 
diff --git a/docs/overview/integrate/on-chain.md b/docs/overview/integrate/on-chain.md
index 75c0f2a2d..f8fd84bcd 100644
--- a/docs/overview/integrate/on-chain.md
+++ b/docs/overview/integrate/on-chain.md
@@ -57,7 +57,7 @@ Concentrated liquidity is available on the OsmoJS package. For more information
 
 ## CosmWasm - (`osmosis-std`)
 
-Concentrated liquidity types and querier are available on [`osmosis-std` crate.](https://crates.io/crates/osmosis-std/)
+Concentrated liquidity types and querier are available on [`osmosis-std` create.](https://crates.io/crates/osmosis-std/)
 
 ### Install `osmosis-std`
 ```bash
@@ -155,7 +155,7 @@ type MsgCreatePosition struct {
 
 - **Response**
 
-On succesful response, we receive the actual amounts of each token used to
+On successful response, we receive the actual amounts of each token used to
 create the liquidityCreated number of shares in the given range.
 
 ```go
diff --git a/docs/overview/integrate/registration.md b/docs/overview/integrate/registration.md
index 39141c415..74d9a3cc7 100644
--- a/docs/overview/integrate/registration.md
+++ b/docs/overview/integrate/registration.md
@@ -16,7 +16,7 @@ To ensure a complete integration with Osmosis Zone and related apps, see the [Os
 
 ### Required Skills
 
-Basic understanding of GitHub, knowing how to fork a respository, create a branch, commit changes, and submit a Pull Request
+Basic understanding of GitHub, knowing how to fork a repository, create a branch, commit changes, and submit a Pull Request
 
 ## Step 1: Register to the Cosmos Chain Registry
 
@@ -103,7 +103,7 @@ The Osmosis Labs' Assetlist Registry is used to serve asset metadata displayed o
     - Generally describes to the 'path' (IBC hops) that the asset takes to get to Osmosis
       - Every IBC hop is described in the path, including destination chain port and destination chain channel-id
     - Used as input for the IBC Hash function to determine the asset denomination on the destination chain.
-      - IBC denoms alway appear as: 'ibc/{SHA256 HASH of IBC Path}'
+      - IBC denoms always appear as: 'ibc/{SHA256 HASH of IBC Path}'
     - In some rare cases, some characters in the source chain's base_denom or replaced with other characters.
   - Whether the Asset is bridged (not referring to IBC transfers)
 
@@ -177,4 +177,4 @@ The Osmosis Labs' Assetlist Registry is used to serve asset metadata displayed o
 
 ## Step 3 (optional): Complete the Asset Integration
 
-To create an ideal user experience when interacting with an Asset on Osmosios Zone, it is best to ensure that all metadata is registered, dependend data sources have all data about the asset, and that there is sufficient and efficient liquidity of the asset on Osmosis. See [LISTING.md](https://github.com/osmosis-labs/assetlists/blob/main/LISTING.md) for details.
+To create an ideal user experience when interacting with an Asset on Osmosios Zone, it is best to ensure that all metadata is registered, dependent data sources have all data about the asset, and that there is sufficient and efficient liquidity of the asset on Osmosis. See [LISTING.md](https://github.com/osmosis-labs/assetlists/blob/main/LISTING.md) for details.
diff --git a/docs/overview/integrate/rpc.md b/docs/overview/integrate/rpc.md
index dc9e2df3c..8b5d050c3 100644
--- a/docs/overview/integrate/rpc.md
+++ b/docs/overview/integrate/rpc.md
@@ -4,13 +4,13 @@ sidebar_position: 12
 
 # Interact with RPC endpoints
 
-As shown on the RPC specifications, there are different endpoints to communicate with the Osmosis chain. Unlike the LCD rest api, the RPC endpoints provide genereic endpoints to communicate with the various modules available. For example the [ABCI Query](/api?v=RPC#/operations/abci_query) allows you the query different data from Osmosis.
+As shown on the RPC specifications, there are different endpoints to communicate with the Osmosis chain. Unlike the LCD rest api, the RPC endpoints provide generic endpoints to communicate with the various modules available. For example the [ABCI Query](/api?v=RPC#/operations/abci_query) allows you the query different data from Osmosis.
 
 For more information please read generating, [signing and boradcasting transactions.] https://docs.cosmos.network/v0.46/run-node/txs.html on the cosmos-sdk docs. 
 
 ## Querying the ABCI Query with Javascript via Telescope
 
-If you are looking to query, sign and broadcast transactions using Javascript. Telescope and OsmoJS make this very easy. The following is a very simple example of you could acomplish this using Telescope.
+If you are looking to query, sign and broadcast transactions using Javascript. Telescope and OsmoJS make this very easy. The following is a very simple example of you could accomplish this using Telescope.
 
 ## Setting up Telescope
 ```bash
diff --git a/docs/overview/validate/validating-testnet.md b/docs/overview/validate/validating-testnet.md
index 27a22bc94..8d13f90c6 100644
--- a/docs/overview/validate/validating-testnet.md
+++ b/docs/overview/validate/validating-testnet.md
@@ -91,7 +91,7 @@ If you inspect your `create-validator` transaction in the explorer, and see the
 out of gas in location: WritePerByte; gasWanted: 177140, gasUsed: 177979: out of gas
 ```
 
-Please try subsituting:
+Please try substituting:
 ```
 --gas="auto" \
 --gas-prices="0.0025uosmo"
diff --git a/docs/telescope/README.md b/docs/telescope/README.md
index 8440d6307..faa97ebe6 100644
--- a/docs/telescope/README.md
+++ b/docs/telescope/README.md
@@ -41,7 +41,7 @@ The following blockchain libraries (generated by Telescope) are available via np
     - [Transpile](#transpile)
     - [Build](#build)
 - [Usage](#usage)
-  - [Programatic Usage](#programatic-usage)
+  - [Programmatic Usage](#programatic-usage)
   - [Options](#options)
     - [Amino Encoding](#amino-encoding)
     - [Prototypes Options](#prototypes-options)
@@ -49,7 +49,7 @@ The following blockchain libraries (generated by Telescope) are available via np
     - [LCD Client Options](#lcd-client-options)
     - [RPC Client Options](#rpc-client-options)
     - [Stargate Client Options](#stargate-client-options)
-    - [Typings and Formating](#typings-and-formating)
+    - [Typings and Formatting](#typings-and-formating)
     - [Protobuf parser](#protobuf-parser)
     - [Typescript Disabling](#typescript-disabling)
     - [ESLint Disabling](#eslint-disabling)
@@ -132,11 +132,11 @@ You should now see some `.ts` files generated in `./src`. These are the real sou
 
 ### Build
 
-Finally, run `install` and `buidl` to generate the JS and types for publishing your module to npm.
+Finally, run `install` and `build` to generate the JS and types for publishing your module to npm.
 
 ```sh
 yarn install
-yarn buidl
+yarn build
 ```
 
 Now you should have code inside of your `./src` folder, ready for publishing via `npm publish`. Or, if you used the defaults, you can start developing and your code can be imported from `./src/codegen`;
@@ -275,7 +275,7 @@ See [RPC Clients](#rpc-clients) for more info.
 | -------------------------------------------- | --------------------------------------------------------------  | ---------|
 | `stargateClients.includeCosmosDefaultTypes`  | if true, will include the cosmjs defaults with stargate clients | `true` (except cosmos package) |
 
-### Typings and Formating
+### Typings and Formatting
 
 | option                                    | description                                                     | defaults  | 
 | ----------------------------------------- | --------------------------------------------------------------  | --------- |
diff --git a/src/theme/MDXComponents.js b/src/theme/MDXComponents.js
index d3b3877a9..68d8b580c 100644
--- a/src/theme/MDXComponents.js
+++ b/src/theme/MDXComponents.js
@@ -11,7 +11,7 @@ import PropsTable from '../components/PropsTable';
 import ComponentsGrid from '../components/ComponentsGrid';
 
 export default {
-  // Re-use the default mapping
+  // Reuse the default mapping
   ...MDXComponents,
 
   Tabs,
diff --git a/static/api/DATA.yaml b/static/api/DATA.yaml
index 8bc9e9388..3fdfd9a7b 100644
--- a/static/api/DATA.yaml
+++ b/static/api/DATA.yaml
@@ -64,7 +64,7 @@ paths:
       description: |-
         List all existing paths with pending packets, last tx and since when (in minutes)
            
-        optionnal: filter by dex
+        optional: filter by dex
       operationId: ibc_all
       parameters:
         - required: false
@@ -733,7 +733,7 @@ paths:
       tags:
         - fees
       summary: Fees Spent Pool
-      description: fees paid on 24h and 7d timeframe from a choosen pools
+      description: fees paid on 24h and 7d timeframe from a chosen pools
       operationId: fees_spent_pool
       parameters:
         - required: true
diff --git a/static/api/IBCGO.yaml b/static/api/IBCGO.yaml
index a0d9d0003..6408fad28 100644
--- a/static/api/IBCGO.yaml
+++ b/static/api/IBCGO.yaml
@@ -4316,7 +4316,7 @@ paths:
       - name: latest_height
         in: query
         description: |-
-          latest_height overrrides the height field and queries the latest stored
+          latest_height overrides the height field and queries the latest stored
           ConsensusState.
         schema:
           type: boolean
@@ -5440,7 +5440,7 @@ paths:
                                 items:
                                   type: string
                             description: |-
-                              Version defines the versioning scheme used to negotiate the IBC verison in
+                              Version defines the versioning scheme used to negotiate the IBC version in
                               the connection handshake.
                         state:
                           type: string
@@ -5714,7 +5714,7 @@ paths:
                               items:
                                 type: string
                           description: |-
-                            Version defines the versioning scheme used to negotiate the IBC verison in
+                            Version defines the versioning scheme used to negotiate the IBC version in
                             the connection handshake.
                       state:
                         type: string
@@ -11008,7 +11008,7 @@ components:
               signatures required by gogoproto.
     ibc.core.channel.v1.PacketId:
       title: |-
-        PacketId is an identifer for a unique Packet
+        PacketId is an identifier for a unique Packet
         Source chains refer to packets by source port/channel
         Destination chains refer to packets by destination port/channel
       type: object
@@ -12344,7 +12344,7 @@ components:
                 items:
                   type: string
             description: |-
-              Version defines the versioning scheme used to negotiate the IBC verison in
+              Version defines the versioning scheme used to negotiate the IBC version in
               the connection handshake.
         state:
           type: string
@@ -12446,7 +12446,7 @@ components:
                 items:
                   type: string
             description: |-
-              Version defines the versioning scheme used to negotiate the IBC verison in
+              Version defines the versioning scheme used to negotiate the IBC version in
               the connection handshake.
         state:
           type: string
@@ -12865,7 +12865,7 @@ components:
                     items:
                       type: string
                 description: |-
-                  Version defines the versioning scheme used to negotiate the IBC verison in
+                  Version defines the versioning scheme used to negotiate the IBC version in
                   the connection handshake.
             state:
               type: string
@@ -12974,7 +12974,7 @@ components:
                       items:
                         type: string
                   description: |-
-                    Version defines the versioning scheme used to negotiate the IBC verison in
+                    Version defines the versioning scheme used to negotiate the IBC version in
                     the connection handshake.
               state:
                 type: string
@@ -13095,7 +13095,7 @@ components:
           items:
             type: string
       description: |-
-        Version defines the versioning scheme used to negotiate the IBC verison in
+        Version defines the versioning scheme used to negotiate the IBC version in
         the connection handshake.
     ibc.core.channel.v1.Channel:
       type: object
diff --git a/static/api/LCD.yaml b/static/api/LCD.yaml
index 3c022f977..1a1d32ed8 100644
--- a/static/api/LCD.yaml
+++ b/static/api/LCD.yaml
@@ -3274,7 +3274,7 @@ components:
     cosmos.distribution.v1beta1.QueryValidatorCommissionResponse:
       properties:
         commission:
-          description: commission defines the commision the validator received.
+          description: commission defines the commission the validator received.
           properties:
             commission:
               items:
@@ -7804,7 +7804,7 @@ components:
 
         gas to be used by the transaction. The ratio yields an effective "gasprice",
 
-        which must be above some miminum to be accepted into the mempool.'
+        which must be above some minimum to be accepted into the mempool.'
       properties:
         amount:
           items:
@@ -10939,7 +10939,7 @@ components:
         lockable_durations:
           items:
             type: string
-          title: Time durations that users can lock coins for in order to recieve
+          title: Time durations that users can lock coins for in order to receive
             rewards
           type: array
       type: object
@@ -10959,7 +10959,7 @@ components:
               denom:
                 type: string
             type: object
-          title: 'Estimated coin rewards that will be recieved at provided address
+          title: 'Estimated coin rewards that will be received at provided address
 
             from specified locks between current time and end epoch'
           type: array
@@ -12911,7 +12911,7 @@ components:
 
             to be set as the Time-weighted-average-osmo-backing for the entire duration
 
-            of epoch N-1. (Thereby locking whats in use for epoch N as based on the
+            of epoch N-1. (Thereby locking what's in use for epoch N as based on the
             prior
 
             epochs rewards) However for now, this is not the TWAP but instead the
@@ -13069,7 +13069,7 @@ components:
 
         to be set as the Time-weighted-average-osmo-backing for the entire duration
 
-        of epoch N-1. (Thereby locking whats in use for epoch N as based on the prior
+        of epoch N-1. (Thereby locking what's in use for epoch N as based on the prior
 
         epochs rewards) However for now, this is not the TWAP but instead the spot
 
@@ -21367,7 +21367,7 @@ paths:
               schema:
                 properties:
                   commission:
-                    description: commission defines the commision the validator received.
+                    description: commission defines the commission the validator received.
                     properties:
                       commission:
                         items:
@@ -24093,7 +24093,7 @@ paths:
         schema:
           format: uint64
           type: string
-      - description: voter defines the oter address for the proposals.
+      - description: voter defines the other address for the proposals.
         in: path
         name: voter
         required: true
@@ -30186,7 +30186,7 @@ paths:
     get:
       operationId: PoolsWithFilter
       parameters:
-      - description: 'String of the coins in single string seperated by comma. Ex)
+      - description: 'String of the coins in single string separated by comma. Ex)
 
           10uatom,100uosmo.'
         in: query
@@ -33251,7 +33251,7 @@ paths:
                     items:
                       type: string
                     title: Time durations that users can lock coins for in order to
-                      recieve rewards
+                      receive rewards
                     type: array
                 type: object
           description: A successful response.
@@ -33391,7 +33391,7 @@ paths:
                         denom:
                           type: string
                       type: object
-                    title: 'Estimated coin rewards that will be recieved at provided
+                    title: 'Estimated coin rewards that will be received at provided
                       address
 
                       from specified locks between current time and end epoch'
@@ -37326,7 +37326,7 @@ paths:
                       to be set as the Time-weighted-average-osmo-backing for the
                       entire duration
 
-                      of epoch N-1. (Thereby locking whats in use for epoch N as based
+                      of epoch N-1. (Thereby locking what's in use for epoch N as based
                       on the prior
 
                       epochs rewards) However for now, this is not the TWAP but instead
diff --git a/static/api/RPC.yaml b/static/api/RPC.yaml
index 2e8cece61..88dfefef3 100644
--- a/static/api/RPC.yaml
+++ b/static/api/RPC.yaml
@@ -71,7 +71,7 @@ tags:
   - name: Websocket
     description: Subscribe/unsubscribe are reserved for websocket events.
   - name: Info
-    description: Informations about the node APIs
+    description: Information about the node APIs
   - name: Tx
     description: Transactions broadcast APIs
   - name: ABCI
@@ -1375,7 +1375,7 @@ paths:
       parameters:
         - in: query
           name: hash
-          description: transaction Hash to retrive
+          description: transaction Hash to retrieve
           required: true
           schema:
             type: string
@@ -3172,9 +3172,9 @@ components:
               example: 2
           type: object
 
-    ###### Reuseable types ######
+    ###### Reusable types ######
 
-    # Validator type with proposer prioirty
+    # Validator type with proposer priority
     ValidatorPriority:
       type: object
       properties: