[R4R] Better docs (#541)

* update sidebar order

* update event backticks

* fix broken links

* fix spelling

docs/.vuepress/config.js

@@ -13,12 +13,20 @@ module.exports = {
         children: [
           {
             title: "Chainlink Price Oracle",
-            path: "https://docs.kava.io/Tools/oracle.html"
+            path: "/tools/oracle.html"
           },
           {
             title: "Auction Bot",
-            path: "https://docs.kava.io/Tools/auction.html",
+            path: "/tools/auction.html",
-            static: true
+          }
+        ]
+      },
+      {
+        title: "Building on Kava",
+        children: [
+          {
+            title: "JavaScript SDK",
+            path: "/building/javascript-sdk.html"
           }
         ]
       },
@@ -31,7 +39,7 @@ module.exports = {
           },
           {
             title: "Protocol Reference",
-            path: "https://godoc.org/github.com/Kava-Labs/kava"
+            path: "https://pkg.go.dev/github.com/kava-labs/kava?tab=subdirectories"
           }
         ]
       },

docs/post.sh

@@ -4,7 +4,7 @@
 rm -rf Modules
 
 # JavaScript SDK docs
- rm -rf Building
+ rm -rf building
 
  # Kava Tools docs
- rm -rf Tools
+ rm -rf tools

docs/pre.sh

