smeb_y/0g-chain
1
0
Fork 0
mirror of https://github.com/0glabs/0g-chain.git synced 2024-11-10 10:05:18 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

[R4R] Better docs (#541)

Browse Source 
* update sidebar order

* update event backticks

* fix broken links

* fix spelling
This commit is contained in:
Denali Marsh 2020-06-03 11:54:31 -07:00 committed by GitHub
parent e1c1902543
commit 2d7f5c4080
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
56 changed files with 388 additions and 138 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
docs/.vuepress/config.js
View File

@ -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",
static: true
path: "/tools/auction.html",
}
]
},
{
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"
}
]
},

4
docs/post.sh
View File

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

15
docs/pre.sh
View File

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

4
x/auction/spec/01_concepts.md
View File

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

4
x/auction/spec/02_state.md
View File

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

4
x/auction/spec/03_messages.md
View File

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

36
x/auction/spec/04_events.md
View File

@ -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_type | {auction type} |
| auction_start | lot | {coin amount} |
| auction_start | bid | {coin amount} |
| auction_start | max_bid | {coin amount} |
|---------------|---------------|-------------------|
| auction_start | auction_id | `{auction ID}` |
| auction_start | auction_type | `{auction type}` |
| auction_start | lot | `{coin amount}` |
| auction_start | bid | `{coin amount}` |
| auction_start | max_bid | `{coin amount}` |
## Handlers
### MsgPlaceBid
| Type | Attribute Key | Attribute Value |
|-------------|---------------|--------------------|
| auction_bid | auction_id | {auction ID} |
| auction_bid | bidder | {latest bidder} |
| auction_bid | bid | {coin amount} |
| auction_bid | lot | {coin amount} |
| auction_bid | end_time | {auction end time} |
|-------------|---------------|----------------------|
| auction_bid | auction_id | `{auction ID}` |
| auction_bid | bidder | `{latest bidder}` |
| auction_bid | bid | `{coin amount}` |
| auction_bid | lot | `{coin amount}` |
| 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 | close_block | {block height} |
|---------------|---------------|-------------------|
| auction_close | auction_id | `{auction ID}` |
| auction_close | close_block | `{block height}` |

4
x/auction/spec/05_params.md
View File

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

4
x/auction/spec/06_begin_block.md
View File

@ -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:

7
x/auction/spec/README.md
View File

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

6
x/bep3/spec/01_concepts.md
View File

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

4
x/bep3/spec/02_state.md
View File

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

4
x/bep3/spec/03_messages.md
View File

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

58
x/bep3/spec/04_events.md
View File

@ -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 | recipient | {recipient address} |
| create_atomic_swap | atomic_swap_id | {swap ID} |
| create_atomic_swap | random_number_hash | {random number hash} |
| create_atomic_swap | timestamp | {timestamp} |
| create_atomic_swap | sender_other_chain | {sender other chain} |
| create_atomic_swap | expire_height | {swap expiration block} |
| create_atomic_swap | amount | {coin amount} |
| create_atomic_swap | direction | {incoming or outgoing} |
|--------------------|--------------------|---------------------------|
| create_atomic_swap | sender | `{sender address}` |
| create_atomic_swap | recipient | `{recipient address}` |
| create_atomic_swap | atomic_swap_id | `{swap ID}` |
| create_atomic_swap | random_number_hash | `{random number hash}` |
| create_atomic_swap | timestamp | `{timestamp}` |
| create_atomic_swap | sender_other_chain | `{sender other chain}` |
| create_atomic_swap | expire_height | `{swap expiration block}` |
| create_atomic_swap | amount | `{coin amount}` |
| 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 | recipient | {recipient address} |
| claim_atomic_swap | atomic_swap_id | {swap ID} |
| claim_atomic_swap | random_number_hash | {random number hash} |
| claim_atomic_swap | random_number | {secret random number} |
|--------------------|--------------------|---------------------------|
| claim_atomic_swap | claim_sender | `{sender address}` |
| claim_atomic_swap | recipient | `{recipient address}` |
| claim_atomic_swap | atomic_swap_id | `{swap ID}` |
| claim_atomic_swap | random_number_hash | `{random number hash}` |
| 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 | sender | {swap creator address} |
| refund_atomic_swap | atomic_swap_id | {swap ID} |
| refund_atomic_swap | random_number_hash | {random number hash} |
|--------------------|--------------------|---------------------------|
| refund_atomic_swap | refund_sender | `{sender address}` |
| refund_atomic_swap | sender | `{swap creator address}` |
| refund_atomic_swap | atomic_swap_id | `{swap ID}` |
| 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 | expiration_block | {block height at expiration} |
|---------------|------------------|----------------------------------|
| swaps_expired | atomic_swap_ids | `{array of swap IDs}` |
| swaps_expired | expiration_block | `{block height at expiration}` |

4
x/bep3/spec/05_params.md
View File

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

4
x/bep3/spec/06_begin_block.md
View File

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

7
x/bep3/spec/README.md
View File

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

6
x/cdp/spec/01_concepts.md
View File

@ -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:

6
x/cdp/spec/02_state.md
View File

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

4
x/cdp/spec/03_messages.md
View File

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

4
x/cdp/spec/06_params.md → x/cdp/spec/04_params.md
View File

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

56
x/cdp/spec/05_events.md
View File

