diff --git a/docs/cosmwasm/cosmwasm-verify-contract.md b/docs/cosmwasm/cosmwasm-verify-contract.md index 0698a089d..c1a4f4634 100644 --- a/docs/cosmwasm/cosmwasm-verify-contract.md +++ b/docs/cosmwasm/cosmwasm-verify-contract.md @@ -34,7 +34,7 @@ osmosisd query wasm contract-state raw osmo1mpf0guu0t363xrshhedandypq003ahzaxvsx ``` What in the world is `636F6E74726163745F696E666F`? 😕 -ContractInfo is must be stored under "contract_info" key which translates to "636F6E74726163745F696E666F" in hex format. As documented [here](https://lib.rs/crates/cw2). +ContractInfo must be stored under "contract_info" key which translates to "636F6E74726163745F696E666F" in hex format. As documented [here](https://lib.rs/crates/cw2). Output: diff --git a/docs/cosmwasm/cw-orch.md b/docs/cosmwasm/cw-orch.md index 7605d3851..db407719e 100644 --- a/docs/cosmwasm/cw-orch.md +++ b/docs/cosmwasm/cw-orch.md @@ -9,7 +9,7 @@ sidebar_position: 9 cw-orchestrator is the most advanced scripting, testing, and deployment framework for CosmWasm smart-contracts. It makes it easy to write cross-environment compatible code for [cw-multi-test](https://github.com/CosmWasm/cw-multi-test), [Osmosis Test Tube](https://github.com/osmosis-labs/test-tube), [Starship](https://github.com/cosmology-tech/starship) (alpha), and **live networks**, significantly reducing code duplication and test-writing time. -Get ready to change the way you interact with contracts and simplify you smart-contracts journey. The following steps will allow you to integrate `cw-orch` and write clean code such as: +Get ready to change the way you interact with contracts and simplify your smart-contracts journey. The following steps will allow you to integrate `cw-orch` and write clean code such as: ```rust counter.upload()?; @@ -133,7 +133,7 @@ Learn more about the content of the interface creation specifics in the [`cw-orc ### Interaction helpers -cw-orchestrator provides a additional macros that simplify contract calls and queries. The macro implements functions on the interface for each variant of the contract's `ExecuteMsg` and `QueryMsg`. +cw-orchestrator provides an additional macros that simplify contract calls and queries. The macro implements functions on the interface for each variant of the contract's `ExecuteMsg` and `QueryMsg`. Enabling this functionality is very straightforward. Find your `ExecuteMsg` and `QueryMsg` definitions (in `msg.rs` in our example) and add the `ExecuteFns` and `QueryFns` derive macros to them like below: diff --git a/docs/cosmwasm/javascript.md b/docs/cosmwasm/javascript.md index 755a052cf..41098b531 100644 --- a/docs/cosmwasm/javascript.md +++ b/docs/cosmwasm/javascript.md @@ -163,7 +163,7 @@ The output should look like this: ![](contract_details.png) ## Get the count from the contract -The contract we are interacting with has a few simple functions. 'get_count', 'increment' and 'reset'. These two functions can be called via by using the `queryContractSmart` method. +The contract we are interacting with has a few simple functions. 'get_count', 'increment' and 'reset'. These two functions can be called by using the `queryContractSmart` method. :::tip Please note there is a complete guide on how to upload the example contract on localOsmosis [here](./local/localosmosis.md). diff --git a/docs/cosmwasm/testnet/cosmwasm-beaker.md b/docs/cosmwasm/testnet/cosmwasm-beaker.md index fb5948aa1..9a9363503 100644 --- a/docs/cosmwasm/testnet/cosmwasm-beaker.md +++ b/docs/cosmwasm/testnet/cosmwasm-beaker.md @@ -6,7 +6,7 @@ sidebar_position: 2 # Cosmwasm & Beaker ## Deploying Cosmwasm Contracts to the testnet with Beaker -The following guide will show you how to create and deploy a Cosmwasm smart contract to the Osmosis testnet. The testnet is permisonless by default to allow developers to test their contracts on a live environment. The Osmosis mainnet is permissioned meaning that you will need to submit a governance proposal in order to deploy to it. +The following guide will show you how to create and deploy a Cosmwasm smart contract to the Osmosis testnet. The testnet is permissionless by default to allow developers to test their contracts on a live environment. The Osmosis mainnet is permissioned meaning that you will need to submit a governance proposal in order to deploy to it. ### Requirements - [Rust](https://www.rust-lang.org/tools/install) @@ -33,15 +33,15 @@ For detailed information about Beaker [click here](https://github.com/osmosis-la ### Your first CosmWasm contract with Beaker -After that we can create new contract (the command uses template from [cw-template](https://github.com/InterWasm/cw-template)) +After that we can create a new contract (the command uses template from [cw-template](https://github.com/InterWasm/cw-template)) ```sh cd counter-dapp beaker wasm new counter ``` -### Deploy contract on permisionless network -The testnet is permisionless by default in order to allow developers to easily deploy contracts. +### Deploy contract on permissionless network +The testnet is permissionless by default in order to allow developers to easily deploy contracts. ```sh beaker wasm deploy counter --signer-account test1 --network testnet --no-wasm-opt --raw '{ "count": 0 }' --label 'My first Beaker Contract' @@ -128,10 +128,10 @@ https://testnet.mintscan.io/osmosis-testnet/proposals/196 https://lcd-test.osmosis.zone/cosmos/gov/v1beta1/proposals/196 ``` -Note how the min_deposit was `500000000uosmo` that's why our prop.yml had `500000000uosmo`. If the deposit requirement is not met, then additional funds need to be send to the proposal. +Note how the min_deposit was `500000000uosmo` that's why our prop.yml had `500000000uosmo`. If the deposit requirement is not met, then additional funds need to be sent to the proposal. #### Proposal period -On the testnet the voting period is very short to allow developers to move quickly with their testing, as you can see in this case it's `3 minutes`. This means you must vote within the next 3 minutes for your proposal to pass. In mainet the voting period is usually several days. If you take longer than 3 minutes, then you will get an error letting you know that the voting period has passed. +On the testnet the voting period is very short to allow developers to move quickly with their testing, as you can see in this case it's `3 minutes`. This means you must vote within the next 3 minutes for your proposal to pass. In mainnet the voting period is usually several days. If you take longer than 3 minutes, then you will get an error letting you know that the voting period has passed. ``` ├── voting_start_time: 2022-07-06T18:45:06Z @@ -149,7 +149,7 @@ Run the following command to vote from beaker beaker wasm proposal vote --option yes counter --signer-account test1 --network testnet ``` -Even though the testnet is configured as permisionless, it's important to understanding the voting process. We need validators to vote for your proposal in order to reach the quorum. We created a simple utility in our faucet that will allow you to request a validator with enough voting power to vote for your proposal as well. +Even though the testnet is configured as permissionless, it's important to understand the voting process. We need validators to vote for your proposal in order to reach the quorum. We created a simple utility in our faucet that will allow you to request a validator with enough voting power to vote for your proposal as well. Please visit: @@ -170,7 +170,7 @@ In the examples above we used the test1 account to sign transactions. However, B - `--signer-keyring` use the OS secure store as backend to securely store your key. To manage them, you can find more information [here](../../beaker/commands/beaker_key). ### Using the OS keyring -Let's dive a little deeper on how to use the OS keyring in order to sing a transaction with your OS keyring. +Let's dive a little deeper on how to use the OS keyring in order to sign a transaction with your OS keyring. First of all you can import an account by running: diff --git a/docs/cosmwasm/testnet/cosmwasm-deployment.md b/docs/cosmwasm/testnet/cosmwasm-deployment.md index b5493b156..f9a60ddf5 100644 --- a/docs/cosmwasm/testnet/cosmwasm-deployment.md +++ b/docs/cosmwasm/testnet/cosmwasm-deployment.md @@ -1,5 +1,5 @@ # Cosmwasm testnet deployment -The following is a quick guide that shows the basics of deploying a contract to a Osmosis Testnet (`osmo-test-5`). It covers: +The following is a quick guide that shows the basics of deploying a contract to an Osmosis Testnet (`osmo-test-5`). It covers: - Initial Setup - Setup Rust @@ -20,13 +20,13 @@ The following is a quick guide that shows the basics of deploying a contract to - Execute the contract :::tip -Please note this a detailed guide on how to deploy via `osmosisd`, it also covers additional tooling and useful tips. You can also deploy to testnet with [Beaker](./cosmwasm-beaker.md) with a couple of commands. +Please note this is a detailed guide on how to deploy via `osmosisd`, it also covers additional tooling and useful tips. You can also deploy to testnet with [Beaker](./cosmwasm-beaker.md) with a couple of commands. ::: ## Initial Setup -This tutorial uses a Osmosis specific development tools to deploy contracts to Osmosis Testnet(`osmo-test-5`). +This tutorial uses an Osmosis specific development tools to deploy contracts to Osmosis Testnet(`osmo-test-5`). ### Setup Rust @@ -95,7 +95,7 @@ You need some tokens named `OSMO`(`uosmo`) in your address to interact with the You can request tokens from the official faucet at [faucet.osmosis.zone](https://faucet.osmosis.zone) #### Discord Faucet -Youcan also participate in the [Osmosis discord](https://discord.com/invite/osmosis) to request a faucet of the Osmosis Testnet. After gaining access to the testnet channel on the `#roles` channel of the discord, you can request a testnet token by sending the following message on the `#faucet` channel: +You can also participate in the [Osmosis discord](https://discord.com/invite/osmosis) to request a faucet of the Osmosis Testnet. After gaining access to the testnet channel on the `#roles` channel of the discord, you can request a testnet token by sending the following message on the `#faucet` channel: ```bash $request
@@ -325,4 +325,4 @@ In the Write Contract section, type `increment` messages and the OSMO to pay and ![](https://user-images.githubusercontent.com/70956926/172300485-4d66b5a9-1082-48da-ba1c-b979206f277e.png) -Congratulations! Now you deployed your wasm smart contract on Osmosis Testnet successfully. \ No newline at end of file +Congratulations! Now you deployed your wasm smart contract on Osmosis Testnet successfully. diff --git a/docs/osmosis-core/guides/create-ibc-pool.md b/docs/osmosis-core/guides/create-ibc-pool.md index 56e996357..b5158570b 100644 --- a/docs/osmosis-core/guides/create-ibc-pool.md +++ b/docs/osmosis-core/guides/create-ibc-pool.md @@ -5,9 +5,9 @@ sidebar_position: 9 # How to create a new pool with IBC assets -Osmosis is a automated market maker blockchain. This means any IBC-enabled zone can add its token as an asset to be traded on Osmosis AMM completely permissionlessly. Because Osmosis is fundamentally designed as an IBC-native AMM that trades IBC tokens, rather than tokens issued on the Osmosis zone, there are additional nuances to understand and steps to be taken in order to ensure your asset is supported by Osmosis. +Osmosis is an automated market maker blockchain. This means any IBC-enabled zone can add its token as an asset to be traded on Osmosis AMM completely permissionlessly. Because Osmosis is fundamentally designed as an IBC-native AMM that trades IBC tokens, rather than tokens issued on the Osmosis zone, there are additional nuances to understand and steps to be taken in order to ensure your asset is supported by Osmosis. -This document lays out the prerequisites and the process that's needed to ensure that your token meets the interchain UX standards set by Osmosis. +This document lays out the prerequisites and the process that's needed to ensure that your token meets the interchain UX standards set by Osmosis. ### Prerequisites 1. Zone must have IBC token transferred enabled (ICS20 standard). @@ -39,7 +39,7 @@ Make a PR to add your chain's entry to the [Cosmos Chain Registry](https://githu Make sure to include at least one reliable RPC, gRPC, REST endpoint behind https. Refer to the [Osmosis entry](https://github.com/cosmos/chain-registry/blob/master/osmosis/chain.json) as an example. ### 2. Setting up and operating relayer to Osmosis -Relayers are responsible of transferring IBC packets between Osmosis chain and the native chain of an asset. All Osmosis 'deposits' and 'withdrawals' are IBC transfers which dedicated relayers process. +Relayers are responsible for transferring IBC packets between Osmosis chain and the native chain of an asset. All Osmosis 'deposits' and 'withdrawals' are IBC transfers which dedicated relayers process. To ensure fungibility amongst IBC assets, the frontend will assume social consensus have been achieved and designate one specific channel between Osmosis and the native chain as the primary channel for all IBC token transfers. Multiple relayers can be active on the same channel, and for the sake of redundancy and increased resilience we recommend having multiple relayers actively relaying packets. It is recommended to initialize the channel as an unordered IBC channel, rather than an ordered IBC channel. diff --git a/docs/osmosis-core/modules/ibc-rate-limit/README.md b/docs/osmosis-core/modules/ibc-rate-limit/README.md index 103bbd88e..f032a8cc0 100644 --- a/docs/osmosis-core/modules/ibc-rate-limit/README.md +++ b/docs/osmosis-core/modules/ibc-rate-limit/README.md @@ -201,7 +201,7 @@ The contract also supports quotas on a custom channel called "any" that is check transfer channel or the "any" channel have a quota that has been filled, the transaction will be rate limited. #### Notes on Denom -We always use the the denom as represented on Osmosis. For native assets that is the local denom, and for non-native +We always use the denom as represented on Osmosis. For native assets that is the local denom, and for non-native assets it's the "ibc" prefix and the sha256 hash of the denom trace (`ibc/...`). ##### Sends @@ -304,4 +304,4 @@ Not yet highlighted * Could imagine tieng it into looking at AMM volatility, or off-chain oracles * but these are both things we should be wary of security bugs in. * Maybe [constraint based programming with tracking of provenance](https://youtu.be/HB5TrK7A4pI?t=2852) as a solution -* Analyze changing denom-based rate limits, to just overall withdrawal amount for Osmosis \ No newline at end of file +* Analyze changing denom-based rate limits, to just overall withdrawal amount for Osmosis diff --git a/docs/osmosis-core/modules/incentives/README.md b/docs/osmosis-core/modules/incentives/README.md index 1b4d8d50c..c4a7f3306 100644 --- a/docs/osmosis-core/modules/incentives/README.md +++ b/docs/osmosis-core/modules/incentives/README.md @@ -10,9 +10,9 @@ Anyone can create gauge and add rewards to the gauge, there is no way to take it There are two kinds of `gauges`, perpetual and non-perpetual ones. -- Non perpetual ones get removed from active queue after the the distribution period finish but perpetual ones persist. +- Non perpetual ones get removed from active queue after the distribution period finish but perpetual ones persist. - For non perpetual ones, they distribute the tokens equally per epoch during the `gauge` is in the active period. -- For perpetual ones, it distribute all the tokens at a single time and somewhere else put the tokens regularly to distribute the tokens, it's mainly used to distribute minted OSMO tokens to LP token stakers. +- For perpetual ones, it distributes all the tokens at a single time and somewhere else put the tokens regularly to distribute the tokens, it's mainly used to distribute minted OSMO tokens to LP token stakers. ## Contents @@ -74,7 +74,7 @@ message QueryCondition { message Gauge { uint64 id = 1; // unique ID of a Gauge - QueryCondition distribute_to = 2; // distribute condition of a lock which meet one of these conditions + QueryCondition distribute_to = 2; // distribute condition of a lock which meets one of these conditions repeated cosmos.base.v1beta1.Coin coins = 3; // can distribute multiple coins google.protobuf.Timestamp start_time = 4; // condition for lock start time, not valid if unset value uint64 num_epochs_paid_over = 5; // number of epochs distribution will be done @@ -279,7 +279,7 @@ The incentives module contains the following parameters: | -------------------- | ------ | -------- | | DistrEpochIdentifier | string | "weekly" | -Note: DistrEpochIdentifier is a epoch identifier, and module distribute +Note: DistrEpochIdentifier is an epoch identifier, and module distribute rewards at the end of epochs. As `epochs` module is handling multiple epochs, the identifier is required to check if distribution should be done at `AfterEpochEnd` hook diff --git a/docs/osmosis-core/modules/superfluid/README.md b/docs/osmosis-core/modules/superfluid/README.md index e281b821e..aa44fa20b 100644 --- a/docs/osmosis-core/modules/superfluid/README.md +++ b/docs/osmosis-core/modules/superfluid/README.md @@ -160,16 +160,16 @@ SyntheticLockups are synthetic forms of PeriodLocks, but different in the sense that they store suffix, which is a combination of bonding/unbonding status + validator address. This is mainly used to track whether an individual lock that has been superfluid staked has an -bonding status or a unbonding status from the staking delegations. +bonding status or an unbonding status from the staking delegations. ### Intermediary Account Intermediary Accounts establish the connections between the superfluid staked locks and delegations to the validator. Intermediary accounts -exists for every denom + validator combination, so that it would group +exist for every denom + validator combination, so that it would group locks with the same denom + validator selection. Superfluid staking a lock would mint equivalent amount of OSMO of the lock and send it to the -intermediary account and the intermediarry accounts would be delegating +intermediary account and the intermediary accounts would be delegating to the specified validator. ### Intermediary Account Connection @@ -194,7 +194,7 @@ Lots of questions to be answered here ### Dedicated Gauges -Each intermediary account has has dedicated gauge where it sends the +Each intermediary account has a dedicated gauge where it sends the delegation rewards to. Gauges are distributing the rewards to end users at the end of the epoch. @@ -340,7 +340,7 @@ This message does all the functionality of `MsgSuperfluidUndelegate` but also starts unbonding the underlying lock as well, allowing both the unstaking and unlocking to complete at the same time. Without using this function, a user will not be able to start unbonding their underlying -lock until after the the unstaking has finished. +lock until after the unstaking has finished. **State Modifications:** @@ -612,7 +612,7 @@ currently contains: - `MinimumRiskFactor` which is an sdk.Dec that represents the discount to apply to all superfluid staked modules when calculating their staking power. For example, if a specific denom has an OSMO - equivalent value of 100 OSMO, but the the `MinimumRiskFactor` param + equivalent value of 100 OSMO, but the `MinimumRiskFactor` param is 0.05, then the denom will only get 95 OSMO worth of staking power when staked. @@ -984,4 +984,4 @@ the `IntermediaryAccount` will be slashed by less than the TODO - expand on this Uses `lockup` accumulator to find total amount of synthetic locks for a given `IntermediaryAccount` (Superfluid Asset + -Validator pair) \ No newline at end of file +Validator pair) diff --git a/docs/overview/features/ibc-rate-limit.md b/docs/overview/features/ibc-rate-limit.md index 79cb55e58..fcaa03301 100644 --- a/docs/overview/features/ibc-rate-limit.md +++ b/docs/overview/features/ibc-rate-limit.md @@ -18,7 +18,7 @@ The cosmwasm contract then has all of the actual IBC rate limiting logic. The Cosmwasm code can be found in the [`contracts`](./contracts/) package, with bytecode findable in the [`bytecode`](./bytecode/) folder. The cosmwasm VM usage allows Osmosis chain governance to choose to change this safety control with no hard forks, via a parameter change proposal, a great mitigation for faster threat adaptavity. The status of the module is being in a state suitable for some initial governance settable rate limits for high value bridged assets. -Its not in its long term / end state for all channels by any means, but does act as a strong protection we +It's not in its long term / end state for all channels by any means, but does act as a strong protection we can instantiate today for high value IBC connections. ## Motivation @@ -119,7 +119,7 @@ As mentioned at the beginning of the README, the go code is a relatively minimal ### Go Middleware -To achieve this, the middleware needs to implement the `porttypes.Middleware` interface and the +To achieve this, the middleware needs to implement the `porttypes.Middleware` interface and the `porttypes.ICS4Wrapper` interface. This allows the middleware to send and receive IBC messages by wrapping any IBC module, and be used as an ICS4 wrapper by a transfer module (for sending packets or writing acknowledgements). @@ -156,8 +156,8 @@ Something to keep in mind with all of the code, is that we have to reason separa (Error ACK can reuse the same code as timeout) TODO: Spend more time on sudo messages in the following description. We need to better describe how we map the quota concepts onto the code. -Need to describe how we get the quota beginning balance, and that its different for sends and receives. -Explain intracacies of tracking that a timeout and/or ErrorAck must appear from the same quota, else we ignore its update to the quotas. +Need to describe how we get the quota beginning balance, and that it's different for sends and receives. +Explain intricacies of tracking that a timeout and/or ErrorAck must appear from the same quota, else we ignore its update to the quotas. The tracking contract uses the following concepts @@ -205,7 +205,7 @@ The contract also supports quotas on a custom channel called "any" that is check transfer channel or the "any" channel have a quota that has been filled, the transaction will be rate limited. #### Notes on Denom -We always use the the denom as represented on Osmosis. For native assets that is the local denom, and for non-native +We always use the denom as represented on Osmosis. For native assets that is the local denom, and for non-native assets it's the "ibc" prefix and the sha256 hash of the denom trace (`ibc/...`). ##### Sends @@ -220,7 +220,7 @@ is built on the `relay.SendTransfer()` in the transfer module and then passed to ##### Receives -This behaves slightly different if the asset is an osmosis asset that was sent to the counterparty and is being +This behaves slightly differently if the asset is an osmosis asset that was sent to the counterparty and is being returned to the chain, or if the asset is being received by the chain and originates on the counterparty. In ibc this is called being a "source" or a "sink" respectively. @@ -237,7 +237,7 @@ We have iterated on different strategies for calculating the channel value. Our * For non-native tokens (`ibc/...`), the channel value should be the supply of those tokens in Osmosis * For native tokens, the channel value should be the total amount of tokens in escrow across all ibc channels -The later ensures the limits are lower and represent the amount of native tokens that exist outside Osmosis. This is +The latter ensures the limits are lower and represent the amount of native tokens that exist outside Osmosis. This is beneficial as we assume the majority of native tokens exist on the native chain and the amount "normal" ibc transfers is proportional to the tokens that have left the chain. @@ -311,4 +311,4 @@ Not yet highlighted * Analyze changing denom-based rate limits, to just overall withdrawal amount for Osmosis ## Repository -For more an in-depth docs and implementation, please visit: https://github.com/osmosis-labs/osmosis/tree/main/x/ibc-rate-limit \ No newline at end of file +For more in-depth docs and implementation, please visit: https://github.com/osmosis-labs/osmosis/tree/main/x/ibc-rate-limit