docs(build): CosmWasm Quickstart and Build a Dapp guides (MTN-115)

docs/build/chain/concentrated-liquidity/README.md

@@ -404,8 +404,8 @@ type MsgCreatePosition struct {
  UpperTick       int64
  TokenDesired0   types.Coin
  TokenDesired1   types.Coin
- TokenMinAmount0 sdk.Int
- TokenMinAmount1 sdk.Int
+ TokenMinAmount0 osmomath.Int
+ TokenMinAmount1 osmomath.Int
 }
 ```
 
@@ -417,10 +417,10 @@ create the liquidityCreated number of shares in the given range.
 ```go
 type MsgCreatePositionResponse struct {
  PositionId  uint64
- Amount0 sdk.Int
- Amount1 sdk.Int
+ Amount0 osmomath.Int
+ Amount1 osmomath.Int
  JoinTime time.Time
- LiquidityCreated sdk.Dec
+ LiquidityCreated osmomath.Dec
 
 }
 ```
@@ -444,7 +444,7 @@ associated with the position are still retained until a user claims them manuall
 type MsgWithdrawPosition struct {
  PositionId      uint64
  Sender          string
- LiquidityAmount sdk.Dec
+ LiquidityAmount osmomath.Dec
 }
 ```
 
@@ -455,8 +455,8 @@ for the provided share liquidity amount.
 
 ```go
 type MsgWithdrawPositionResponse struct {
- Amount0 sdk.Int
- Amount1 sdk.Int
+ Amount0 osmomath.Int
+ Amount1 osmomath.Int
 }
 ```
 
@@ -478,7 +478,7 @@ type MsgCreateConcentratedPool struct {
  Denom0                    string
  Denom1                    string
  TickSpacing               uint64
- SpreadFactor                   sdk.Dec
+ SpreadFactor                   osmomath.Dec
 }
 ```
 
@@ -530,10 +530,10 @@ the original join time so charging is preserved.
 type MsgAddToPosition struct {
  PositionId     uint64
  Sender         string
- Amount0        sdk.Int
- Amount1        sdk.Int
- TokenMinAmount0 sdk.Int
- TokenMinAmount1 sdk.Int
+ Amount0        osmomath.Int
+ Amount1        osmomath.Int
+ TokenMinAmount0 osmomath.Int
+ TokenMinAmount1 osmomath.Int
 }
 ```
 
@@ -676,7 +676,7 @@ and token1 as a result the one that had higher liquidity will end up smaller
 than originally given by the user.
 
 Note that the liquidity used here does not represent an amount of a specific
-token, but the liquidity of the pool itself, represented in `sdk.Dec`.
+token, but the liquidity of the pool itself, represented in `osmomath.Dec`.
 
 Using the provided liquidity, now we calculate the delta amount of both token0
 and token1, using the following equations, where L is the liquidity calculated above:
@@ -695,19 +695,16 @@ Given the parameters needed for calculating the tokens needed for creating a
 position for a given tick, the API in the keeper layer would look like the following:
 
 ```go
-ctx sdk.Context, poolId uint64, owner sdk.AccAddress, amount0Desired,
-amount1Desired, amount0Min, amount1Min sdk.Int,
-lowerTick, upperTick int64, frozenUntil time.Time
 func createPosition(
     ctx sdk.Context,
     poolId uint64,
     owner sdk.AccAddress,
     amount0Desired,
     amount1Desired,
     amount0Min,
-    amount1Min sdk.Int
+    amount1Min osmomath.Int,
     lowerTick,
-    upperTick int64) (amount0, amount1 sdk.Int, sdk.Dec, error) {
+    upperTick int64) (amount0, amount1 osmomath.Int, liquidity osmomath.Dec, err error) {
         ...
 }
 ```
