sei-protocol · Kbhat1 · Jun 13, 2022 · Jun 2, 2022 · Jun 2, 2022 · Jun 2, 2022
diff --git a/readme.md b/readme.md
@@ -9,6 +9,22 @@ Sei Network is the first orderbook-specific L1 blockchain. The chain emphasizes
 
 Designed with developers and users in mind, Sei serves as the infrastructure and shared liquidity hub for the next generation of DeFi. Apps can easily plug-and-play to trade on Sei orderbook infrastructure and access pooled liquidity from other apps. To prioritize developer experience, Sei Network has integrated the wasmd module to support CosmWasm smart contracts.
 
+# Documentation
+For the most up to date documentation please visit https://docs.seinetwork.io
+
+# Central Limit Orderbook
+Most financial applications in traditional finance make use of CLOBs to create markets. This works well if you have cheap transaction fees and large amounts of liquidity. In decentralized finance however, the automated market-maker (AMM) model is more popular because it doesn't require constantly updating orders and works with lower amounts of liquidity. 
+
+Sei offers cheap transaction fees and works with market makers to have large amounts of liquidity. As a result, it can offer the orderbook based trading experience in a decentralized, permissionless manner. This unlocks many use cases that previously didn't work with the AMM model. 
+
+# Sei Ecosystem
+Sei Network is an L1 blockchain with a built-in on-chain orderbook that allows smart contracts easy access to shared liquidity. Sei architecture enables composable apps that maintain modularity.
+
+Sei Network serves as the matching core of the ecosystem, offering superior reliability and ultra-high transaction speed to ecosystem partners, each with their own functionality and user experience. Anyone can create a DeFi application that leverages Sei's liquidity and the entire ecosystem benefits.
+
+Developers, traders, and users can all connect to Sei as ecosystem partners benefiting from shared liquidity and decentralized financial primitives.
+
+# Testnet
 ## Get started
 **How to validate on the Sei Testnet**
 *This is the Sei Testnet-1 (sei-testnet-1)*
