feat: fix spells

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)

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
 

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
 

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.  
    > 

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)

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";

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

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: 
 

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))

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
 

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,

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.

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

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 {

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

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