@@ -730,9 +727,8 @@ func (k Keeper) withdrawPosition(
     owner sdk.AccAddress,
     lowerTick,
     upperTick int64,
-    frozenUntil time.Time,
-    requestedLiquidityAmountToWithdraw sdk.Dec)
-    (amtDenom0, amtDenom1 sdk.Int, err error) {
+    requestedLiquidityAmountToWithdraw osmomath.Dec)
+    (amtDenom0, amtDenom1 osmomath.Int, err error) {
     ...
 }
 ```
@@ -788,8 +784,8 @@ From the user perspective, there are two ways to swap:
 Each case has a corresponding message discussed previously in the `x/poolmanager`
 section.
 
-- `MsgSwapExactIn`
-- `MsgSwapExactOut`
+- `MsgSwapExactAmountIn`
+- `MsgSwapExactAmountOut`
 
 Once a message is received by the `x/poolmanager`, it is propagated into a
 corresponding keeper
@@ -856,32 +852,32 @@ type SwapState struct {
  // if in given out, amount of token being swapped out.
  // Initialized to the amount of the token specified by the user.
  // Updated after every swap step.
- amountSpecifiedRemaining sdk.Dec
+ amountSpecifiedRemaining osmomath.Dec
 
  // Amount of the other token that is calculated from the specified token.
  // if out given in, amount of token swapped out.
  // if in given out, amount of token swapped in.
  // Initialized to zero.
  // Updated after every swap step.
- amountCalculated sdk.Dec
+ amountCalculated osmomath.Dec
 
  // Current sqrt price while calculating swap.
  // Initialized to the pool's current sqrt price.
  // Updated after every swap step.
- sqrtPrice sdk.Dec
+ sqrtPrice osmomath.BigDec
  // Current tick while calculating swap.
  // Initialized to the pool's current tick.
  // Updated each time a tick is crossed.
- tick sdk.Int
+ tick int64
  // Current liqudiity within the active tick.
  // Initialized to the pool's current tick's liquidity.
  // Updated each time a tick is crossed.
- liquidity sdk.Dec
+ liquidity osmomath.Dec
 
  // Global spread reward growth per-current swap.
  // Initialized to zero.
  // Updated after every swap step.
- spreadRewardGrowthGlobal sdk.Dec
+ spreadRewardGrowthGlobal osmomath.Dec
 }
 ```
 
@@ -1164,15 +1160,6 @@ tick tracked by the pool is 11_000. The global spread reward growth per unit of
 has increased by 50 units of token one. See more details about the spread reward growth
 in the "Spread Rewards" section.
 
-TODO: Swapping, Appendix B: Compute Swap Step Internals and Math
-
-## Range Orders
-
-> As a trader, I want to be able to execute ranger orders so that I have better
-> control of the price at which I trade
-
-TODO
-
 ## Spread Rewards
 
 > As a an LP, I want to earn spread rewards on my capital so that I am incentivized to
@@ -1197,7 +1184,7 @@ layers of state:
 // Note that this is proto-generated.
 type Pool struct {
     ...
-    SpreadFactor sdk.Dec
+    SpreadFactor osmomath.Dec
 }
 ```
 
@@ -1460,7 +1447,7 @@ some [clever accumulator tricks](https://www.paradigm.xyz/2021/05/liquidity-mini
 this can be designed to ensure that each LP only receives incentives for liquidity they contribute
 to the active tick. This approach is incredible for liquidity depth, which is arguably the most
 important property we need incentives to be able to accommodate. It is also a user flow that
-on-chain market makers are already somewhat familiar with and has enough live examples where
+onchain market makers are already somewhat familiar with and has enough live examples where
 we roughly know that it functions as intended.
 
 ## Our Implementation
@@ -1735,7 +1722,7 @@ the quote asset that has precision of 6 (e.g `uosmo` or `uusdc`).
 
 The true price of PEPE in USDC terms is `0.0000009749`.
 
-In the "on-chain representation", this would be:
+In the "onchain representation", this would be:
 `0.0000009749 * 10**6 / 10**18 = 9.749e-19`
 
 Note that this is below the minimum precision of `sdk.Dec`.

docs/build/chain/cosmwasmpool/README.md

@@ -9,8 +9,9 @@ The module is built on top of the CosmWasm smart contracting platform, which pro
 
 Having pools in CosmWasm provides several benefits, one of which is avoiding the need for chain upgrades when introducing new functionalities or modifying existing ones related to liquidity pools. This advantage is particularly important in the context of speed of development and iteration.
 
-An example of a CosmWasm pool type:
-- [transmuter](https://github.com/osmosis-labs/transmuter)
+Examples of CosmWasm pool types:
+- [transmuter](https://github.com/osmosis-labs/transmuter) (the constant-sum pools behind alloyed assets)
+- [orderbook](https://github.com/osmosis-labs/orderbook) (the SumTree-based onchain orderbook markets)
 
 ## Key Components
 
@@ -46,7 +47,7 @@ To create new CosmWasm Pool, there are 3 modules involved: `x/cosmwasmpool`, `x/
 graph TD;
   Sender((Sender))
 
-  Sender -- create poool --> x/cosmwasmpool
+  Sender -- create pool --> x/cosmwasmpool
   x/cosmwasmpool -- get next & set pool id --> x/poolmanager
   x/cosmwasmpool -- instantiate contract --> x/wasm
 ```
@@ -304,7 +305,7 @@ Ok(Response::new()
 ```rs
 #[cw_serde]
 pub struct AfterPoolCreated {
-    pub create_pool_guages: Option<CreatePoolGauges>,
+    pub create_pool_gauges: Option<CreatePoolGauges>,
 }
 
 #[cw_serde]
@@ -387,7 +388,7 @@ Note, that in both cases, x/cosmwasmpool module account will act as the admin an
 Proposal Name: `UploadCosmWasmPoolCodeAndWhiteListProposal`
 
 On successful passing of this proposal, the code id of the pool contract will be added to the whitelist.