@@ -119,4 +135,7 @@ seid tx staking create-validator \
 --amount <token delegation>usei \
 --node localhost:26657
 ```
-
+# Build with Us!
+If you are interested in building with Sei Network: 
+Email us at team@seinetwork.io 
+DM us on Twitter https://twitter.com/SeiNetwork
diff --git a/x/dex/README.md b/x/dex/README.md
@@ -1 +1,21 @@
-# Dex
+## Abstract
+
+TODO: Populate dex README Contents below.
+
+## Contents
+
+## Concepts
+
+## State
+
+## Messages
+
+## Events
+
+## Hooks
+
+## Parameters
+
+## Transactions
+
+## Queries
diff --git a/x/dex/spec/README.md b/x/dex/spec/README.md
@@ -0,0 +1,21 @@
+## Abstract
+
+TODO: Populate dex README Contents below.
+
+## Contents
+
+## Concepts
+
+## State
+
+## Messages
+
+## Events
+
+## Hooks
+
+## Parameters
+
+## Transactions
+
+## Queries
diff --git a/x/epoch/README.md b/x/epoch/README.md
@@ -1 +1,23 @@
-# Epoch
+## Abstract
+
+The epoch module gives modules the ability to be signaled once ever period.
+
+TODO: Populate Epoch README Contents below.
+
+## Contents
+
+## Concepts
+
+## State
+
+## Messages
+
+## Events
+
+## Hooks
+
+## Parameters
+
+## Transactions
+
+## Queries
diff --git a/x/epoch/spec/README.md b/x/epoch/spec/README.md
@@ -0,0 +1,23 @@
+## Abstract
+
+The epoch module gives modules the ability to be signaled once ever period.
+
+TODO: Populate Epoch README Contents below.
+
+## Contents
+
+## Concepts
+
+## State
+
+## Messages
+
+## Events
+
+## Hooks
+
+## Parameters
+
+## Transactions
+
+## Queries
diff --git a/x/oracle/README.md b/x/oracle/README.md
@@ -1 +1,39 @@
-# Oracle
+## Abstract
+
+Sei Network has an `oracle` module to support asset exchange rate pricing for use by other modules and contracts. When validating for the network, participation as an Oracle is expected and required in order to ensure the most reliable and accurate pricing for assets.
+
+For oracle pricing, the voting rounds have several steps to ensure integrity and consensus of pricing data prior to accepting the exchange rates as the source of truth. In each voting period, there are two aggregation steps that oracles must participate in.
+
+The prevote step is a step where a validator provides their oracle pricing submission during voting window X for the next voting window X+1. In this prevote step, the validator hashes their proposed exchange rates to prevent other validators from simply copying that validator's votes.
+
+In the vote step for window X, the validator provides their proposed exchange rates for the current window. These are hashed and compared with the prevotes from window X-1 to ensure that the voted values haven't changed across the voting window. At the end of the voting period, all of the exchange rate votes are accumulated and a weighted median is computed (weighted by validator voting power) to determine the true exchange rate for each asset.
+
+There are penalties for non-participation and participation with bad data. Validators have a miss count that tracks the number of voting windows in which a validator has either not provided data or provided data that deviated too much from the weighted median. In a given number of voting periods, if a validators miss count is too high, they are slashed as a penalty for misbehaving over an extended period of time.
+
+TODO: Populate Oracle README Contents below.
+
+## Contents
+
+## Concepts
+
+### Voting Procedure
+
+### Reward Band
+
+### Slashing
+
+### Abstaining from Voting
+
+## State
+
+## Messages
+
+## Events
+
+## Hooks
+
+## Parameters
+
+## Transactions
+
+## Queries
diff --git a/x/oracle/spec/01_concepts.md b/x/oracle/spec/01_concepts.md
@@ -6,55 +6,9 @@ order: 1
 
 ## Voting Procedure
 
-During each `VotePeriod`, the Oracle module obtains consensus on the exchange rate of Luna against denominations specified in `Whitelist` by requiring all members of the validator set to submit a vote for Luna exchange rate before the end of the interval.
-
-Validators must first pre-commit to a exchange rate, then in the subsequent `VotePeriod` submit and reveal their exchange rate alongside a proof that they had pre-commited at that price. This scheme forces the voter to commit to a submission before knowing the votes of others and thereby reduces centralization and free-rider risk in the Oracle.
-
-* Prevote and Vote
-
-    Let `P_t` be the current time interval of duration defined by `VotePeriod` (currently set to 30 seconds) during which validators must submit two messages:
-
-    * A `MsgAggregateExchangeRatePrevote`, containing the SHA256 hash of the exchange rates of Luna with respect to a Terra peg. A prevote must be submitted for all different denomination on which to report a Luna exchange rates.
-    * A `MsgAggregateExchangeRateVote`, containing the salt used to create the hash for the aggreagte prevote submitted in the previous interval `P_t-1`.
-
-* Vote Tally
-
-    At the end of `P_t`, the submitted votes are tallied.
-
-    The submitted salt of each vote is used to verify consistency with the prevote submitted by the validator in `P_t-1`. If the validator has not submitted a prevote, or the SHA256 resulting from the salt does not match the hash from the prevote, the vote is dropped.
-
-    For each denomination, if the total voting power of submitted votes exceeds 50%, the weighted median of the votes is recorded on-chain as the effective exchange rate for Luna against that denomination for the following `VotePeriod` `P_t+1`.
-
-    Denominations receiving fewer than `VoteThreshold` total voting power have their exchange rates deleted from the store, and no swaps can be made with it during the next VotePeriod `P_t+1`.
-
-* Ballot Rewards
-
-    After the votes are tallied, the winners of the ballots are determined with `tally()`.
-
-    Voters that have managed to vote within a narrow band around the weighted median, are rewarded with a portion of the collected seigniorage. See `k.RewardBallotWinners()` for more details.
-
-    > Starting from Columbus-3, fees from [Market](../../market/spec/README.md) swaps are no longer are included in the oracle reward pool, and are immediately burned during the swap operation.
-
 ## Reward Band
-
-Let `M` be the weighted median, `𝜎` be the standard deviation of the votes in the ballot, and  be the RewardBand parameter. The band around the median is set to be `𝜀 = max(𝜎, R/2)`. All valid (i.e. bonded and non-jailed) validators that submitted an exchange rate vote in the interval `[M - 𝜀, M + 𝜀]` should be included in the set of winners, weighted by their relative vote power.
-
 ## Slashing
 
-> Be sure to read this section carefully as it concerns potential loss of funds.
-
-A `VotePeriod` during which either of the following events occur is considered a "miss":
-
-* The validator fails to submits a vote for Luna exchange rate against **each and every** denomination specified in `Whitelist`.
-
-* The validator fails to vote within the `reward band` around the weighted median for one or more denominations.
-
-During every `SlashWindow`, participating validators must maintain a valid vote rate of at least `MinValidPerWindow` (5%), lest they get their stake slashed (currently set to 0.01%). The slashed validator is automatically temporarily "jailed" by the protocol (to protect the funds of delegators), and the operator is expected to fix the discrepancy promptly to resume validator participation.
-
 ## Abstaining from Voting
-
-A validator may abstain from voting by submitting a non-positive integer for the `ExchangeRate` field in `MsgExchangeRateVote`. Doing so will absolve them of any penalties for missing `VotePeriod`s, but also disqualify them from receiving Oracle seigniorage rewards for faithful reporting.
-
 ## Messages
 
-> The control flow for vote-tallying, Luna exchange rate updates, ballot rewards and slashing happens at the end of every `VotePeriod`, and is found at the [end-block ABCI](./03_end_block.md) function rather than inside message handlers.
diff --git a/x/oracle/spec/README.md b/x/oracle/spec/README.md
@@ -1,35 +1,39 @@
 ## Abstract
 
-The Oracle module provides the Terra blockchain with an up-to-date and accurate price feed of exchange rates of Luna against various Terra pegs so that the [Market](../../market/spec/README.md) may provide fair exchanges between Terra<>Terra currency pairs, as well as Terra<>Luna.
+Sei Network has an `oracle` module to support asset exchange rate pricing for use by other modules and contracts. When validating for the network, participation as an Oracle is expected and required in order to ensure the most reliable and accurate pricing for assets.
 
-As price information is extrinsic to the blockchain, the Terra network relies on validators to periodically vote on the current Luna exchange rate, with the protocol tallying up the results once per `VotePeriod` and updating the on-chain exchange rate as the weighted median of the ballot.
+For oracle pricing, the voting rounds have several steps to ensure integrity and consensus of pricing data prior to accepting the exchange rates as the source of truth. In each voting period, there are two aggregation steps that oracles must participate in.
 
-> Since the Oracle service is powered by validators, you may find it interesting to look at the [Staking](https://github.com/cosmos/cosmos-sdk/tree/master/x/staking/spec/README.md) module, which covers the logic for staking and validators.
+The prevote step is a step where a validator provides their oracle pricing submission during voting window X for the next voting window X+1. In this prevote step, the validator hashes their proposed exchange rates to prevent other validators from simply copying that validator's votes.
+
+In the vote step for window X, the validator provides their proposed exchange rates for the current window. These are hashed and compared with the prevotes from window X-1 to ensure that the voted values haven't changed across the voting window. At the end of the voting period, all of the exchange rate votes are accumulated and a weighted median is computed (weighted by validator voting power) to determine the true exchange rate for each asset.
+
+There are penalties for non-participation and participation with bad data. Validators have a miss count that tracks the number of voting windows in which a validator has either not provided data or provided data that deviated too much from the weighted median. In a given number of voting periods, if a validators miss count is too high, they are slashed as a penalty for misbehaving over an extended period of time.
+
+TODO: Populate Oracle README Contents below.
 
 ## Contents
 
-1. **[Concepts](01_concepts.md)**
-    - [Voting Procedure](01_concepts.md#Voting-Procedure)
-    - [Reward Band](01_concepts.md#Reward-Band)
-    - [Slashing](01_concepts.md#Slashing)
-    - [Abstaining from Voting](01_concepts.md#Abstaining-from-Voting)
-2. **[State](02_state.md)**
-    - [ExchangeRatePrevote](02_state.md#ExchangeRatePrevote)
-    - [ExchangeRateVote](02_state.md#ExchangeRateVote)
-    - [ExchangeRate](02_state.md#ExchangeRate)
-    - [FeederDelegation](02_state.md#FeederDelegation)
-    - [MissCounter](02_state.md#MissCounter)
-    - [AggregateExchangeRatePrevote](02_state.md#AggregateExchangeRatePrevote)
-    - [AggregateExchangeRateVote](02_state.md#AggregateExchangeRateVote)
-3. **[EndBlock](03_end_block.md)**
-    - [Tally Exchange Rate Votes](03_end_block.md#Tally-Exchange-Rate-Votes)
-4. **[Messages](04_messages.md)**
-    - [MsgExchangeRatePrevote](04_messages.md#MsgExchangeRatePrevote)
-    - [MsgExchangeRatePrevote](04_messages.md#MsgExchangeRatePrevote)
-    - [MsgDelegateFeedConsent](04_messages.md#MsgDelegateFeedConsent)
-    - [MsgAggregateExchangeRatePrevote](04_messages.md#MsgAggregateExchangeRatePrevote)
-    - [MsgAggregateExchangeRateVote](04_messages.md#MsgAggregateExchangeRateVote)
-5. **[Events](05_events.md)**
-    - [EndBlocker](05_events.md#EndBlocker)
-    - [Handlers](05_events.md#Handlers)
-6. **[Parameters](06_params.md)**
+## Concepts
+
+### Voting Procedure
+
+### Reward Band
+
+### Slashing
+
+### Abstaining from Voting
+
+## State
+
+## Messages
+
+## Events
+
+## Hooks
+
+## Parameters
+
+## Transactions
+
+## Queries