@@ -5,7 +5,7 @@ mkdir -p Modules
 for D in ../x/*; do
   if [ -d "${D}" ]; then
     rm -rf "Modules/$(echo $D | awk -F/ '{print $NF}')"
-    mkdir -p "Modules/$(echo $D | awk -F/ '{print $NF}')" && cp -r $D/spec/* "$_" && mv "./$_/README.md" "./$_/00_README.md" 
+    mkdir -p "Modules/$(echo $D | awk -F/ '{print $NF}')" && cp -r $D/spec/* "$_"
   fi
 done
 
@@ -13,18 +13,25 @@ baseGitUrl="https://raw.githubusercontent.com/Kava-Labs"
 
 # Client docs (JavaScript SDK)
 clientGitRepo="javascript-sdk"
-clientDir="Building"
+clientDir="building"
 
 mkdir -p "./${clientDir}"
 curl "${baseGitUrl}/${clientGitRepo}/master/README.md" -o "./${clientDir}/${clientGitRepo}.md"
+echo "---
+parent: 
+  order: false
+---" > "./${clientDir}/readme.md"
 
 # Kava Tools docs
 toolsGitRepo="kava-tools"
-toolsDir="Tools"
+toolsDir="tools"
 toolDocs=("auction" "oracle")
 
 mkdir -p "./${toolsDir}"
 for T in ${toolDocs[@]}; do
   curl "${baseGitUrl}/${toolsGitRepo}/master/${T}/README.md" -o "./${toolsDir}/${T}.md"
 done
-
+echo "---
+parent: 
+  order: false
+---" > "./${toolsDir}/readme.md"

x/auction/spec/01_concepts.md

@@ -1,3 +1,7 @@
+<!--
+order: 1
+-->
+
 # Concepts
 
 Auctions are broken down into three distinct types, which correspond to three specific functionalities within the CDP system.

x/auction/spec/02_state.md

@@ -1,3 +1,7 @@
+<!--
+order: 2
+-->
+
 # State
 
 ## Parameters and genesis state

x/auction/spec/03_messages.md

@@ -1,3 +1,7 @@
+<!--
+order: 3
+-->
+
 # Messages
 
 ## Bidding

x/auction/spec/04_events.md

@@ -1,3 +1,7 @@
+<!--
+order: 4
+-->
+
 # Events
 
 The `x/auction` module emits the following events:
@@ -5,30 +9,30 @@ The `x/auction` module emits the following events:
 ## Triggered By Other Modules
 
 | Type          | Attribute Key | Attribute Value   |
-|---------------|---------------|-----------------|
+|---------------|---------------|-------------------|
-| auction_start | auction_id    | {auction ID}    |
+| auction_start | auction_id    | `{auction ID}`    |
-| auction_start | auction_type  | {auction type}  |
+| auction_start | auction_type  | `{auction type}`  |
-| auction_start | lot           | {coin amount}   |
+| auction_start | lot           | `{coin amount}`   |
-| auction_start | bid           | {coin amount}   |
+| auction_start | bid           | `{coin amount}`   |
-| auction_start | max_bid       | {coin amount}   |
+| auction_start | max_bid       | `{coin amount}`   |
 
 ## Handlers
 
 ### MsgPlaceBid
 
 | Type        | Attribute Key | Attribute Value      |
-|-------------|---------------|--------------------|
+|-------------|---------------|----------------------|
-| auction_bid | auction_id    | {auction ID}       |
+| auction_bid | auction_id    | `{auction ID}`       |
-| auction_bid | bidder        | {latest bidder}    |
+| auction_bid | bidder        | `{latest bidder}`    |
-| auction_bid | bid           | {coin amount}      |
+| auction_bid | bid           | `{coin amount}`      |
-| auction_bid | lot           | {coin amount}      |
+| auction_bid | lot           | `{coin amount}`      |
-| auction_bid | end_time      | {auction end time} |
+| auction_bid | end_time      | `{auction end time}` |
 | message     | module        | auction              |
-| message     | sender        | {sender address}   |
+| message     | sender        | `{sender address}`   |
 
 ## BeginBlock
 
 | Type          | Attribute Key | Attribute Value   |
-|---------------|---------------|-----------------|
+|---------------|---------------|-------------------|
-| auction_close | auction_id    | {auction ID}    |
+| auction_close | auction_id    | `{auction ID}`    |
-| auction_close | close_block   | {block height}  |
+| auction_close | close_block   | `{block height}`  |

x/auction/spec/05_params.md

@@ -1,3 +1,7 @@
+<!--
+order: 5
+-->
+
 # Parameters
 
 The auction module contains the following parameters:

x/auction/spec/06_begin_block.md

@@ -1,3 +1,7 @@
+<!--
+order: 6
+-->
+
 # Begin Block
 
 At the start of each block, auctions that have reached `EndTime` are closed. The logic to close auctions is as follows:

x/auction/spec/README.md

@@ -1,3 +1,10 @@
+<!--
+order: 0
+title: "Auction Overview"
+parent:
+  title: "auction"
+-->
+
 # `auction`
 
 <!-- TOC -->

x/bep3/spec/01_concepts.md

@@ -1,6 +1,10 @@
+<!--
+order: 1
+-->
+
 # Concepts
 
- The BEP3 module implements the [BEP3 protocol](https://github.com/binance-chain/BEPs/blob/master/BEP3.md) for secure cross-chain asset transfers between Kava and other BEP3 compatible chains, such as Binance Chain. Tranactions are witnessed and relayed between the two blockchains by Binance's BEP3 deputy process. The deputy maintains an address on both chains and is responsible for delivering tokens upon the successful completion of an Atomic Swap. Learn more about the BEP3 deputy process [here](https://github.com/binance-chain/bep3-deputy).
+ The BEP3 module implements the [BEP3 protocol](https://github.com/binance-chain/BEPs/blob/master/BEP3.md) for secure cross-chain asset transfers between Kava and other BEP3 compatible chains, such as Binance Chain. Transactions are witnessed and relayed between the two blockchains by Binance's BEP3 deputy process. The deputy maintains an address on both chains and is responsible for delivering tokens upon the successful completion of an Atomic Swap. Learn more about the BEP3 deputy process [here](https://github.com/binance-chain/bep3-deputy).
 
 ## Requirements
 Kava

x/bep3/spec/02_state.md

@@ -1,3 +1,7 @@
+<!--
+order: 2
+-->
+
 # State
 
 ## Parameters and genesis state

x/bep3/spec/03_messages.md

@@ -1,3 +1,7 @@
+<!--
+order: 3
+-->
+
 # Messages
 
 ## Create swap

x/bep3/spec/04_events.md

@@ -1,3 +1,7 @@
+<!--
+order: 4
+-->
+
 # Events
 
 The `x/bep3` module emits the following events:
@@ -7,45 +11,45 @@ The `x/bep3` module emits the following events:
 ### MsgCreateAtomicSwap
 
 | Type               | Attribute Key      | Attribute Value           |
-|--------------------|--------------------|--------------------------|
+|--------------------|--------------------|---------------------------|
-| create_atomic_swap | sender             | {sender address}         |
+| create_atomic_swap | sender             | `{sender address}`        |
-| create_atomic_swap | recipient          | {recipient address}      |
+| create_atomic_swap | recipient          | `{recipient address}`     |
-| create_atomic_swap | atomic_swap_id     | {swap ID}                |
+| create_atomic_swap | atomic_swap_id     | `{swap ID}`               |
-| create_atomic_swap | random_number_hash | {random number hash}     |
+| create_atomic_swap | random_number_hash | `{random number hash}`    |
-| create_atomic_swap | timestamp          | {timestamp}              |
+| create_atomic_swap | timestamp          | `{timestamp}`             |
-| create_atomic_swap | sender_other_chain | {sender other chain}     |
+| create_atomic_swap | sender_other_chain | `{sender other chain}`    |
-| create_atomic_swap | expire_height      | {swap expiration block}  |
+| create_atomic_swap | expire_height      | `{swap expiration block}` |
-| create_atomic_swap | amount             | {coin amount}            |
+| create_atomic_swap | amount             | `{coin amount}`           |
-| create_atomic_swap | direction          | {incoming or outgoing}   |
+| create_atomic_swap | direction          | `{incoming or outgoing}`  |
 | message            | module             | bep3                      |
-| message            | sender             | {sender address}         |
+| message            | sender             | `{sender address}`        |
 
 ### MsgClaimAtomicSwap
 
 | Type               | Attribute Key      | Attribute Value           |
-|--------------------|--------------------|--------------------------|
+|--------------------|--------------------|---------------------------|
-| claim_atomic_swap  | claim_sender       | {sender address}         |
+| claim_atomic_swap  | claim_sender       | `{sender address}`        |
-| claim_atomic_swap  | recipient          | {recipient address}      |
+| claim_atomic_swap  | recipient          | `{recipient address}`     |
-| claim_atomic_swap  | atomic_swap_id     | {swap ID}                |
+| claim_atomic_swap  | atomic_swap_id     | `{swap ID}`               |
-| claim_atomic_swap  | random_number_hash | {random number hash}     |
+| claim_atomic_swap  | random_number_hash | `{random number hash}`    |
-| claim_atomic_swap  | random_number      | {secret random number}   |
+| claim_atomic_swap  | random_number      | `{secret random number}`  |
 | message            | module             | bep3                      |
-| message            | sender             | {sender address}         |
+| message            | sender             | `{sender address}`        |
 
 ## MsgRefundAtomicSwap
 
 | Type               | Attribute Key      | Attribute Value           |
-|--------------------|--------------------|--------------------------|
+|--------------------|--------------------|---------------------------|
-| refund_atomic_swap | refund_sender      | {sender address}         |
+| refund_atomic_swap | refund_sender      | `{sender address}`        |
-| refund_atomic_swap | sender             | {swap creator address}   |
+| refund_atomic_swap | sender             | `{swap creator address}`  |
-| refund_atomic_swap | atomic_swap_id     | {swap ID}                |
+| refund_atomic_swap | atomic_swap_id     | `{swap ID}`               |
-| refund_atomic_swap | random_number_hash | {random number hash}     |
+| refund_atomic_swap | random_number_hash | `{random number hash}`    |
 | message            | module             | bep3                      |
-| message            | sender             | {sender address}         |
+| message            | sender             | `{sender address}`        |
 
 ## BeginBlock
 
 | Type          | Attribute Key    | Attribute Value                  |
-|---------------|------------------|------------------------------|
+|---------------|------------------|----------------------------------|
-| swaps_expired | atomic_swap_ids  | {array of swap IDs}          |
+| swaps_expired | atomic_swap_ids  | `{array of swap IDs}`            |
-| swaps_expired | expiration_block | {block height at expiration} |
+| swaps_expired | expiration_block | `{block height at expiration}`   |

x/bep3/spec/05_params.md

@@ -1,3 +1,7 @@
+<!--
+order: 5
+-->
+
 # Parameters
 
 The bep3 module contains the following parameters:

x/bep3/spec/06_begin_block.md

@@ -1,3 +1,7 @@
+<!--
+order: 6
+-->
+
 # Begin Block
 
 At the start of each block, atomic swaps that meet certain criteria are expired or deleted.

x/bep3/spec/README.md

@@ -1,3 +1,10 @@
+<!--
+order: 0
+title: "BEP3 Overview"
+parent:
+  title: "bep3"
+-->
+
 # `bep3`
 
 <!-- TOC -->

x/cdp/spec/01_concepts.md

@@ -1,3 +1,7 @@
+<!--
+order: 1
+-->
+
 # Concepts
 
 ## Collateralized Debt Positions
@@ -58,7 +62,7 @@ Fees accumulate to the system and are split between the savings rate and surplus
 
 ## Governance
 
-The cdp module's behavior is controlled through several parameters which are updated through a governance mechanism. These parameters are listed in [Parameters](06_params.md).
+The cdp module's behavior is controlled through several parameters which are updated through a governance mechanism. These parameters are listed in [Parameters](04_params.md).
 
 Governance is important for actions such as:
 

x/cdp/spec/02_state.md

@@ -1,3 +1,7 @@
+<!--
+order: 2
+-->
+
 # State
 
 For detail on the state tracked by the cdp module see the types package. In particular [keys.go](../types/keys.go) describes how state is stored in the key-value store.
@@ -49,7 +53,7 @@ type Deposit struct {
 
 ## Params
 
-Module parameters controlled by governance. See [Parameters](06_params.md) for details.
+Module parameters controlled by governance. See [Parameters](04_params.md) for details.
 
 ## NextCDPID
 

x/cdp/spec/03_messages.md

@@ -1,3 +1,7 @@
+<!--
+order: 3
+-->
+
 # Messages
 
 Users can submit various messages to the cdp module which trigger state changes detailed below.

x/cdp/spec/04_params.md

@@ -1,3 +1,7 @@
+<!--
+order: 4
+-->
+
 # Parameters
 
 The cdp module contains the following parameters:

x/cdp/spec/05_events.md

@@ -1,3 +1,7 @@
+<!--
+order: 5
+-->
+
 # Events
 
 The cdp module emits the following events:
@@ -7,58 +11,58 @@ The cdp module emits the following events:
 ### MsgCreateCDP
 
 | Type        | Attribute Key | Attribute Value    |
-|-------------|---------------|------------------|
+|-------------|---------------|--------------------|
 | message     | module        | cdp                |
-| message     | sender        | {sender address} |
+| message     | sender        | `{sender address}' |
-| create_cdp  | cdp_id        | {cdp id}         |
+| create_cdp  | cdp_id        | `{cdp id}'         |
-| cdp_deposit | cdp_id        | {cdp id}         |
+| cdp_deposit | cdp_id        | `{cdp id}'         |
-| cdp_deposit | amount        | {deposit amount} |
+| cdp_deposit | amount        | `{deposit amount}' |
-| cdp_draw    | cdp_id        | {cdp id}         |
+| cdp_draw    | cdp_id        | `{cdp id}'         |
-| cdp_draw    | amount        | {draw amount}    |
+| cdp_draw    | amount        | `{draw amount}'    |
 
 ### MsgWithdraw
 
 | Type    | Attribute Key  | Attribute Value       |
 |---------|--------------- |-----------------------|
-| message | cdp_withdrawal | {collateral amount}   |
+| message | cdp_withdrawal | `{collateral amount}' |
-| message | cdp_id         | {cdp_id}              |
+| message | cdp_id         | `{cdp_id}'            |
 | message | module         | cdp                   |
-| message | sender         | {sender address}      |
+| message | sender         | `{sender address}'    |
 
 ### MsgDeposit
 
 | Type        | Attribute Key | Attribute Value    |
-|-------------|---------------|------------------|
+|-------------|---------------|--------------------|
 | message     | module        | cdp                |
-| message     | sender        | {sender address} |
+| message     | sender        | `{sender address}' |
-| cdp_deposit | cdp_id        | {cdp id}         |
+| cdp_deposit | cdp_id        | `{cdp id}'         |
-| cdp_deposit | amount        | {deposit amount} |
+| cdp_deposit | amount        | `{deposit amount}' |
 
 ### MsgDrawDebt
 
 | Type     | Attribute Key | Attribute Value    |
-|----------|---------------|------------------|
+|----------|---------------|--------------------|
 | message  | module        | cdp                |
-| message  | sender        | {sender address} |
+| message  | sender        | `{sender address}' |
-| cdp_draw | cdp_id        | {cdp id}         |
+| cdp_draw | cdp_id        | `{cdp id}'         |
-| cdp_draw | amount        | {draw amount}    |
+| cdp_draw | amount        | `{draw amount}'    |
 
 ### MsgRepayDebt
 
 | Type          | Attribute Key | Attribute Value      |
-|---------------|---------------|--------------------|
+|---------------|---------------|----------------------|
-| cdp_repayment | amount        | {repayment amount} |
+| cdp_repayment | amount        | `{repayment amount}' |
-| cdp_repayment | cdp_id        | {cdp id}           |
+| cdp_repayment | cdp_id        | `{cdp id}'           |
-| cdp_close     | cdp_id        | {cdp id}           |
+| cdp_close     | cdp_id        | `{cdp id}'           |
 | message       | module        | cdp                  |
-| message       | sender        | {sender address}   |
+| message       | sender        | `{sender address}'   |
 
 ## BeginBlock
 
 | Type                    | Attribute Key | Attribute Value     |
 |-------------------------|---------------|---------------------|
 | cdp_liquidation         | module        | cdp                 |
-| cdp_liquidation         | cdp_id        | {cdp id}            |
+| cdp_liquidation         | cdp_id        | `{cdp id}'          |
-| cdp_liquidation         | deposit       | {deposit}           |
+| cdp_liquidation         | deposit       | `{deposit}'         |
 | cdp_begin_blocker_error | module        | cdp                 |
-| cdp_begin_blocker_error | error_message | {error}             |
+| cdp_begin_blocker_error | error_message | `{error}'           |

x/cdp/spec/06_begin_block.md

@@ -1,3 +1,7 @@
+<!--
+order: 6
+-->
+
 # Begin Block
 
 At the start of every block the BeginBlock of the cdp module:

x/cdp/spec/README.md

@@ -1,3 +1,10 @@
+<!--
+order: 0
+title: "CDP Overview"
+parent:
+  title: "cdp"
+-->
+
 # `cdp`
 
 ## Table of Contents
@@ -5,9 +12,9 @@
 1. **[Concepts](01_concepts.md)**
 2. **[State](02_state.md)**
 3. **[Messages](03_messages.md)**
-4. **[BeginBlock](04_begin_block.md)**
+4. **[Parameters](04_params.md)**
 5. **[Events](05_events.md)**
-6. **[Parameters](06_params.md)**
+6. **[BeginBlock](06_begin_block.md)**
 
 ## Overview
 

x/committee/spec/01_concepts.md

@@ -1,3 +1,7 @@
+<!--
+order: 1
+-->
+
 # Concepts
 
 For a general introduction to governance using the Comsos-SDK, see [x/gov](https://github.com/cosmos/cosmos-sdk/blob/v0.38.3/x/gov/spec/01_concepts.md).

x/committee/spec/02_state.md

@@ -1,3 +1,7 @@
+<!--
+order: 2
+-->
+
 # State
 
 ## Genesis state

x/committee/spec/03_messages.md

@@ -1,3 +1,7 @@
+<!--
+order: 3
+-->
+
 # Messages
 
 Committee members submit proposals using a `MsgSubmitProposal`

x/committee/spec/04_events.md

@@ -1,3 +1,7 @@
+<!--
+order: 4
+-->
+
 # Events
 
 The `x/committee` module emits the following events:
@@ -6,25 +10,25 @@ The `x/committee` module emits the following events:
 
 | Type                 | Attribute Key       | Attribute Value    |
 |----------------------|---------------------|--------------------|
-| proposal_submit      | committee_id        | {committee ID}     |
+| proposal_submit      | committee_id        | {'committee ID}'   |
-| proposal_submit      | proposal_id         | {proposal ID}      |
+| proposal_submit      | proposal_id         | {'proposal ID}'    |
 | message              | module              | committee          |
-| message              | sender              | {sender address}   |
+| message              | sender              | {'sender address}' |
 
 ## MsgVote
 
 | Type                 | Attribute Key       | Attribute Value    |
 |----------------------|---------------------|--------------------|
-| proposal_vote        | committee_id        | {committee ID}     |
+| proposal_vote        | committee_id        | {'committee ID}'   |
-| proposal_vote        | proposal_id         | {proposal ID}      |
+| proposal_vote        | proposal_id         | {'proposal ID}'    |
-| proposal_vote        | voter               | {voter address}    |
+| proposal_vote        | voter               | {'voter address}'  |
 | message              | module              | committee          |
-| message              | sender              | {sender address}   |
+| message              | sender              | {'sender address}' |
 
 ## BeginBlock
 
 | Type                 | Attribute Key       | Attribute Value    |
 |----------------------|---------------------|--------------------|
-| proposal_close       | committee_id        | {committee ID}     |
+| proposal_close       | committee_id        | {'committee ID}'   |
-| proposal_close       | proposal_id         | {proposal ID}      |
+| proposal_close       | proposal_id         | {'proposal ID}'    |
-| proposal_close       | status              | {outcome}          |
+| proposal_close       | status              | {'outcome}'        |

x/committee/spec/05_params.md

@@ -1,3 +1,7 @@
+<!--
+order: 5
+-->
+
 # Parameters
 
 The committee module has no parameters. Committees are created using the `x/gov` module and and inherit the parameters controlling governance proposals from `x/gov`.

x/committee/spec/06_begin_block.md

@@ -1,3 +1,7 @@
+<!--
+order: 6
+-->
+
 # Begin Block
 
 At the start of each block, expired proposals are deleted. The logic is as follows:

x/committee/spec/README.md

@@ -1,3 +1,9 @@
+<!--
+order: 0
+title: "Committee Overview"
+parent:
+  title: "committee"
+-->
 
 # `committee`
 

x/incentive/spec/01_concepts.md

@@ -1,3 +1,7 @@
+<!--
+order: 1
+-->
+
 # Concepts
 
 This module presents an implementation of user incentives that are controlled by governance. When users take a certain action, in this case opening a CDP, they become eligible for rewards. Rewards are __opt in__ meaning that users must submit a message before the claim deadline to claim their rewards. The goals and background of this module were subject of a previous Kava governance proposal, which can be found [here](https://ipfs.io/ipfs/QmSYedssC3nyQacDJmNcREtgmTPyaMx2JX7RNkMdAVkdkr/user-growth-fund-proposal.pdf).

x/incentive/spec/02_state.md

@@ -1,3 +1,7 @@
+<!--
+order: 2
+-->
+
 # State
 
 ## Parameters and Genesis State

x/incentive/spec/03_messages.md

@@ -1,3 +1,7 @@
+<!--
+order: 3
+-->
+
 # Messages
 
 Users claim rewards using a `MsgClaimReward`.

x/incentive/spec/04_events.md

@@ -1,3 +1,7 @@
+<!--
+order: 4
+-->
+
 # Events
 
 The `x/incentive` module emits the following events:
@@ -5,16 +9,16 @@ The `x/incentive` module emits the following events:
 ## MsgClaimReward
 
 | Type                 | Attribute Key       | Attribute Value      |
-|----------------------|---------------------|--------------------|
+|----------------------|---------------------|----------------------|
-| claim_reward         | claimed_by          | {claiming address} |
+| claim_reward         | claimed_by          | `{claiming address}' |
-| claim_reward         | claim_amount        | {amount claimed}   |
+| claim_reward         | claim_amount        | `{amount claimed}'   |
 | message              | module              | incentive            |
-| message              | sender              | {sender address}   |
+| message              | sender              | `{sender address}'   |
 
 ## BeginBlock
 
 | Type                 | Attribute Key       | Attribute Value      |
-|----------------------|---------------------|--------------------|
+|----------------------|---------------------|----------------------|
-| new_claim_period     | claim_period        | {claim period}     |
+| new_claim_period     | claim_period        | `{claim period}'     |
-| new_reward_period    | reward_period       | {reward period}    |
+| new_reward_period    | reward_period       | `{reward period}'    |
-| claim_period_expiry  | claim_period        | {claim period}     |
+| claim_period_expiry  | claim_period        | `{claim period}'     |

x/incentive/spec/05_params.md

@@ -1,3 +1,7 @@
+<!--
+order: 5
+-->
+
 # Parameters
 
 The incentive module contains the following parameters:

x/incentive/spec/06_begin_block.md

@@ -1,3 +1,7 @@
+<!--
+order: 6
+-->
+
 # Begin Block
 
 At the start of each block, expired claims and claim periods are deleted, rewards are applied to CDPs for any ongoing reward periods, expired reward periods are deleted and replaced with a new reward period (if active), and claim periods are created for expiring reward periods. The logic is as follows:

x/incentive/spec/README.md

@@ -1,3 +1,10 @@
+<!--
+order: 0
+title: "Incentive Overview"
+parent:
+  title: "incentive"
+-->
+
 # `incentive`
 
 <!-- TOC -->

x/kavadist/spec/01_concepts.md

@@ -1,3 +1,7 @@
+<!--
+order: 1
+-->
+
 # Concepts
 
 The minting mechanism in this module is designed to allow governance to determine a set of inflationary periods and the APR rate of inflation for each period. This module mints coins each block according to the schedule such that after 1 year the APR inflation worth of coins will have been minted. Governance can alter the APR inflation using a parameter change proposal. Parameter change proposals that change the APR will take effect in the block after they pass.

x/kavadist/spec/02_state.md

@@ -1,3 +1,7 @@
+<!--
+order: 2
+-->
+
 # State
 
 ## Parameters and Genesis State

x/kavadist/spec/03_messages.md

@@ -1,3 +1,7 @@
+<!--
+order: 3
+-->
+
 # Messages
 
 There are no messages in the kavadist module. All state transitions are controlled by parameters, which can be updated via parameter change proposals.

x/kavadist/spec/04_events.md

@@ -1,3 +1,7 @@
+<!--
+order: 4
+-->
+
 # Events
 
 The `x/kavadist` module emits the following events:
@@ -6,5 +10,5 @@ The `x/kavadist` module emits the following events:
 
 | Type                 | Attribute Key       | Attribute Value |
 |----------------------|---------------------|-----------------|
-| kavadist             | kava_dist_inflation | {amount}        |
+| kavadist             | kava_dist_inflation | `{amount}`      |
 | kavadist             | kava_dist_status    | "inactive"      |

x/kavadist/spec/05_params.md

@@ -1,3 +1,7 @@
+<!--
+order: 5
+-->
+
 # Parameters
 
 The kavadist module has the following parameters:

x/kavadist/spec/06_begin_block.md

@@ -1,3 +1,7 @@
+<!--
+order: 6
+-->
+
 # Begin Block
 
 At the start of each block, the inflationary coins for the ongoing period, if any, are minted. The logic is as follows:

x/kavadist/spec/README.md

@@ -1,3 +1,10 @@
+<!--
+order: 0
+title: "Kavadist Overview"
+parent:
+  title: "kavadist"
+-->
+
 # `kavadist`
 
 <!-- TOC -->

x/pricefeed/spec/01_concepts.md

@@ -1,3 +1,7 @@
+<!--
+order: 1
+-->
+
 # Concepts
 
 Prices can be posted by any account which is added as an oracle. Oracles are specific to each market and can be updated via param change proposals. When an oracle posts a price, they submit a message to the blockchain that contains the current price for that market and a time when that price should be considered expired. If an oracle posts a new price, that price becomes the current price for that oracle, regardless of the previous price's expiry. A group of prices posted by a set of oracles for a particular market are referred to as 'raw prices' and the current median price of all valid oracle prices is referred to as the 'current price'. Each block, the current price for each market is determined by calculating the median of the raw prices.

x/pricefeed/spec/02_state.md

@@ -1,3 +1,7 @@
+<!--
+order: 2
+-->
+
 # State
 
 ## Parameters and genesis state

x/pricefeed/spec/03_messages.md

@@ -1,3 +1,7 @@
+<!--
+order: 3
+-->
+
 # Messages
 
 ## Posting Prices

x/pricefeed/spec/04_events.md

@@ -1,3 +1,7 @@
+<!--
+order: 4
+-->
+
 # Events
 
 The `x/pricefeed` module emits the following events:
@@ -5,18 +9,18 @@ The `x/pricefeed` module emits the following events:
 ## MsgPostPrice
 
 | Type                 | Attribute Key | Attribute Value    |
-|----------------------|---------------|------------------|
+|----------------------|---------------|--------------------|
-| oracle_updated_price | market_id     | {market ID}      |
+| oracle_updated_price | market_id     | `{market ID}`      |
-| oracle_updated_price | oracle        | {oracle}         |
+| oracle_updated_price | oracle        | `{oracle}`         |
-| oracle_updated_price | market_price  | {price}          |
+| oracle_updated_price | market_price  | `{price}`          |
-| oracle_updated_price | expiry        | {expiry}         |
+| oracle_updated_price | expiry        | `{expiry}`         |
 | message              | module        | pricefeed          |
-| message              | sender        | {sender address} |
+| message              | sender        | `{sender address}` |
 
 ## BeginBlock
 
 | Type                 | Attribute Key   | Attribute Value  |
-|----------------------|-----------------|-----------------|
+|----------------------|-----------------|------------------|
-| market_price_updated | market_id       | {market ID}     |
+| market_price_updated | market_id       | `{market ID}`    |
-| market_price_updated | market_price    | {price}         |
+| market_price_updated | market_price    | `{price}`        |
-| no_valid_prices      | market_id       | {market ID}     |
+| no_valid_prices      | market_id       | `{market ID}`    |

x/pricefeed/spec/05_params.md

@@ -1,3 +1,7 @@
+<!--
+order: 5
+-->
+
 # Parameters
 
 The pricefeed module has the following parameters:

x/pricefeed/spec/06_end_block.md

@@ -1,3 +1,7 @@
+<!--
+order: 6
+-->
+
 # End Block
 
 At the end of each block, the current price is calculated as the median of all raw prices for each market. The logic is as follows:

x/pricefeed/spec/README.md

@@ -1,3 +1,10 @@
+<!--
+order: 0
+title: "Pricefeed Overview"
+parent:
+  title: "pricefeed"
+-->
+
 # `pricefeed`
 
 <!-- TOC -->

x/validator-vesting/spec/01_concepts.md

@@ -1,3 +1,7 @@
+<!--
+order: 1
+-->
+
 # Concepts
 
 The validator-vesting module is responsible for managing Validator Vesting Accounts, a vesting account for which the release of coins is tied to the validation of the blockchain. Validator Vesting Accounts implement the cosmos-sdk vesting account spec, which can be found [here](https://github.com/cosmos/cosmos-sdk/tree/master/x/auth/spec).

x/validator-vesting/spec/02_state.md

@@ -1,3 +1,7 @@
+<!--
+order: 2
+-->
+
 # State
 
 ## Validator Vesting Account type

x/validator-vesting/spec/03_begin_block.md

@@ -1,3 +1,7 @@
+<!--
+order: 3
+-->
+
 # Begin Block
 
 At each `BeginBlock`, all validator vesting accounts are iterated over to update the status of the current vesting period. Note that the address of each account is retrieved by iterating over the keys in the `validator-vesting` store, while the account objects are stored and accessed using the `auth` module's `AccountKeeper`. For each account, the block count is incremented, the missed sign count is incremented if the validator did not sign the block or was not found in the validator set. By comparing the blocktime of the current `BeginBlock`, with the value of `previousBlockTime` stored in the `validator-vesting` store, it is determined if the end of the current period has been reached. If the current period has ended, the `VestingPeriodProgress` field is updated to reflect if the coins for the ending period successfully vested or not. After updates are made regarding the status of the current vesting period, any outstanding debt on the account is attempted to be collected. If there is enough `SpendableBalance` on the account to cover the debt, coins are sent to the `ReturnAdress` or burned. If there is not enough `SpendableBalance` to cover the debt, all delegations of the account are `Unbonded`. Once those unbonding events reach maturity, the coins freed from the unbonding will be used to cover the debt. Finally, the time of the previous block is stored in the validator vesting account keeper, which is used to determine when a period has ended.

x/validator-vesting/spec/README.md

@@ -1,3 +1,10 @@
+<!--
+order: 0
+title: "Validator Vesting Overview"
+parent:
+  title: "validator-vesting"
+-->
+
 # `validator-vesting`
 
 <!-- TOC -->