-As a result, anyone would be able to instantiate a pool contract with this code id when creating a pol.
+As a result, anyone would be able to instantiate a pool contract with this code id when creating a pool.
 No address will be able to maliciously upload a new code id and instantiate a pool contract with it without
 governance approval.
 
@@ -413,7 +414,7 @@ In both cases, if one of the pools specified by the given `poolID` does not exis
 
 The reason for having `poolID`s be a slice of ids is to account for the potential need for emergency migration of all old code ids to new code ids, or simply having the flexibility of migrating multiple older pool contracts to a new one at once when there is a release.
 
-`poolD`s must be at the most size of `PoolMigrationLimit` module parameter. It is configured to 20 at launch.
+`poolID`s must be at the most size of `PoolMigrationLimit` module parameter. It is configured to 20 at launch.
 The proposal fails if more. Note that 20 was chosen arbitrarily to have a constant bound on the number of pools migrated at once.
 
 Inputs

docs/build/chain/downtime-detector/README.md

@@ -3,7 +3,8 @@
 For several use cases, we need a module that can detect when the chain is recovering from downtime. We want to be able to efficiently know "Has it been `RECOVERY_PERIOD` minutes since the chain has been down for `DOWNTIME_PERIOD`", and expose this as a query to contracts.
 
 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
+
+## Suggested Design
 
 There's a couple designs, such as:
 
@@ -15,7 +16,7 @@ There's a couple designs, such as:
 
 Because this will be in important txs for contracts, we need to go with the approach that has minimal query compute, which is the latter. So we explain that in more depth.
 
-We restrict the `DOWNTIME_PERIOD` options that you can query, to be: 30seconds, 1 min, 2 min, 3 min, 4 min, 5 min, 10 min, 20 min, 30 min, 40 min, 50 min, 1 hr, 1.5hr, 2 hr, 2.5 hr, 3 hr, 4 hr, 5 hr, 6 hr, 9hr, 12hr, 18hr, 24hr, 36hr, 48hr.
+We restrict the `DOWNTIME_PERIOD` options that you can query, to be: 30 seconds, 1 min, 2 min, 3 min, 4 min, 5 min, 10 min, 20 min, 30 min, 40 min, 50 min, 1 hr, 1.5 hr, 2 hr, 2.5 hr, 3 hr, 4 hr, 5 hr, 6 hr, 9 hr, 12 hr, 18 hr, 24 hr, 36 hr, 48 hr.
 
 In the downtime detector module, we store state entries for:
 
@@ -27,4 +28,16 @@ Then in every begin block:
 * Store last blocks timestamp
 * if time since last block timestamp >= 30 seconds, iterate through all `DOWNTIME_PERIODS` less than the downtime, and in each add a state entry for the current block time
 
-Then our query for has it been `RECOVERY_PERIOD` since `DOWNTIME_PERIOD`, simply reads the state entry for that `DOWNTIME_PERIOD`, and then checks if time difference between now and that block is > `RECOVERY_PERIOD`.
+Then our query for has it been `RECOVERY_PERIOD` since `DOWNTIME_PERIOD`, simply reads the state entry for that `DOWNTIME_PERIOD`, and then checks if time difference between now and that block is > `RECOVERY_PERIOD`.
+
+## Queries
+
+The module exposes a single gRPC query, `RecoveredSinceDowntimeOfLength`:
+
+* Request `RecoveredSinceDowntimeOfLengthRequest`
+    * `downtime` (`Downtime`): the downtime period to check, one of the restricted `DOWNTIME_PERIOD` options listed above (30 seconds through 48 hr), encoded as the `Downtime` enum (`DURATION_30S`, `DURATION_1M`, ... `DURATION_48H`).
+    * `recovery` (`google.protobuf.Duration`): the `RECOVERY_PERIOD` to check against.
+* Response `RecoveredSinceDowntimeOfLengthResponse`
+    * `succesfully_recovered` (`bool`): true if it has been at least `recovery` since the last downtime of length `downtime`. (The misspelling is part of the deployed proto field name.)
+
+Source: [`proto/osmosis/downtimedetector/v1beta1/query.proto`](https://github.com/osmosis-labs/osmosis/blob/main/proto/osmosis/downtimedetector/v1beta1/query.proto) and [`downtime_duration.proto`](https://github.com/osmosis-labs/osmosis/blob/main/proto/osmosis/downtimedetector/v1beta1/downtime_duration.proto).

docs/build/chain/epochs/README.md

@@ -20,7 +20,7 @@ they can easily be signalled upon such events.
 
 ## Concepts
 
-The epochs module defines on-chain timers, that execute at fixed time intervals.
+The epochs module defines onchain timers, that execute at fixed time intervals.
 Other SDK modules can then register logic to be executed at the timer ticks.
 We refer to the period in between two timer ticks as an "epoch".