@ -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} |
| create_cdp | cdp_id | {cdp id} |
| cdp_deposit | cdp_id | {cdp id} |
| cdp_deposit | amount | {deposit amount} |
| cdp_draw | cdp_id | {cdp id} |
| cdp_draw | amount | {draw amount} |
| message | sender | `{sender address}' |
| create_cdp | cdp_id | `{cdp id}' |
| cdp_deposit | cdp_id | `{cdp id}' |
| cdp_deposit | amount | `{deposit amount}' |
| cdp_draw | cdp_id | `{cdp id}' |
| cdp_draw | amount | `{draw amount}' |
### MsgWithdraw
| Type | Attribute Key | Attribute Value |
|---------|--------------- |-----------------------|
| message | cdp_withdrawal | {collateral amount} |
| message | cdp_id | {cdp_id} |
| message | cdp_withdrawal | `{collateral amount}' |
| 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} |
| cdp_deposit | cdp_id | {cdp id} |
| cdp_deposit | amount | {deposit amount} |
| message | sender | `{sender address}' |
| cdp_deposit | cdp_id | `{cdp id}' |
| cdp_deposit | amount | `{deposit amount}' |
### MsgDrawDebt
| Type | Attribute Key | Attribute Value |
|----------|---------------|------------------|
|----------|---------------|--------------------|
| message | module | cdp |
| message | sender | {sender address} |
| cdp_draw | cdp_id | {cdp id} |
| cdp_draw | amount | {draw amount} |
| message | sender | `{sender address}' |
| cdp_draw | cdp_id | `{cdp id}' |
| cdp_draw | amount | `{draw amount}' |
### MsgRepayDebt
| Type | Attribute Key | Attribute Value |
|---------------|---------------|--------------------|
| cdp_repayment | amount | {repayment amount} |
| cdp_repayment | cdp_id | {cdp id} |
| cdp_close | cdp_id | {cdp id} |
|---------------|---------------|----------------------|
| cdp_repayment | amount | `{repayment amount}' |
| cdp_repayment | 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 | deposit | {deposit} |
| cdp_liquidation | cdp_id | `{cdp id}' |
| cdp_liquidation | deposit | `{deposit}' |
| cdp_begin_blocker_error | module | cdp |
| cdp_begin_blocker_error | error_message | {error} |
| cdp_begin_blocker_error | error_message | `{error}' |

4
x/cdp/spec/04_begin_block.md → x/cdp/spec/06_begin_block.md
View File

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

11
x/cdp/spec/README.md
View File

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

4
x/committee/spec/01_concepts.md
View File

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

4
x/committee/spec/02_state.md
View File

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

4
x/committee/spec/03_messages.md
View File

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

24
x/committee/spec/04_events.md
View File

@ -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 | proposal_id | {proposal ID} |
| proposal_submit | committee_id | {'committee 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 | proposal_id | {proposal ID} |
| proposal_vote | voter | {voter address} |
| proposal_vote | committee_id | {'committee ID}' |
| proposal_vote | proposal_id | {'proposal ID}' |
| 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 | proposal_id | {proposal ID} |
| proposal_close | status | {outcome} |
| proposal_close | committee_id | {'committee ID}' |
| proposal_close | proposal_id | {'proposal ID}' |
| proposal_close | status | {'outcome}' |

4
x/committee/spec/05_params.md
View File

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

4
x/committee/spec/06_begin_block.md
View File

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

6
x/committee/spec/README.md
View File

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

4
x/incentive/spec/01_concepts.md
View File

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

4
x/incentive/spec/02_state.md
View File

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

4
x/incentive/spec/03_messages.md
View File

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

20
x/incentive/spec/04_events.md
View File

@ -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 | claim_amount | {amount claimed} |
|----------------------|---------------------|----------------------|
| claim_reward | claimed_by | `{claiming address}' |
| 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_reward_period | reward_period | {reward period} |
| claim_period_expiry | claim_period | {claim period} |
|----------------------|---------------------|----------------------|
| new_claim_period | claim_period | `{claim period}' |
| new_reward_period | reward_period | `{reward period}' |
| claim_period_expiry | claim_period | `{claim period}' |

4
x/incentive/spec/05_params.md
View File

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

4
x/incentive/spec/06_begin_block.md
View File

@ -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:

7
x/incentive/spec/README.md
View File

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

4
x/kavadist/spec/01_concepts.md
View File

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

4
x/kavadist/spec/02_state.md
View File

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

4
x/kavadist/spec/03_messages.md
View File

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

6
x/kavadist/spec/04_events.md
View File

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

4
x/kavadist/spec/05_params.md
View File

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

4
x/kavadist/spec/06_begin_block.md
View File

@ -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:

7
x/kavadist/spec/README.md
View File

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

4
x/pricefeed/spec/01_concepts.md
View File

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

4
x/pricefeed/spec/02_state.md
View File

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

4
x/pricefeed/spec/03_messages.md
View File

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

24
x/pricefeed/spec/04_events.md
View File

@ -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 | oracle | {oracle} |
| oracle_updated_price | market_price | {price} |
| oracle_updated_price | expiry | {expiry} |
|----------------------|---------------|--------------------|
| oracle_updated_price | market_id | `{market ID}` |
| oracle_updated_price | oracle | `{oracle}` |
| oracle_updated_price | market_price | `{price}` |
| 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_price | {price} |
| no_valid_prices | market_id | {market ID} |
|----------------------|-----------------|------------------|
| market_price_updated | market_id | `{market ID}` |
| market_price_updated | market_price | `{price}` |
| no_valid_prices | market_id | `{market ID}` |

4
x/pricefeed/spec/05_params.md
View File

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

4
x/pricefeed/spec/06_end_block.md
View File

@ -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:

7
x/pricefeed/spec/README.md
View File

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

4
x/validator-vesting/spec/01_concepts.md
View File

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

4
x/validator-vesting/spec/02_state.md
View File

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

4
x/validator-vesting/spec/03_begin_block.md
View File

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

7
x/validator-vesting/spec/README.md
View File

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