removal of docs dir, migrated to discrete repo (#1169)

This commit is contained in:
stephensprinkle 2022-02-22 08:59:02 -08:00 committed by GitHub
parent c5dad2f19c
commit 666f136661
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
49 changed files with 0 additions and 19373 deletions

View File

@ -1,157 +0,0 @@
module.exports = {
theme: "cosmos",
title: "Kava Documentation",
themeConfig: {
logo: {
src: "/logo.svg"
},
custom: true,
sidebar: {
auto: false,
nav: [
{
title: "Getting Started - Developers",
children: [
{
title: "Get Started",
path: "/Education/getting_started.html"
},
{
title: "Building Modules",
path: "/Education/hello_kava.html"
},
{
title: "Javascript SDK",
path: "/building/javascript-sdk.html"
},
{
title: "Run Validator Node",
path: "/validator_guide"
},
{
title: "Run Bots",
children: [
{
title: "Sentinel Bot",
path: "/tools/sentinel.html"
},
{
title: "Auction Bot",
path: "/tools/auction.html"
}
]
},
{
title: "Migration Guide",
path: "/kava-8",
directory: true
}
]
},
{
title: "Resources",
children: [
{
title: "Community Tools",
path: "/tools/community.html"
},
{
title: "Module Specs",
path: "/Modules",
directory: true,
},
{
title: "CLI Docs",
path: "/Education/user_actions/",
directory: true,
},
{
title: "REST API Spec",
path: "https://swagger.kava.io/"
},
{
title: "Protocol Reference",
path: "https://pkg.go.dev/github.com/kava-labs/kava?tab=subdirectories"
},
{
title: "FAQ",
path: "/Education/FAQ/",
directory: true,
}
]
}
]
},
footer: {
logo: "/logo.svg",
textLink: {
text: "kava.io",
url: "https://www.kava.io"
},
services: [
{
service: "twitter",
url: "https://twitter.com/kava_platform"
},
{
service: "medium",
url: "https://medium.com/kava-labs"
},
{
service: "telegram",
url: "https://t.me/kavalabs"
},
{
service: "discord",
url: "https://discord.gg/JJYnuCx"
},
{
service: "github",
url: "https://github.com/kava-labs"
}
],
smallprint: "© 2021 Kava Labs.",
links: [
{
title: "Community",
children: [
{
title: "Blog",
url: "https://medium.com/kava-labs"
},
{
title: "Chat",
url: "https://t.me/kavalabs"
}
]
},
{
title: "Contributing",
children: [
{
title: "Contributing to the docs",
url: "https://github.com/Kava-Labs/kava/tree/master/docs"
},
{
title: "Source code on GitHub",
url: "https://github.com/Kava-Labs/kava"
}
]
},
{
title: "Related Docs",
children: [
{
title: "Cosmos SDK",
url: "https://cosmos.network/docs"
},
{
title: "Binance Chain",
url: "https://docs.binance.org"
}
]
}
]
}
}
}

Binary file not shown.

Before

Width:  |  Height:  |  Size: 464 B

View File

@ -1,7 +0,0 @@
<svg width="160" height="48" viewBox="0 0 160 48" fill="none" xmlns="http://www.w3.org/2000/svg">
<path d="M114.333 8.07732H123.4L107.621 47.1404H97.1424L81.3629 8.07732H90.4306L102.361 37.726L114.333 8.07732Z" fill="#FF564F"/>
<path d="M8.25957 0H0V47.1541H8.25957V0Z" fill="#FF564F"/>
<path d="M30.8467 47.1541L12.7523 23.577L30.8467 0H41.2157L23.3542 23.577L41.2157 47.1541H30.8467Z" fill="#FF564F"/>
<path d="M60.9811 7.04036C51.9408 7.04036 45.1331 12.0205 44.64 19.4292L44.5852 20.3024H52.6941L52.8311 19.6612C53.5845 16.1819 56.4335 14.2717 60.8441 14.2717C65.6382 14.2717 68.3914 16.6731 68.3914 20.8755V23.2905L58.2142 23.8636C49.0643 24.3957 43.5305 28.8573 43.5305 35.7885C43.5305 43.1018 49.0369 48 57.1321 48C61.9536 48 65.4738 46.6902 68.3503 43.7567V47.3314H76.5688V20.2479C76.5688 12.2251 70.3501 7.04036 60.9811 7.04036ZM68.3777 29.6214V32.05C67.8435 37.3576 64.1589 40.6868 58.5155 40.9596C56.3376 41.0688 54.4611 40.4821 53.2283 39.3087C52.2558 38.3945 51.749 37.1666 51.749 35.7749C51.749 32.664 54.4063 30.7129 59.0771 30.4127L68.3777 29.6214Z" fill="#FF564F"/>
<path d="M144.399 7.04036C135.358 7.04036 128.551 12.0205 128.058 19.4292L128.003 20.3024H136.112L136.249 19.6612C137.002 16.1819 139.851 14.2717 144.262 14.2717C149.056 14.2717 151.809 16.6731 151.809 20.8755V23.2905L141.645 23.8636C132.496 24.3957 126.962 28.8573 126.962 35.7885C126.962 43.1018 132.468 48 140.563 48C145.385 48 148.905 46.6902 151.782 43.7567V47.3314H160V20.2479C159.986 12.2251 153.768 7.04036 144.399 7.04036ZM151.809 29.6214V32.05C151.275 37.3576 147.59 40.6868 141.947 40.9596C139.769 41.0688 137.892 40.4821 136.66 39.3087C135.687 38.3945 135.18 37.1666 135.18 35.7749C135.18 32.664 137.838 30.7129 142.508 30.4127L151.809 29.6214Z" fill="#FF564F"/>
</svg>

Before

Width:  |  Height:  |  Size: 1.7 KiB

View File

@ -1,3 +0,0 @@
:root
--color-link #ff554f
--color-primary #ff554f

View File

@ -1,61 +0,0 @@
## The Basics
### What is Kava Protocol?
Kava Chain is a decentralized, permissionless, censorship-resistant blockchain built with the Cosmos SDK. This means it operates much like other Cosmos ecosystem blockchains, and is designed to be interoperable between chains.
[Learn more about Cosmos](https://cosmos.network/).
[Learn more about Kava](https://medium.com/kava-labs/kava-protocol-101-ce3beb0fa8b8)
Kava Protocol is the set of rules and behaviors built into the Kava Chain that enables advanced Decentralized Finance (DeFi) functionality like permissionless borrowing and lending.
The KAVA token is an asset on the Kava Chain. Kava Chain is secured by its token KAVA and it is used across the full chain as a transport and a store of value.
### What is Kava Lend?
Kava Lend is an application that runs on Kava blockchain. It builds upon the Kava Protocol and adds new functionality, expanding the Kava Ecosystem to include an autonomous money market protocol.
The HARD token is an asset on the Kava Chain. It is given as a reward for supplying and borrowing on Kava Lend.
### What tokens and assets can be use on the Kava Blockchain?
**Native assets**
Native assets are tokens that originate on the Kava Chain. These currently include KAVA, HARD, SWP and USDX.
KAVA and HARD are governance tokens, meaning holders can vote on the rules of the protocols. KAVA is also used as a Proof of Stake staking asset, which ensures the finality and safety of loans on the protocol and also acts as the lender of last resort in certain situations. USDX is a stable coin loosely pegged to the US Dollar. It is minted when a Kava CDP is opened. The exact value of USDX is determined by market forces. [Read more](https://medium.com/kava-labs/usdx-stability-mechanics-12bf23ed957b.com/kava-labs/usdx-stability-mechanics-12bf23ed957b)
**Non-native assets**
Other tokens can also be issued on the Kava Chain. These non-native asset tokens are often used to “wrap”, “tokenize,” or represent assets on other chains. For example:
Binance Coin (BNB) can be represented as a token on Kava Chain. During a cross-chain swap, BNB(Kava) coins are created or destroyed (burned) on Kava Chain, and frozen/unfrozen on Binance Chain.
Assets from other blockchains are considered non-native assets. This includes coins from other Cosmos ecosystem blockchains, which can connect to the Kava Chain through protocols like [Cosmos IBC](https://cosmos.network/ibc).
Be aware that KAVA (native) has been tokenized on other blockchains, namely Binance Chain. KAVA (BEP-2) is a token that exists solely on Binance Chain. Do not send KAVA (BEP2) directly to the Kava Chain.
**BTCB**
represents BTC which has been tokenized on Binance Chain. This BNB token has also been tokenized on KAVA, making BTCB (Kava) a doubly tokenized representation of BTC.
### How do I access Kava?
The Kava Platform or Kava Web App, which is live at [app.kava.io](https://app.kava.io/), is a user-friendly hub for interacting with the protocol.
Similarly, Kava Lend can be found at [app.kava.io/lend](https://app.kava.io/lend).
### Where can I learn more?
Here are great introductory readings:
[Mint](https://medium.com/kava-labs/kava-protocol-101-ce3beb0fa8b8)
[Lend](https://medium.com/kava-labs/introducing-harvest-io-the-worlds-first-cross-chain-money-market-a27535a5d91a).
Check out our other articles on [Medium](https://medium.com/kava-labs).
### Does Kava have smart contracts?
Like most Cosmos ecosystem blockchains, the automated transaction behaviors known as smart contracts are hardcoded into the protocol. They are referred to as “modules” in the Cosmos Ecosystem. The Kava App uses a special kind of module called a CDP.
### What is a CDP? How do I mint USDX?
A CDP or Collateralized Debt Position is a new kind of automated loan contract, used to create “stablecoins” that are pegged to a fiat currency like the US Dollar. The lender puts up a crypto asset as collateral to mint, or create new stablecoins.
For example, on Kava, users can stake BNB as collateral to mint USDX. The collateral is locked while the position is open. The lender unlocks their collateral once they repay the loan amount plus accumulated interest.
Minting USDX is as simple as supplying your asset to Kava and clicking “Borrow.” The lender can only take out 2/3rds of the collateral amount. [Read more here](https://medium.com/kava-labs/borrow-usdx-on-kavas-web-app-using-trust-wallet-8540ba61f7a4)
Lenders should keep in mind that if the price of the collateral asset drops below the liquidation price, their CDP will be liquidated. Therefore, it is advised not to mint more than 1/2 of the value of the collateral. The “Safe Max” button included in the app goes by this recommendation.
### What is Kava planning for the future?
Check out our [roadmap](https://medium.com/kava-labs/kava-2021-roadmap-91f839a0907b). Follow us on [Twitter](https://twitter.com/kava_labs) to receive the latest announcements.

View File

@ -1,64 +0,0 @@
## Earn With Kava
### Why use Mint/Lend?
**Borrowing**
Mint and Lend let users take out loans in a decentralized fashion. This democratizes finance by removing the barrier to entry, lowering friction, and removing gatekeepers.
**Lending**
Mint, Lend, and Swap let users turn their idle cryptocurrencies into interest-producing assets safely and transparently.
**Rewards**
As the protocols scale, numerous rewards are available to early adopters.DeFi applications - developers are encouraged to build new apps, integrations, and protocols in the Kava ecosystem for new business use cases.
### How can I earn money on Kava?
**Staking**
Like most Proof of Stake (PoS) blockchains, KAVA holders can stake their KAVA by either running a validator node themselves or by bonding their tokens to a third party that is running a node. Bonding temporarily locks in your coins for a 21-day. [Learn more.](https://medium.com/kava-labs/kava-staking-guide-4894b8452ab3) A list of validators can be found [here.](https://kava.bigdipper.live/validators)
**Borrowing**
Use your assets as collateral to borrow other assets, then using those to earn returns by trading or with other DeFi pursuits. Users can borrow USDX on Kava and other assets on Lend.
**Lending**
Supply assets to Kava Lend and automatically earn rewards in HARD tokens.
**Rewards**
Kava Mint
[Trust wallet guide](https://medium.com/kava-labs/borrow-usdx-on-kavas-web-app-using-trust-wallet-8540ba61f7a4).
[Minting rewards](https://medium.com/kava-labs/usdx-minting-rewards-explained-82d0b74897a2#Reward%20Calculation).
Available assets include: BNB, BTCB, BUSD-A, BUSD-B, XRPB, KAVA, UST, and HARD.
Kava Lend
Supply assets to Kava Lend to earn KAVA and HARD rewards. [Guide](https://medium.com/kava-labs/supply-and-earn-on-hard-money-market-from-binance-com-e3f54acf4b19).
Available assets include: USDX, KAVA, HARD, BNB, BUSD, BTCB, SWP, ATOM, and XRPB.
KAVA, HARD, and SWP rewards have a vesting period of either 1 month or 12 months. If you choose 12 months, the reward amount increases.
Users can earn rewards by:
- Supplying an asset to Lend.
- Borrowing against that asset.
- Supplying the borrowed asset to Mint.
- Minting USDX.
- Supplying that minted USDX to Lend.
- Supplying a pair of assets to a Swap Liquidity pool.
**Tips**
Keep a small amount of KAVA in your wallet in case you want to include a fee.
Avoid having a CDP liquidated by monitoring the collateral value, debt value, and liquidation price. If the collateral value drops below the liquidation price, your position will be liquidated. Assets from liquidated CDPs are put up for auction. If that happens, the auction typically takes 8-24 hours and you can expect ~⅓ of the collateral back (not guaranteed).
Some exchanges (like Binance) require a memo field for cross-chain transfers. If a memo is not included, those funds can be lost.
### How can I send assets to Kava?
To use assets on Kava, first move those assets to the Binance Chain (not Binance Smart Chain) and then to the Kava Chain.
This [guide](https://medium.com/kava-labs/borrow-usdx-on-kavas-web-app-using-trust-wallet-8540ba61f7a4) walks you through the process.
### Do Kava transactions require fees?
Fees are optional. They can be included if the network becomes busy, and can be added to prioritize a transaction to complete faster.
### Do Kava transactions require gas?
All transactions on the Kava blockchain consume gas.
The amount of gas consumed is proportional to the amount of computation and state access that the transaction requires.
For large and/or complex transactions, users may have to increase the amount of gas that the transaction requests above the default value.

View File

@ -1,55 +0,0 @@
## Support
### Where did my coins go? What is the deal with the hot wallet balance?
Check the status of the transaction by searching for your kava address on [Mintscan](https://www.mintscan.io/kava).
If you dont see your funds as expected, these are the most likely reasons:
- The deputy is running slowly and the transaction is still in progress
- Check to be sure that asset is visible in the Tokens tab in Trust Wallet. If the asset is not visible, search for it in the Manage tab and toggle it on.
Every cross-chain swap has an auditable record. In times of high network traffic, the deputy might not complete transactions immediately. If you encounter this issue, please wait patiently. If your transaction has not completed or refunded after 24 hours, please contact the Kava team and send us the transaction ID.
To operate cross-chain swaps, Binance must allocate a certain amount of funds for transfers into a hot wallet. As a security measure, the Binance team needs to manually refill the hot wallet from time to time. Otherwise, the rest of the cross-chain swap is completely automated.
### I have unstaked my coins, why are they still pending?
After unstaking KAVA, those coins are locked for 21 days. After that, they are released and can be used.
### Why can't I repay my CDP?
The total amount to close the position is the original loan amount plus accrued interest.
When repaying a CDP, the remaining debt balance cannot be below 10 USDX.
If you try to repay your original principal only, the transaction will fail if the remaining interest would leave a debt balance of less than 10 USDX.
If you need to purchase additional USDX to fully close out a position:
- Swap an asset for USDX on Kava Swap
- Purchase USDX on AscendEx
- Peer-to-peer transaction through [Kava TipBot](https://kavatipbot.com/)
### I have enough balance, but it says I can't transfer because my balance is too low
Check if your balance contains vested (“locked”) coins or not. If so, you need to wait for the vesting period to complete.
### I got an error during a transaction
"Error during Broadcasting - could not broadcast transaction"
This error can result from:
- closing the app
- a problem with the connection
- attempting to repeatedly send the same transaction.
Check for the transaction on the balances tab in the Kava app or the tokens tab (if you're using Cosmostation wallet) and see if it was successfully completed. If not, your tokens will still be there.
“Error during Confirming - out of gas”
- This transaction requires more than the default amount of gas.
- Note the amount of “gasUsed”
- Attempt the transaction again, and select click “Advanced” below the fee slider to be able to manually set the gas amount. If you enter an amount greater than “gasUsed,” the transaction should complete.
### Why are my transactions for 10 KAVA and 10 BNB showing up as 10,000,000 ukava and 1,000,000,000, bnb in Trust Wallet?
This is how the coins are represented in the source code. They represent the smallest indivisible unit of the currency.
- ukava is one -millionth (or 10^-6) of a KAVA coin
- bnb is one hundred-millionth (or 10^-8) of a BNB coin
### My validator node is having problems
Please contact our team through [Discord](https://discord.com/invite/kQzh3Uv), [Telegram](https://t.me/kavalabs), or Slack. Describe the problem in full with steps to reproduce.
Check the #validator-announcements channel in Discord for information regarding the potential need for an update.
Feel free to message us and we will set up a private channel on Telegram or Slack.
### Somebody from Kava support messaged me in Telegram. Are they legitimate team members?
Kava team members never message first. Please report at @notoscam and block the account. The scammer might also imitate the account of a team member changing the letters in the username. If you need assistance, find the team member in the chat user list and send them a direct message.

View File

@ -1,3 +0,0 @@
# Application Process
We are working on updating our entire documentation to provide a better user experience, please check back later!

View File

@ -1,3 +0,0 @@
# Kava DAO Governance
We are working on updating our entire documentation to provide a better user experience, please check back later!

View File

@ -1,3 +0,0 @@
# Mainnet Upgrade
We are working on updating our entire documentation to provide a better user experience, please check back later!

View File

@ -1,3 +0,0 @@
# Testnet
We are working on updating our entire documentation to provide a better user experience, please check back later!

View File

@ -1,88 +0,0 @@
## Getting Started For Developers
In order for developers to start building modules, they must install the following tools:
1. [Go 1.6 or higher](https://golang.org/doc/install)
2. [Docker](https://docs.docker.com/get-docker/)
### Go Programming Language
Go is a language developed and used by some of the largest companies in the world for server/networking applications. Go is used to develop modules and provides optimum performance and flexibility to blockchain developers.
[A Tour Of Go](https://tour.golang.org/welcome/1)
### Docker
Docker is a software containerization tool used to spin up and shut down Kava nodes and allows software portability between different operating systems & environments. It is also used to spin up multiple Kava nodes locally and handles basic networking between them with `docker compose`.
[Docker Overview](https://docs.docker.com/get-started/overview/)
### Set Up bash_profile
Once Go & Docker are installed, update your bash_profile to include the go path and an alias command for one of the tools we will use to handle Kava node interactions
```
export PATH=/usr/local/go/bin:$PATH
export PATH=$HOME/go/bin:$PATH
export GOPATH=$HOME/go
export GO111MODULE=on
alias dkvcli='docker exec -it generated_kavanode_1 kvcli'
```
Make sure to source your bash profile or restart it for the changes to take place.
## Getting The Kava Repository & Development Tools
Once you have the core tools installed & set up, its now time to get the following repositories from Github:
- [kava](https://github.com/Kava-Labs/kava)
- Main Kava Repo that holds all modules
- [kvtool](https://github.com/Kava-Labs/kvtool)
- Dev tools to interact with a Kava node
## Set Up a Local Blockchain
Now that you have set up all the tools & repositories in your local machine its finally time to set up a local blockchain.
- Open a terminal and change into the ```kvtool``` directory.
- Ensure Docker is running.
- Run ```make install``` in your terminal which will install ```kvtool``` in your machine.
- Ensure Docker is running.
- Run ```kvtool testnet bootstrap``` this command will build against the master branch from the kava project, initialize the Docker containers and finally starts a local chain.
Now that you have a local chain running, you can start utilizing the ```dkvcli``` that we set up an alias for. If for whatever reason ```dkvcli``` doesn't work, you can try the following:
- Open a terminal and change into the ```kvtool``` directory.
- In the ```kvtool``` directory there should be a directory named ```full_configs``` change into it.
- Once at ```full_configs``` directory change into ```generated``` directory.
- Once you are at ```generated``` run the following command ```docker-compose exec kavanode bash```.
This should open up a bash terminal inside a docker container that will give you access to the ```kvcli``` command line interface. You should see something similar to the snippet below after typing ```kvcli help```:
```
bash-5.0# kvcli
Command line interface for interacting with kvd
Usage:
kvcli [command]
Available Commands:
status Query remote node for status
config Create or query an application CLI configuration file
query Querying subcommands
tx Transactions subcommands
rest-server Start LCD (light-client daemon), a local REST server
keys Add or view local private keys
version Print the app version
help Help about any command
Flags:
--chain-id string Chain ID of tendermint node
-e, --encoding string Binary encoding (hex|b64|btc) (default "hex")
-h, --help help for kvcli
--home string directory for config and data (default "/root/.kvcli")
-o, --output string Output format (text|json) (default "text")
--trace print out full stack trace on errors
Use "kvcli [command] --help" for more information about a command.
```

View File

@ -1,777 +0,0 @@
# Building a Module
In this tutorial we will be going over building a module in Kava to show how easy it is to build on top of the Kava ecosystem. This module will be simple in nature but will show how to set up and connect a module to Kava and can be used as a starting point for more complex modules.
## Set up
```
this tutorial is based on the v44 cosmos version which Kava is currently migrating to, to follow this tutorial clone the kava repo but ensure you
clone the upgrade-v44 branch as the master branch is currently on v39 & ensure you have kvtool, docker & go installed on your machine.
git clone -b upgrade-v44 https://github.com/Kava-Labs/kava.git
```
## Defining Protocol Buffer Types
The first step in building a new Kava Module is to define our Module's types. To do that we use Protocol Buffers which is a used for serializing structured data and generating code for multiple target languages, Protocol Buffers are also smaller than JSON & XML so sending data around the network will be less expensive. [Learn More](https://developers.google.com/protocol-buffers).
Our Protobuf files will all live in ```proto/kava``` directory. we will create a new directory with the new module ```greet``` and add the following files in the ```proto/greet/v1beta1/``` directory
```
genesis.proto
greet.proto
query.proto
tx.proto
```
### Defining The Greet Type
Inside the ```proto/greet/v1beta1/greet.proto``` file lets define our greet type:
```
syntax = "proto3";
package kava.greet.v1beta1;
import "cosmos_proto/cosmos.proto";
import "gogoproto/gogo.proto";
option go_package = "github.com/kava-labs/kava/x/greet/types";
message Greet {
string owner = 1;
string id = 2;
string message = 3;
}
```
Here we are saying that we have a Greet type that will have an owner, an id and a message that will contain the greet string. Once we have that defined we are ready to set up a way to create this greet message and query it.
### Creating a new Greeting
Inside the ```proto/greet/v1beta1/tx.proto``` file lets define our Msg Type:
```
syntax = "proto3";
package kava.greet.v1beta1;
import "gogoproto/gogo.proto";
import "cosmos_proto/cosmos.proto";
option go_package = "github.com/kava-labs/kava/x/greet/types";
service Msg {
rpc CreateGreet(MsgCreateGreet) returns (MsgCreateGreetResponse);
}
message MsgCreateGreet {
string message = 1;
string owner = 2;
}
message MsgCreateGreetResponse {}
```
Now that we have defined how to create a new Greeting let's finish up by setting up our queries to view a specific greeting or all of them.
One thing to note here is that any state changing actions are transactions and for that reason we put them in our ```tx.proto``` files, we essentially said we are creating a new state changing message & defined the types for that message in our proto file, we will later add clients to trigger state change, which in our case will be adding a new message to our chain.
### Querying Greetings
Code inside the ```proto/greet/v1beta1/query.proto``` :
```
syntax = "proto3";
package kava.greet.v1beta1;
option go_package = "github.com/kava-labs/kava/x/greet/types";
import "gogoproto/gogo.proto";
import "google/api/annotations.proto";
import "cosmos/base/query/v1beta1/pagination.proto";
import "cosmos_proto/cosmos.proto";
import "kava/greet/v1beta1/greet.proto";
service Query {
rpc Greet(QueryGetGreetRequest) returns (QueryGetGreetResponse) {
option (google.api.http).get = "/kava/greet/v1beta1/greetings/{id}";
}
rpc GreetAll(QueryAllGreetRequest) returns (QueryAllGreetResponse) {
option (google.api.http).get = "/kava/swap/v1beta1/greetings";
}
}
message QueryGetGreetRequest {
string id = 1;
}
message QueryGetGreetResponse {
Greet greeting = 1;
}
message QueryAllGreetRequest {
cosmos.base.query.v1beta1.PageRequest pagination = 1;
}
message QueryAllGreetResponse {
repeated Greet greetings = 1;
cosmos.base.query.v1beta1.PageResponse pagination = 2;
}
```
Our ```query.proto``` now contains the types for our queries, we have defined a request type & a response type and those types will be returned once we trigger a query through the CLI, REST API, or Grpc. The response will follow the same structure regardless of the type of client initiating the request.
We defined our query, tx, and greet proto files we finally need to set up the genesis file and then we are ready to generate these types. In the genesis file we will create a minimal ```genesis.proto``` for this tutorial to keep things simple.
```
syntax = "proto3";
package kava.greet.v1beta1;
import "kava/greet/v1beta1/greet.proto";
import "gogoproto/gogo.proto";
import "google/protobuf/timestamp.proto";
import "cosmos_proto/cosmos.proto";
option go_package = "github.com/kava-labs/kava/x/greet/types";
// our gensis state message will be empty for this tutorial
message GenesisState {}
```
Once all the files are filled in we are ready to generate our proto types. in the Kava Directory run ```make proto-gen ``` to generate the types, this will create a folder inside the ```x/greet``` and will contain the auto-generated proto types.
## Developing Our Greet Module
we have successfully set up our Proto files & generated them, we now have a ```x/greet``` directory generated, this is where we will write our module's code. For starters we will define our module's types in a new file inside ```x/greet/types/greet.go```.
### Setting up constants & importing packages
Let's set up some basic constants for our module to help with routing, & fetching items from our store.
```
package types
import (
"fmt"
"strings"
"github.com/cosmos/cosmos-sdk/codec"
"github.com/cosmos/cosmos-sdk/codec/types"
sdk "github.com/cosmos/cosmos-sdk/types"
sdkerrors "github.com/cosmos/cosmos-sdk/types/errors"
"github.com/cosmos/cosmos-sdk/types/msgservice"
)
// defined our module's constants such as name, routerkey
// and prefixes for getting items from the store
const (
ModuleName = "greet"
StoreKey = ModuleName
RouterKey = ModuleName
QuerierRoute = ModuleName
GreetKey = "greet-value-" // used for getting a greeting from our store
GreetCountKey = "greet-count-" // used for getting count from out store
QueryGetGreeting = "get-greeting" // used for legacy querier routing
QueryListGreetings = "list-greetings"// used for legacy querier routing
)
// heler function simply returns []byte out of a prefix string
func KeyPrefix(p string) []byte {
return []byte(p)
}
// returns default genesis state
func DefaultGenesisState() GenesisState {
return GenesisState{}
}
// validates genesis state
func (gs GenesisState) Validate() error {
return nil
}
```
### Setting up our Msg for creating a new greeting
Our ```MsgCreateGreet``` struct was created when we generated our Proto Types, we now need to use that struct to implement the ```sdk.Msg``` interface such that we can create new greetings. the first thing we will do is defined an unnamed variable with the ```_``` syntax and have it implement the ```sdk.Msg``` type. This will help us catch unimplemented functions and guide us with syntax highlighting.
```
// MsgCreateGreet we defined it here to get type checking
//to make sure we are immplementing it correctly
var _ sdk.Msg = &MsgCreateGreet{}
// constructor for creating a new greeting
func NewMsgCreateGreet(owner string, message string) *MsgCreateGreet{
return &MsgCreateGreet{
Owner: owner,
Message: message,
}
}
// does a quick stateless validation on our new greeting
func (m *MsgCreateGreet) ValidateBasic() error {
// ensures address is valid
if _, err := sdk.AccAddressFromBech32(m.Owner); err != nil {
return sdkerrors.Wrapf(sdkerrors.ErrInvalidAddress, "invalid owner address", err)
}
// ensures the greeting is not empty
if len(strings.TrimSpace(m.Message)) == 0 {
return fmt.Errorf("must provide a greeting message")
}
return nil
}
// gets the signer of the new message which will be the owner of the greeting
func (m *MsgCreateGreet) GetSigners() []sdk.AccAddress {
owner, err := sdk.AccAddressFromBech32(m.Owner);
if err != nil {
panic(err)
}
return []sdk.AccAddress{owner}
}
```
### Registering our Codec & interfaces
now that we have our ```MsgCreateGreet``` implement the ```sdk.Msg``` interface let's register our codec for marshaling/unmarshaling our greeting we will register both the deprecated legacy amino and the new Interface registry.
```
// registers the marshal/unmarsahl for greating a new greeting for our legacy amino codec
func RegisterLegacyAminoCodec(cdc *codec.LegacyAmino){
cdc.RegisterConcrete(&MsgCreateGreet{}, "greet/CreateGreet", nil)
}
// registers a module's interface types and their concrete implementations as proto.Message.
func RegisterInterfaces(registry types.InterfaceRegistry){
registry.RegisterImplementations((*sdk.Msg)(nil), &MsgCreateGreet{})
msgservice.RegisterMsgServiceDesc(registry, &_Msg_serviceDesc)
}
var amino = codec.NewLegacyAmino()
var ModuleCdc = codec.NewAminoCodec(amino)
```
### Setting up a basic Keeper
we have finished up setting up our types, now it's time to implement our greet module's keeper, lets do that in a new folder & package named keeper, create ```x/greet/keeper/greet_keeper.go``` .
### Setting up the Keeper Struct & imports
keepers are an abstraction over the state defined by a module, every module would have a keeper which would be used to access the state of that module, or if given access a keeper can also use other module's keepers by providing reference to the other module's keeper.
```
package keeper
import (
"context"
"strconv"
"github.com/cosmos/cosmos-sdk/codec"
"github.com/cosmos/cosmos-sdk/store/prefix"
sdk "github.com/cosmos/cosmos-sdk/types"
abci "github.com/tendermint/tendermint/abci/types"
"github.com/kava-labs/kava/x/greet/types"
sdkerrors "github.com/cosmos/cosmos-sdk/types/errors"
)
type Keeper struct {
cdc codec.Codec // used to marshall and unmarshall structs from & to []byte
key sdk.StoreKey // grant access to the store
}
// our constructor for creating a new Keeper for this module
func NewKeeper(c codec.Codec, k sdk.StoreKey) Keeper {
return Keeper{
cdc: c,
key: k,
}
}
```
### Wiring up our methods for handling new transactions & queries
Now that we have our Keeper Struct written, let's create some receiver functions on our keeper to handle adding a new greeting & looking up a greeting.
```
// get greet count will be used for setting an Id when a new greeting is created
func (k Keeper) GetGreetCount(ctx sdk.Context) int64 {
store := prefix.NewStore(ctx.KVStore(k.key), types.KeyPrefix(types.GreetCountKey))
byteKey := types.KeyPrefix(types.GreetCountKey)
bz := store.Get(byteKey)
if bz == nil {
return 0
}
count, err := strconv.ParseInt(string(bz), 10, 64)
if err != nil {
panic("cannot decode count")
}
return count
}
// sets the greet count
func (k Keeper) SetGreetCount(ctx sdk.Context, count int64){
store := prefix.NewStore(ctx.KVStore(k.key), types.KeyPrefix(types.GreetCountKey))
key := types.KeyPrefix(types.GreetCountKey)
value := []byte(strconv.FormatInt(count, 10))
store.Set(key, value)
}
// creates a new greeting
func (k Keeper) CreateGreet(ctx sdk.Context, m types.MsgCreateGreet){
count := k.GetGreetCount(ctx)
greet := types.Greet{
Id: strconv.FormatInt(count, 10),
Owner: m.Owner,
Message: m.Message,
}
store := prefix.NewStore(ctx.KVStore(k.key), types.KeyPrefix(types.GreetKey))
key := types.KeyPrefix(types.GreetKey + greet.Id)
value := k.cdc.MustMarshal(&greet)
store.Set(key, value)
k.SetGreetCount(ctx, count + 1)
}
// gets a greeting from the store
func (k Keeper) GetGreeting(ctx sdk.Context, key string) types.Greet {
store := prefix.NewStore(ctx.KVStore(k.key), types.KeyPrefix(types.GreetKey))
var Greet types.Greet
k.cdc.Unmarshal(store.Get(types.KeyPrefix(types.GreetKey + key)), &Greet)
return Greet
}
// checks if a greeting exists by an id
func (k Keeper) HasGreet(ctx sdk.Context, id string) bool {
store := prefix.NewStore(ctx.KVStore(k.key), types.KeyPrefix(types.GreetKey))
return store.Has(types.KeyPrefix(types.GreetKey + id))
}
// gets the owner of a greeting
func (k Keeper) GetGreetOwner(ctx sdk.Context, key string) string {
return k.GetGreeting(ctx, key).Owner
}
// gets a list of all greetings in the store
func (k Keeper) GetAllGreetings(ctx sdk.Context) (msgs []types.Greet){
store := prefix.NewStore(ctx.KVStore(k.key), types.KeyPrefix(types.GreetKey))
iterator := sdk.KVStorePrefixIterator(store, types.KeyPrefix(types.GreetKey))
defer iterator.Close()
for ; iterator.Valid(); iterator.Next() {
var msg types.Greet
k.cdc.Unmarshal(iterator.Value(), &msg)
msgs = append(msgs, msg)
}
return
}
```
### Handling queries
We have added methods for interacting with greetings such as creating or reading them, now let's set up our two query services so we can route them to the correct method, we will set up our legacy Querier & gRPC querier below the methods we defined above on our keeper.
```
func (k Keeper) GreetAll(c context.Context, req *types.QueryAllGreetRequest) (*types.QueryAllGreetResponse, error){
ctx := sdk.UnwrapSDKContext(c)
var greetings []*types.Greet
for _, g := range k.GetAllGreetings(ctx) {
var greeting = &g
greetings = append(greetings,greeting)
}
return &types.QueryAllGreetResponse{Greetings: greetings, Pagination: nil}, nil
}
func (k Keeper) Greet(c context.Context, req *types.QueryGetGreetRequest) (*types.QueryGetGreetResponse, error){
sdk.UnwrapSDKContext(c)
var greeting = k.GetGreeting(sdk.UnwrapSDKContext(c), req.Id)
return &types.QueryGetGreetResponse{Greeting: &greeting}, nil
}
// LEGACY QUERIER will be deperacted but for the sake of competeness this is how to set it up
func NewQuerier(k Keeper, legacyQuerierCdc *codec.LegacyAmino) sdk.Querier {
return func(ctx sdk.Context, path []string, req abci.RequestQuery) ([]byte, error) {
switch path[0] {
case types.QueryGetGreeting:
var getGreetRequest types.QueryGetGreetRequest
err := legacyQuerierCdc.UnmarshalJSON(req.Data, &getGreetRequest)
if err != nil {
return nil, sdkerrors.Wrap(sdkerrors.ErrJSONUnmarshal, err.Error())
}
val := k.GetGreeting(ctx, getGreetRequest.GetId())
bz, err := legacyQuerierCdc.MarshalJSON(val)
if err != nil {
return nil, sdkerrors.Wrap(sdkerrors.ErrJSONMarshal, err.Error())
}
return bz, nil
case types.QueryListGreetings:
val := k.GetAllGreetings(ctx)
bz, err := codec.MarshalJSONIndent(legacyQuerierCdc, val)
if err != nil {
return nil, sdkerrors.Wrap(sdkerrors.ErrJSONMarshal, err.Error())
}
return bz, nil
default:
return nil, sdkerrors.Wrapf(sdkerrors.ErrUnknownRequest, "unknow request at %s query endpoint", types.ModuleName)
}
}
}
```
### Setting up a command to create a new greeting
let's set up a way for clients to submit a new greeting & query existing greetings, we can do that with a CLI, REST, & gRPC clients. for this tutorial we will focus on setting up our CLI client. create ```x/greet/client/cli/tx.go```.
here We will define a command to create a new greeting:
```
package cli
import (
"fmt"
"github.com/cosmos/cosmos-sdk/client"
"github.com/cosmos/cosmos-sdk/client/flags"
"github.com/cosmos/cosmos-sdk/client/tx"
"github.com/kava-labs/kava/x/greet/types"
"github.com/spf13/cobra"
)
func GetTxCmd() *cobra.Command {
cmd := &cobra.Command{
Use: types.ModuleName,
Short: fmt.Sprintf("%s transactions subcommands", types.ModuleName),
DisableFlagParsing: true,
SuggestionsMinimumDistance: 2,
RunE: client.ValidateCmd,
}
cmd.AddCommand(CmdCreateGreeting())
return cmd
}
func CmdCreateGreeting() *cobra.Command {
cmd:= &cobra.Command{
Use: "create-greeting [message]",
Short: "creates a new greetings",
Args: cobra.ExactArgs(1),
RunE: func(cmd *cobra.Command, args []string) error {
message := string(args[0])
clientCtx, err := client.GetClientTxContext(cmd)
if err != nil {
return err
}
msg := types.NewMsgCreateGreet(clientCtx.GetFromAddress().String(), string(message))
if err := msg.ValidateBasic(); err != nil {
return err
}
return tx.GenerateOrBroadcastTxCLI(clientCtx, cmd.Flags(), msg)
},
}
flags.AddTxFlagsToCmd(cmd)
return cmd
}
```
### Querying greetings
We will now set up two different commands for querying, one will be to list all greetings & the other will be to get a greeting by it's id. inside ```x/greet/cli/query.go```:
```
package cli
import (
"context"
"fmt"
"github.com/cosmos/cosmos-sdk/client"
"github.com/cosmos/cosmos-sdk/client/flags"
"github.com/kava-labs/kava/x/greet/types"
"github.com/spf13/cobra"
)
// this is the parent query command for the greet module everytime we add a new command we will register it here
func GetQueryCmd(queryRoute string) *cobra.Command {
// Group todos queries under a subcommand
cmd := &cobra.Command{
Use: types.ModuleName,
Short: fmt.Sprintf("Querying commands for the %s module", types.ModuleName),
DisableFlagParsing: true,
SuggestionsMinimumDistance: 2,
RunE: client.ValidateCmd,
}
cmd.AddCommand(CmdListGreetings())
cmd.AddCommand(CmdShowGreeting())
return cmd
}
// build the list greet command function
func CmdListGreetings() *cobra.Command {
cmd := &cobra.Command{
Use: "list-greetings",
Short: "list all greetings",
RunE: func(cmd *cobra.Command, args []string) error {
clientCtx, err := client.GetClientTxContext(cmd)
if err != nil {
return err
}
pageReq, err := client.ReadPageRequest(cmd.Flags())
if err != nil {
return err
}
queryClient := types.NewQueryClient(clientCtx)
params := &types.QueryAllGreetRequest{
Pagination: pageReq,
}
res, err := queryClient.GreetAll(context.Background(), params)
if err != nil {
return err
}
return clientCtx.PrintProto(res)
},
}
flags.AddQueryFlagsToCmd(cmd)
return cmd
}
// build the show greet command function
func CmdShowGreeting() *cobra.Command {
cmd := &cobra.Command{
Use: "get-greeting [id]",
Short: "shows a greeting",
Args: cobra.ExactArgs(1),
RunE: func(cmd *cobra.Command, args []string) error {
clientCtx, err := client.GetClientTxContext(cmd)
if err != nil {
return err
}
queryClient := types.NewQueryClient(clientCtx)
params := &types.QueryGetGreetRequest{
Id: args[0],
}
res, err := queryClient.Greet(context.Background(), params)
if err != nil {
return err
}
return clientCtx.PrintProto(res)
},
}
flags.AddQueryFlagsToCmd(cmd)
return cmd
}
```
### Setting up our Module's package
Now that we have all the basic functionality set up for our greet module, let's bring it all together and get our module ready to be used & tested, create a new file ```x/greet/module.go```.
Here we will start by implementing our ```AppModuleBasic``` && ```AppModule``` interfaces.
```
package greet
import (
"context"
"encoding/json"
"github.com/cosmos/cosmos-sdk/client"
"github.com/cosmos/cosmos-sdk/codec"
cdctypes "github.com/cosmos/cosmos-sdk/codec/types"
sdk "github.com/cosmos/cosmos-sdk/types"
"github.com/cosmos/cosmos-sdk/types/module"
"github.com/gorilla/mux"
"github.com/grpc-ecosystem/grpc-gateway/runtime"
"github.com/kava-labs/kava/x/greet/client/cli"
"github.com/kava-labs/kava/x/greet/keeper"
"github.com/kava-labs/kava/x/greet/types"
"github.com/spf13/cobra"
abci "github.com/tendermint/tendermint/abci/types"
)
var (
_ module.AppModule = AppModule{}
_ module.AppModuleBasic = AppModuleBasic{}
)
/*
The AppModuleBasic interface defines the independent methods modules need to implement
it follows this interface below
type AppModuleBasic interface {
Name() string
RegisterLegacyAminoCodec(*codec.LegacyAmino)
RegisterInterfaces(codectypes.InterfaceRegistry)
DefaultGenesis(codec.JSONMarshaler) json.RawMessage
ValidateGenesis(codec.JSONMarshaler, client.TxEncodingConfig, json.RawMessage) error
// client functionality
RegisterRESTRoutes(client.Context, *mux.Router)
RegisterGRPCRoutes(client.Context, *runtime.ServeMux)
GetTxCmd() *cobra.Command
GetQueryCmd() *cobra.Command
}
*/
type AppModuleBasic struct{}
// Returns the name of the module as a string
func (AppModuleBasic) Name() string {
return types.ModuleName
}
func (AppModuleBasic) DefaultGenesis(cdc codec.JSONCodec) json.RawMessage {
gs := types.DefaultGenesisState()
return cdc.MustMarshalJSON(&gs)
}
func (AppModuleBasic) ValidateGenesis(cdc codec.JSONCodec, config client.TxEncodingConfig, bz json.RawMessage) error {
return nil
}
// Registers the amino codec for the module, which is used to marshal
// and unmarshal structs to/from []byte in order to persist them in the module's KVStore.
func (AppModuleBasic) RegisterLegacyAminoCodec(cdc *codec.LegacyAmino){
types.RegisterLegacyAminoCodec(cdc)
}
// Registers a module's interface types and their concrete implementations as proto.Message
func (AppModuleBasic) RegisterInterfaces(registry cdctypes.InterfaceRegistry) {
types.RegisterInterfaces(registry)
}
// Registers gRPC routes for the module.
func (a AppModuleBasic) RegisterGRPCGatewayRoutes(clientCtx client.Context, mux *runtime.ServeMux) {
if err := types.RegisterQueryHandlerClient(context.Background(), mux, types.NewQueryClient(clientCtx)); err != nil {
panic(err)
}
}
// Registers the REST routes for the module. These routes will be used to map REST request to the module in order to process them
func (a AppModuleBasic) RegisterRESTRoutes(clientCtx client.Context, rtr *mux.Router) { }
// Returns the root Tx command for the module. The subcommands of this root command are used by end-users
// to generate new transactions containing messages defined in the module
func (AppModuleBasic) GetTxCmd() *cobra.Command {
return cli.GetTxCmd()
}
// Return the root query command for the module. The subcommands of this root command are used by end-users
// to generate new queries to the subset of the state defined by the module.
func (AppModuleBasic) GetQueryCmd() *cobra.Command {
return cli.GetQueryCmd(types.StoreKey)
}
// -------------------------------------APPMODULE BELOW------------------------------------------------- //
/*
The AppModule interface defines the inter-dependent methods that modules need to implement
follows the interface below
type AppModule interface {
AppModuleGenesis
// registers
RegisterInvariants(sdk.InvariantRegistry)
// routes
Route() sdk.Route
// Deprecated: use RegisterServices
QuerierRoute() string
// Deprecated: use RegisterServices
LegacyQuerierHandler(*codec.LegacyAmino) sdk.Querier
// RegisterServices allows a module to register services
RegisterServices(Configurator)
// ABCI
BeginBlock(sdk.Context, abci.RequestBeginBlock)
EndBlock(sdk.Context, abci.RequestEndBlock) []abci.ValidatorUpdate
}
*/
type AppModule struct{
AppModuleBasic
keeper keeper.Keeper
}
// constructor
func NewAppModule(keeper keeper.Keeper) AppModule {
return AppModule{
AppModuleBasic: AppModuleBasic{},
keeper: keeper,
}
}
// Returns the route for messages to be routed to the module by BaseApp.
func (am AppModule) Name() string {
return am.AppModuleBasic.Name()
}
// registers the invariants of the module. If an invariant deviates from its predicted value,
// the InvariantRegistry triggers appropriate logic (most often the chain will be halted).
func (AppModule) RegisterInvariants(ir sdk.InvariantRegistry) { }
// Returns the route for messages to be routed to the module by BaseApp.
func (AppModule) Route() sdk.Route {
return sdk.Route{}
}
// Returns the name of the module's query route, for queries to be routes to the module by BaseApp.deprecated
func (AppModule) QuerierRoute() string {
return types.QuerierRoute
}
// Returns a querier given the query path, in order to process the query.
func (am AppModule) LegacyQuerierHandler(legacyQuerierCdc *codec.LegacyAmino) sdk.Querier {
return keeper.NewQuerier(am.keeper, legacyQuerierCdc)
}
func (AppModule) ConsensusVersion() uint64 {
return 1
}
// Allows a module to register services.
func (am AppModule) RegisterServices(cfg module.Configurator) {
types.RegisterMsgServer(cfg.MsgServer(), NewMsgServerImpl(am.keeper))
types.RegisterQueryServer(cfg.QueryServer(), am.keeper)
}
func (am AppModule) InitGenesis(ctx sdk.Context, cdc codec.JSONCodec, gs json.RawMessage) []abci.ValidatorUpdate {
return []abci.ValidatorUpdate{}
}
func (am AppModule) ExportGenesis(ctx sdk.Context, cdc codec.JSONCodec) json.RawMessage {
gs := types.DefaultGenesisState()
return cdc.MustMarshalJSON(&gs)
}
func (am AppModule) BeginBlock(_ sdk.Context, _ abci.RequestBeginBlock) { }
func (am AppModule) EndBlock(_ sdk.Context, _ abci.RequestEndBlock) []abci.ValidatorUpdate {
return []abci.ValidatorUpdate{}
}
// ----------------------------------MSGSERVER REGISTER------------------------//
var _ types.MsgServer = msgServer{}
type msgServer struct {
keeper keeper.Keeper
}
func (m msgServer) CreateGreet(c context.Context, msg *types.MsgCreateGreet) (*types.MsgCreateGreetResponse, error) {
ctx := sdk.UnwrapSDKContext(c)
m.keeper.CreateGreet(ctx, types.MsgCreateGreet{Owner: msg.Owner, Message: msg.Message})
return &types.MsgCreateGreetResponse{}, nil
}
func NewMsgServerImpl(keeper keeper.Keeper) types.MsgServer {
return &msgServer{keeper: keeper}
}
```
### Hooking up our module inside App.go
inside ```app/app.go``` start off importing the greet module, it's types & keeper packages and add them to the following places:
1. ```module.NewBasicManager()``` add ```greet.AppModuleBasic{}```
2. ```type App struct {}``` add ```greetkeeper.Keeper```
3. ```sdk.NewKVStoreKeys()``` inside ```NewApp``` func add ```greettypes.StoreKey```
4. inside ```NewApp``` func add ```app.greetKeeper = greetKeeper.NewKeeper()``` and add arguments ```appCodec``` & ```keys[greettypes.StoreKey]```
5. inside ```NewApp``` find where we define ```app.mm``` & add ```greet.NewAppModule(app.greetKeeper),```
6. finally add the greet module's name to ```SetOrderBeginBlockers```, ```SetOrderEndBlockers``` && ```SetOrderInitGenesis```
## Testing our new Module
1. inside the root of our directory run ```docker build -t kava/kava:tutorial-demo .```
2. find the directory for ```kvtool``` and open in your favorite code editor
3. run ```kvtool testnet gen-config kava --kava.configTemplate upgrade-v44``` which will create a bunch of files inside ```full_configs/generated```
4. open up the two ```docker-compose.yaml``` files the one inside ```generated``` & the one inside ```generated/kava``` and change the image to point to ```kava/kava:tutorial-demo``` this will point to the local image we just built
5. change into the ```full_configs/generated``` directory and run ```docker compose up -d```
6. now run ```docker compose exec kavanode bash``` to bash into our ```kava``` cli inside the running container
We should now have access to our greet commands that we defined first we will test creating a new greeting, for that we will run the following command:
```kava tx greet create-greeting "hello world from kava chain" --from whale```
now let's test to see if the greeting message is able to be queried:
```kava q greet list-greetings```
We should see something like this below:
```
greetings:
- id: "0"
message: hello world from kava chain
owner: kava173w2zz287s36ewnnkf4mjansnthnnsz7rtrxqc
pagination: null
```
Now let's test if we can query the greeting by it's id which in our case will be ```"0"```, run the following:
```kava q greet get-greeting 0```
We should see:
```
greeting:
id: "0"
message: hello world from kava chain
owner: kava173w2zz287s36ewnnkf4mjansnthnnsz7rtrxqc
```

View File

@ -1,3 +0,0 @@
# Lite Paper
We are working on updating our entire documentation to provide a better user experience, please check back later!

View File

@ -1,50 +0,0 @@
<!--
title: vote
-->
## kava tx committee vote
Vote for an active proposal
### Synopsis
Submit a ```[yes/no/abstain]``` vote for the proposal with id ```[proposal-id]```.
```
kava tx committee vote [proposal-id] [vote] [flags]
```
### Examples
```
kava tx committee vote 2 yes
```
### Options
```
-a, --account-number uint The account number of the signing account (offline mode only)
-b, --broadcast-mode string Transaction broadcasting mode (sync|async|block) (default "sync")
--dry-run ignore the --gas flag and perform a simulation of a transaction, but don't broadcast it
--fees string Fees to pay along with transaction; eg: 10uatom
--from string Name or address of private key with which to sign
--gas string gas limit to set per-transaction; set to "auto" to calculate required gas automatically (default 200000) (default "200000")
--gas-adjustment float adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored (default 1)
--gas-prices string Gas prices to determine the transaction fee (e.g. 10uatom)
--generate-only Build an unsigned transaction and write it to STDOUT (when enabled, the local Keybase is not accessible and the node operates offline)
-h, --help help for vote
--indent Add indent to JSON response
--keyring-backend string Select keyring's backend (os|file|test) (default "os")
--ledger Use a connected Ledger device
--memo string Memo to send along with transaction
--node string <host>:<port> to tendermint rpc interface for this chain (default "tcp://localhost:26657")
-s, --sequence uint The sequence number of the signing account (offline mode only)
--trust-node Trust connected full node (don't verify proofs for responses) (default true)
-y, --yes Skip tx broadcasting prompt confirmation
```
### Options inherited from parent commands
```
--chain-id string Chain ID of tendermint node
```

View File

@ -1,95 +0,0 @@
<!--
title: committee
-->
## kava tx gov submit-proposal committee
Submit a governance proposal to change a committee.
### Synopsis
Submit a governance proposal to create, alter, or delete a committee.
The proposal file must be the json encoded form of the proposal type you want to submit.
For example, to create or update a committee:
```
{
"type": "kava/CommitteeChangeProposal",
"value": {
"title": "A Title",
"description": "A description of this proposal.",
"new_committee": {
"type": "kava/MemberCommittee",
"value": {
"base_committee": {
"id": "1",
"description": "The description of this committee.",
"members": [
"kava182k5kyx9sy4ap624gm9gukr3jfj7fdx8jzrdgq"
],
"permissions": [
{
"type": "kava/SimpleParamChangePermission",
"value": {
"allowed_params": [
{
"subspace": "cdp",
"key": "CircuitBreaker"
}
]
}
}
],
"vote_threshold": "0.800000000000000000",
"proposal_duration": "604800000000000",
"tally_option": "FirstPastThePost"
}
}
}
}
}
```
and to delete a committee:
```
{
"type": "kava/CommitteeDeleteProposal",
"value": {
"title": "A Title",
"description": "A description of this proposal.",
"committee_id": "1"
}
}
```
```
kava tx gov submit-proposal committee [proposal-file] [deposit] [flags]
```
### Options
```
-a, --account-number uint The account number of the signing account (offline mode only)
-b, --broadcast-mode string Transaction broadcasting mode (sync|async|block) (default "sync")
--dry-run ignore the --gas flag and perform a simulation of a transaction, but don't broadcast it
--fees string Fees to pay along with transaction; eg: 10uatom
--from string Name or address of private key with which to sign
--gas string gas limit to set per-transaction; set to "auto" to calculate required gas automatically (default 200000) (default "200000")
--gas-adjustment float adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored (default 1)
--gas-prices string Gas prices to determine the transaction fee (e.g. 10uatom)
--generate-only Build an unsigned transaction and write it to STDOUT (when enabled, the local Keybase is not accessible and the node operates offline)
-h, --help help for committee
--indent Add indent to JSON response
--keyring-backend string Select keyring's backend (os|file|test) (default "os")
--ledger Use a connected Ledger device
--memo string Memo to send along with transaction
--node string <host>:<port> to tendermint rpc interface for this chain (default "tcp://localhost:26657")
-s, --sequence uint The sequence number of the signing account (offline mode only)
--trust-node Trust connected full node (don't verify proofs for responses) (default true)
-y, --yes Skip tx broadcasting prompt confirmation
```
### Options inherited from parent commands
```
--chain-id string Chain ID of tendermint node
```

View File

@ -1,80 +0,0 @@
<!--
title: param-change
-->
## kava tx gov submit-proposal param-change
Submit a parameter change proposal
### Synopsis
Submit a parameter proposal along with an initial deposit.
The proposal details must be supplied via a JSON file. For values that contains
objects, only non-empty fields will be updated.
IMPORTANT: Currently parameter changes are evaluated but not validated, so it is
very important that any "value" change is valid (ie. correct type and within bounds)
for its respective parameter, eg. "MaxValidators" should be an integer and not a decimal.
Proper vetting of a parameter change proposal should prevent this from happening
(no deposits should occur during the governance process), but it should be noted
regardless.
Example:
```
$ kava tx gov submit-proposal param-change <path/to/proposal.json> --from=<key_or_address>
```
Where proposal.json contains:
```
{
"title": "Staking Param Change",
"description": "Update max validators",
"changes": [
{
"subspace": "staking",
"key": "MaxValidators",
"value": 105
}
],
"deposit": [
{
"denom": "stake",
"amount": "10000"
}
]
}
```
```
kava tx gov submit-proposal param-change [proposal-file] [flags]
```
### Options
```
-a, --account-number uint The account number of the signing account (offline mode only)
-b, --broadcast-mode string Transaction broadcasting mode (sync|async|block) (default "sync")
--dry-run ignore the --gas flag and perform a simulation of a transaction, but don't broadcast it
--fees string Fees to pay along with transaction; eg: 10uatom
--from string Name or address of private key with which to sign
--gas string gas limit to set per-transaction; set to "auto" to calculate required gas automatically (default 200000) (default "200000")
--gas-adjustment float adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored (default 1)
--gas-prices string Gas prices to determine the transaction fee (e.g. 10uatom)
--generate-only Build an unsigned transaction and write it to STDOUT (when enabled, the local Keybase is not accessible and the node operates offline)
-h, --help help for param-change
--indent Add indent to JSON response
--keyring-backend string Select keyring's backend (os|file|test) (default "os")
--ledger Use a connected Ledger device
--memo string Memo to send along with transaction
--node string <host>:<port> to tendermint rpc interface for this chain (default "tcp://localhost:26657")
-s, --sequence uint The sequence number of the signing account (offline mode only)
--trust-node Trust connected full node (don't verify proofs for responses) (default true)
-y, --yes Skip tx broadcasting prompt confirmation
```
### Options inherited from parent commands
```
--chain-id string Chain ID of tendermint node
```

View File

@ -1,50 +0,0 @@
# Borrow
Borrow tokens from the hard protocol
## Command
```
kava tx hard borrow <amount> <flags>
```
Using ```kava``` call the ```tx``` subcommand followed by the module name which is```hard```, then define the action which is ```borrow``` and finally follow up with required arguments or flags.
### Arguments
position|name|expects
|--|--|--|
1|amount| amount & name (no spaces)
### Example
```
kava tx hard borrow 1000000000ukava --from <key>
```
### Options
```
-a, --account-number uint The account number of the signing account (offline mode only)
-b, --broadcast-mode string Transaction broadcasting mode (sync|async|block) (default "sync")
--dry-run ignore the --gas flag and perform a simulation of a transaction, but don't broadcast it
--fees string Fees to pay along with transaction; eg: 10uatom
--from string Name or address of private key with which to sign
--gas string gas limit to set per-transaction; set to "auto" to calculate required gas automatically (default 200000) (default "200000")
--gas-adjustment float adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored (default 1)
--gas-prices string Gas prices to determine the transaction fee (e.g. 10uatom)
--generate-only Build an unsigned transaction and write it to STDOUT (when enabled, the local Keybase is not accessible and the node operates offline)
-h, --help help for borrow
--indent Add indent to JSON response
--keyring-backend string Select keyring's backend (os|file|test) (default "os")
--ledger Use a connected Ledger device
--memo string Memo to send along with transaction
--node string <host>:<port> to tendermint rpc interface for this chain (default "tcp://localhost:26657")
-s, --sequence uint The sequence number of the signing account (offline mode only)
--trust-node Trust connected full node (don't verify proofs for responses) (default true)
-y, --yes Skip tx broadcasting prompt confirmation
```
### Options inherited from parent commands
```
--chain-id string Chain ID of tendermint node
```

View File

@ -1,53 +0,0 @@
# Deposit
Deposit coins to hard
## Command
```
kava tx hard deposit <amount> <flags>
```
Using ```kava``` call the ```tx``` subcommand followed by the module name which is```hard```, then define the action which is ```deposit``` and finally follow up with required arguments or flags.
### Arguments
position|name|expects
|--|--|--|
1|amount| amount & name (no spaces)
### Example
```
kava tx hard deposit 10000000bnb --from <key>
```
### Options
```
-a, --account-number uint The account number of the signing account (offline mode only)
-b, --broadcast-mode string Transaction broadcasting mode (sync|async|block) (default "sync")
--dry-run ignore the --gas flag and perform a simulation of a transaction, but don't broadcast it
--fees string Fees to pay along with transaction; eg: 10uatom
--from string Name or address of private key with which to sign
--gas string gas limit to set per-transaction; set to "auto" to calculate required gas automatically (default 200000) (default "200000")
--gas-adjustment float adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored (default 1)
--gas-prices string Gas prices to determine the transaction fee (e.g. 10uatom)
--generate-only Build an unsigned transaction and write it to STDOUT (when enabled, the local Keybase is not accessible and the node operates offline)
-h, --help help for deposit
--indent Add indent to JSON response
--keyring-backend string Select keyring's backend (os|file|test) (default "os")
--ledger Use a connected Ledger device
--memo string Memo to send along with transaction
--node string <host>:<port> to tendermint rpc interface for this chain (default "tcp://localhost:26657")
-s, --sequence uint The sequence number of the signing account (offline mode only)
--trust-node Trust connected full node (don't verify proofs for responses) (default true)
-y, --yes Skip tx broadcasting prompt confirmation
```
### Options inherited from parent commands
```
--chain-id string Chain ID of tendermint node
```

View File

@ -1,56 +0,0 @@
# Repay
Repay tokens to the hard protocol
## Command
```
kava tx hard repay <amount> <flags>
```
Using ```kava``` call the ```tx``` subcommand followed by the module name which is```hard```, then define the action which is ```repay``` and finally follow up with required arguments or flags.
### Arguments
position|name|expects
|--|--|--|
1|amount| amount & name (no spaces)
### Example
```
kava tx hard repay 1000000000ukava --from <key>
kava tx hard repay 1000000000ukava,25000000000bnb --from <key>
kava tx hard repay 1000000000ukava,25000000000bnb --owner <owner-address> --from <key>
```
### Options
```
-a, --account-number uint The account number of the signing account (offline mode only)
-b, --broadcast-mode string Transaction broadcasting mode (sync|async|block) (default "sync")
--dry-run ignore the --gas flag and perform a simulation of a transaction, but don't broadcast it
--fees string Fees to pay along with transaction; eg: 10uatom
--from string Name or address of private key with which to sign
--gas string gas limit to set per-transaction; set to "auto" to calculate required gas automatically (default 200000) (default "200000")
--gas-adjustment float adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored (default 1)
--gas-prices string Gas prices to determine the transaction fee (e.g. 10uatom)
--generate-only Build an unsigned transaction and write it to STDOUT (when enabled, the local Keybase is not accessible and the node operates offline)
-h, --help help for repay
--indent Add indent to JSON response
--keyring-backend string Select keyring's backend (os|file|test) (default "os")
--ledger Use a connected Ledger device
--memo string Memo to send along with transaction
--node string <host>:<port> to tendermint rpc interface for this chain (default "tcp://localhost:26657")
--owner string original borrower's address whose loan will be repaid
-s, --sequence uint The sequence number of the signing account (offline mode only)
--trust-node Trust connected full node (don't verify proofs for responses) (default true)
-y, --yes Skip tx broadcasting prompt confirmation
```
### Options inherited from parent commands
```
--chain-id string Chain ID of tendermint node
```

View File

@ -1,53 +0,0 @@
# Withdraw
Withdraw coins from hard
## Command
```
kava tx hard withdraw <amount> <flags>
```
Using ```kava``` call the ```tx``` subcommand followed by the module name which is```hard```, then define the action which is ```withdraw``` and finally follow up with required arguments or flags.
### Arguments
position|name|expects
|--|--|--|
1|amount| amount & name (no spaces)
### Example
```
kava tx hard withdraw 10000000bnb --from <key>
```
### Options
```
-a, --account-number uint The account number of the signing account (offline mode only)
-b, --broadcast-mode string Transaction broadcasting mode (sync|async|block) (default "sync")
--dry-run ignore the --gas flag and perform a simulation of a transaction, but don't broadcast it
--fees string Fees to pay along with transaction; eg: 10uatom
--from string Name or address of private key with which to sign
--gas string gas limit to set per-transaction; set to "auto" to calculate required gas automatically (default 200000) (default "200000")
--gas-adjustment float adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored (default 1)
--gas-prices string Gas prices to determine the transaction fee (e.g. 10uatom)
--generate-only Build an unsigned transaction and write it to STDOUT (when enabled, the local Keybase is not accessible and the node operates offline)
-h, --help help for withdraw
--indent Add indent to JSON response
--keyring-backend string Select keyring's backend (os|file|test) (default "os")
--ledger Use a connected Ledger device
--memo string Memo to send along with transaction
--node string <host>:<port> to tendermint rpc interface for this chain (default "tcp://localhost:26657")
-s, --sequence uint The sequence number of the signing account (offline mode only)
--trust-node Trust connected full node (don't verify proofs for responses) (default true)
-y, --yes Skip tx broadcasting prompt confirmation
```
### Options inherited from parent commands
```
--chain-id string Chain ID of tendermint node
```

View File

@ -1,51 +0,0 @@
# Create New CDP
Create a new cdp, depositing some collateral and drawing some debt.
## Command
```
kava tx cdp create <collateral> <debt> <collateral-type> <flags>
```
Using ```kava``` call the ```tx``` subcommand followed by the module name which is```cdp```, then define the action which is ```create``` and finally follow up with required arguments or flags.
### Arguments
position|name|expects
|--|--|--|
1|collateral| amount & name (no spaces)
2|debt| amount & name (no spaces)
3|collateral-type| name
### Example
```
kava tx cdp create 10000000uatom 1000usdx atom-a --from myKeyName
```
### Options
```
-a, --account-number uint The account number of the signing account (offline mode only)
-b, --broadcast-mode string Transaction broadcasting mode (sync|async|block) (default "sync")
--dry-run ignore the --gas flag and perform a simulation of a transaction, but don't broadcast it
--fees string Fees to pay along with transaction; eg: 10uatom
--from string Name or address of private key with which to sign
--gas string gas limit to set per-transaction; set to "auto" to calculate required gas automatically (default 200000) (default "200000")
--gas-adjustment float adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored (default 1)
--gas-prices string Gas prices to determine the transaction fee (e.g. 10uatom)
--generate-only Build an unsigned transaction and write it to STDOUT (when enabled, the local Keybase is not accessible and the node operates offline)
-h, --help help for create
--indent Add indent to JSON response
--keyring-backend string Select keyring's backend (os|file|test) (default "os")
--ledger Use a connected Ledger device
--memo string Memo to send along with transaction
--node string <host>:<port> to tendermint rpc interface for this chain (default "tcp://localhost:26657")
-s, --sequence uint The sequence number of the signing account (offline mode only)
--trust-node Trust connected full node (don't verify proofs for responses) (default true)
-y, --yes Skip tx broadcasting prompt confirmation
```
### Options inherited from parent commands
```
--chain-id string Chain ID of tendermint node
```

View File

@ -1,51 +0,0 @@
# Add Collateral
Add collateral to an existing cdp.
## Command
```
kava tx cdp deposit <owner-addr> <collateral> <collateral-type> <flags>
```
Using ```kava``` call the ```tx``` subcommand followed by the module name which is```cdp```, then define the action which is ```deposit``` and finally follow up with required arguments or flags.
### Arguments
position|name|expects
|--|--|--|
1|owner-addr| kava address
2|collateral| amount & name (no spaces)
3|collateral-type| name
### Example
```
kava tx cdp deposit kava15qdefkmwswysgg4qxgqpqr35k3m49pkx2jdfnw 10000000uatom atom-a --from myKeyName
```
### Options
```
-a, --account-number uint The account number of the signing account (offline mode only)
-b, --broadcast-mode string Transaction broadcasting mode (sync|async|block) (default "sync")
--dry-run ignore the --gas flag and perform a simulation of a transaction, but don't broadcast it
--fees string Fees to pay along with transaction; eg: 10uatom
--from string Name or address of private key with which to sign
--gas string gas limit to set per-transaction; set to "auto" to calculate required gas automatically (default 200000) (default "200000")
--gas-adjustment float adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored (default 1)
--gas-prices string Gas prices to determine the transaction fee (e.g. 10uatom)
--generate-only Build an unsigned transaction and write it to STDOUT (when enabled, the local Keybase is not accessible and the node operates offline)
-h, --help help for deposit
--indent Add indent to JSON response
--keyring-backend string Select keyring's backend (os|file|test) (default "os")
--ledger Use a connected Ledger device
--memo string Memo to send along with transaction
--node string <host>:<port> to tendermint rpc interface for this chain (default "tcp://localhost:26657")
-s, --sequence uint The sequence number of the signing account (offline mode only)
--trust-node Trust connected full node (don't verify proofs for responses) (default true)
-y, --yes Skip tx broadcasting prompt confirmation
```
### Options inherited from parent commands
```
--chain-id string Chain ID of tendermint node
```

View File

@ -1,51 +0,0 @@
# Draw Debt
Create debt in an existing cdp and send the newly minted asset to your account.
## Command
```
kava tx cdp draw <collateral-type> <debt> <flags>
```
Using ```kava``` call the ```tx``` subcommand followed by the module name which is```cdp```, then define the action which is ```draw``` and finally follow up with required arguments or flags.
### Arguments
position|name|expects
|--|--|--|
1|collateral-type| name
2|debt| amount & name (no spaces)
### Example
```
kava tx cdp draw atom-a 1000usdx --from myKeyName
```
### Options
```
-a, --account-number uint The account number of the signing account (offline mode only)
-b, --broadcast-mode string Transaction broadcasting mode (sync|async|block) (default "sync")
--dry-run ignore the --gas flag and perform a simulation of a transaction, but don't broadcast it
--fees string Fees to pay along with transaction; eg: 10uatom
--from string Name or address of private key with which to sign
--gas string gas limit to set per-transaction; set to "auto" to calculate required gas automatically (default 200000) (default "200000")
--gas-adjustment float adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored (default 1)
--gas-prices string Gas prices to determine the transaction fee (e.g. 10uatom)
--generate-only Build an unsigned transaction and write it to STDOUT (when enabled, the local Keybase is not accessible and the node operates offline)
-h, --help help for draw
--indent Add indent to JSON response
--keyring-backend string Select keyring's backend (os|file|test) (default "os")
--ledger Use a connected Ledger device
--memo string Memo to send along with transaction
--node string <host>:<port> to tendermint rpc interface for this chain (default "tcp://localhost:26657")
-s, --sequence uint The sequence number of the signing account (offline mode only)
--trust-node Trust connected full node (don't verify proofs for responses) (default true)
-y, --yes Skip tx broadcasting prompt confirmation
```
### Options inherited from parent commands
```
--chain-id string Chain ID of tendermint node
```

View File

@ -1,53 +0,0 @@
# Repay Debt
Repay debt to an existing cdp
## Command
```
kava tx cdp repay <collateral-name> <debt> <flags>
```
Using ```kava``` call the ```tx``` subcommand followed by the module name which is```cdp```, then define the action which is ```repay``` and finally follow up with required arguments or flags.
### Arguments
position|name|expects
|--|--|--|
1|collateral-name| name
2|debt| amount & name (no spaces)
### Example
```
kava tx cdp repay atom-a 1000usdx --from myKeyName
```
### Options
```
-a, --account-number uint The account number of the signing account (offline mode only)
-b, --broadcast-mode string Transaction broadcasting mode (sync|async|block) (default "sync")
--dry-run ignore the --gas flag and perform a simulation of a transaction, but don't broadcast it
--fees string Fees to pay along with transaction; eg: 10uatom
--from string Name or address of private key with which to sign
--gas string gas limit to set per-transaction; set to "auto" to calculate required gas automatically (default 200000) (default "200000")
--gas-adjustment float adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored (default 1)
--gas-prices string Gas prices to determine the transaction fee (e.g. 10uatom)
--generate-only Build an unsigned transaction and write it to STDOUT (when enabled, the local Keybase is not accessible and the node operates offline)
-h, --help help for repay
--indent Add indent to JSON response
--keyring-backend string Select keyring's backend (os|file|test) (default "os")
--ledger Use a connected Ledger device
--memo string Memo to send along with transaction
--node string <host>:<port> to tendermint rpc interface for this chain (default "tcp://localhost:26657")
-s, --sequence uint The sequence number of the signing account (offline mode only)
--trust-node Trust connected full node (don't verify proofs for responses) (default true)
-y, --yes Skip tx broadcasting prompt confirmation
--chain-id string Chain ID of tendermint node
```
### Options inherited from parent commands
```
--chain-id string Chain ID of tendermint node
```

View File

@ -1,51 +0,0 @@
# Remove Collateral
Withdraw collateral from an existing cdp
## Command
```
kava tx cdp withdraw <owner-addr> <collateral> <collateral-type> <flags>
```
Using ```kava``` call the ```tx``` subcommand followed by the module name which is```cdp```, then define the action which is ```withdraw``` and finally follow up with required arguments or flags.
### Arguments
position|name|expects
|--|--|--|
1|owner-addr| kava address
2|collateral| amount & name (no spaces)
3|collateral-type| name
### Example
```
kava tx cdp withdraw kava15qdefkmwswysgg4qxgqpqr35k3m49pkx2jdfnw 10000000uatom atom-a --from myKeyName
```
### Options
```
-a, --account-number uint The account number of the signing account (offline mode only)
-b, --broadcast-mode string Transaction broadcasting mode (sync|async|block) (default "sync")
--dry-run ignore the --gas flag and perform a simulation of a transaction, but don't broadcast it
--fees string Fees to pay along with transaction; eg: 10uatom
--from string Name or address of private key with which to sign
--gas string gas limit to set per-transaction; set to "auto" to calculate required gas automatically (default 200000) (default "200000")
--gas-adjustment float adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored (default 1)
--gas-prices string Gas prices to determine the transaction fee (e.g. 10uatom)
--generate-only Build an unsigned transaction and write it to STDOUT (when enabled, the local Keybase is not accessible and the node operates offline)
-h, --help help for withdraw
--indent Add indent to JSON response
--keyring-backend string Select keyring's backend (os|file|test) (default "os")
--ledger Use a connected Ledger device
--memo string Memo to send along with transaction
--node string <host>:<port> to tendermint rpc interface for this chain (default "tcp://localhost:26657")
-s, --sequence uint The sequence number of the signing account (offline mode only)
--trust-node Trust connected full node (don't verify proofs for responses) (default true)
-y, --yes Skip tx broadcasting prompt confirmation
```
### Options inherited from parent commands
```
--chain-id string Chain ID of tendermint node
```

View File

@ -1,57 +0,0 @@
# Deposit
Deposit coins to a swap liquidity pool
## Command
```
kava tx swap deposit <tokenA> <tokenB> <slippage> <deadline> <flags>
```
Using ```kava``` call the ```tx``` subcommand followed by the module name which is```swap```, then define the action which is ```deposit``` and finally follow up with required arguments or flags.
### Arguments
position|name|expects
|--|--|--|
1|tokenA| amount & name (no spaces)
2|tokenB| amount & name (no spaces)
3|slippage| percentage float
4|deadline| deadline block
### Example
```
kava tx swap deposit 10000000ukava 10000000usdx 0.01 1624224736 --from <key>
```
### Options
```
-a, --account-number uint The account number of the signing account (offline mode only)
-b, --broadcast-mode string Transaction broadcasting mode (sync|async|block) (default "sync")
--dry-run ignore the --gas flag and perform a simulation of a transaction, but don't broadcast it
--fees string Fees to pay along with transaction; eg: 10uatom
--from string Name or address of private key with which to sign
--gas string gas limit to set per-transaction; set to "auto" to calculate required gas automatically (default 200000) (default "200000")
--gas-adjustment float adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored (default 1)
--gas-prices string Gas prices to determine the transaction fee (e.g. 10uatom)
--generate-only Build an unsigned transaction and write it to STDOUT (when enabled, the local Keybase is not accessible and the node operates offline)
-h, --help help for deposit
--indent Add indent to JSON response
--keyring-backend string Select keyring's backend (os|file|test) (default "os")
--ledger Use a connected Ledger device
--memo string Memo to send along with transaction
--node string <host>:<port> to tendermint rpc interface for this chain (default "tcp://localhost:26657")
-s, --sequence uint The sequence number of the signing account (offline mode only)
--trust-node Trust connected full node (don't verify proofs for responses) (default true)
-y, --yes Skip tx broadcasting prompt confirmation
```
### Options inherited from parent commands
```
--chain-id string Chain ID of tendermint node
```

View File

@ -1,56 +0,0 @@
# Swap Tokens
Swap an exact amount of token a for token b
## Command
```
kava tx swap swap-exact-for-tokens <exactCoinA> <coinB> <slippage> <deadline> <flags>
```
Using ```kava``` call the ```tx``` subcommand followed by the module name which is```swap```, then define the action which is ```swap-exact-for-tokens``` and finally follow up with required arguments or flags.
### Arguments
position|name|expects
|--|--|--|
1|exactCoinA| exact amount & name (no spaces)
2|coinB| amount & name (no spaces)
3|slippage| percentage float
4|deadline| timestamp
### Example
```
kava tx swap swap-exact-for-tokens 1000000ukava 5000000usdx 0.01 1624224736 --from <key>
```
### Options
```
-a, --account-number uint The account number of the signing account (offline mode only)
-b, --broadcast-mode string Transaction broadcasting mode (sync|async|block) (default "sync")
--dry-run ignore the --gas flag and perform a simulation of a transaction, but don't broadcast it
--fees string Fees to pay along with transaction; eg: 10uatom
--from string Name or address of private key with which to sign
--gas string gas limit to set per-transaction; set to "auto" to calculate required gas automatically (default 200000) (default "200000")
--gas-adjustment float adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored (default 1)
--gas-prices string Gas prices to determine the transaction fee (e.g. 10uatom)
--generate-only Build an unsigned transaction and write it to STDOUT (when enabled, the local Keybase is not accessible and the node operates offline)
-h, --help help for swap-exact-for-tokens
--indent Add indent to JSON response
--keyring-backend string Select keyring's backend (os|file|test) (default "os")
--ledger Use a connected Ledger device
--memo string Memo to send along with transaction
--node string <host>:<port> to tendermint rpc interface for this chain (default "tcp://localhost:26657")
-s, --sequence uint The sequence number of the signing account (offline mode only)
--trust-node Trust connected full node (don't verify proofs for responses) (default true)
-y, --yes Skip tx broadcasting prompt confirmation
```
### Options inherited from parent commands
```
--chain-id string Chain ID of tendermint node
```

View File

@ -1,57 +0,0 @@
# Withdraw
Withdraw coins from a swap liquidity pool
## Command
```
kava tx swap withdraw <shares> <minCoinA> <minCoinB> <deadline> <flags>
```
Using ```kava``` call the ```tx``` subcommand followed by the module name which is```swap```, then define the action which is ```withdraw``` and finally follow up with required arguments or flags.
### Arguments
position|name|expects
|--|--|--|
1|shares| number of shares
2|minCoinA| amount & name (no spaces)
3|minCoinB| amount & name (no spaces)
4|deadline| timestamp
### Example
```
kava tx swap withdraw 153000 10000000ukava 20000000usdx 176293740 --from <key>
```
### Options
```
-a, --account-number uint The account number of the signing account (offline mode only)
-b, --broadcast-mode string Transaction broadcasting mode (sync|async|block) (default "sync")
--dry-run ignore the --gas flag and perform a simulation of a transaction, but don't broadcast it
--fees string Fees to pay along with transaction; eg: 10uatom
--from string Name or address of private key with which to sign
--gas string gas limit to set per-transaction; set to "auto" to calculate required gas automatically (default 200000) (default "200000")
--gas-adjustment float adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored (default 1)
--gas-prices string Gas prices to determine the transaction fee (e.g. 10uatom)
--generate-only Build an unsigned transaction and write it to STDOUT (when enabled, the local Keybase is not accessible and the node operates offline)
-h, --help help for withdraw
--indent Add indent to JSON response
--keyring-backend string Select keyring's backend (os|file|test) (default "os")
--ledger Use a connected Ledger device
--memo string Memo to send along with transaction
--node string <host>:<port> to tendermint rpc interface for this chain (default "tcp://localhost:26657")
-s, --sequence uint The sequence number of the signing account (offline mode only)
--trust-node Trust connected full node (don't verify proofs for responses) (default true)
-y, --yes Skip tx broadcasting prompt confirmation
```
### Options inherited from parent commands
```
--chain-id string Chain ID of tendermint node
```

View File

@ -1,76 +0,0 @@
<!--
order: 1
-->
# Quick Reference
### Get a list of all keys
```
kava keys list
```
### Query Account
```
kava q account <kava-addr>
```
### View Staking Delegations
```
kava q staking delegations <kava-addr>
```
### Claim staking rewards
```
kava tx distribution withdraw-all-rewards --gas 650000 --gas-prices 0.01ukava --from <kava-addr or key name>
```
### Querying outstanding staking rewards
```
kava q distribution rewards <kava-addr>
```
### Claim staking from individual validator
```
kava tx distribution withdraw-rewards <kava-validator-addre (starts with kavavaloper)> --gas 650000 --gas-prices 0.01ukava --from <kava-addr or key name>
```
### Claiming KAVA Delegator rewards (yielding HARD and SWP)
```
kava tx incentive claim-delegator --multiplier hard=large,swp=large --from <kava-addr or key name> --gas 800000 --gas-prices 0.01ukava
```
### Querying outstanding HARD rewards
```
kava q incentive rewards --type delegator --owner <kava-address>
```
### View HARD Incentives
```
kava q incentive rewards --type hard --owner <kava-address>
```
### Claim HARD Incentives
```
kava tx incentive claim-hard --multiplier hard=large --multiplier ukava=large --from <kava-addr or key name> --gas 800000 --gas-prices 0.01ukava
```
### Send Coins
```
kava tx bank send <from> <to> <amount (100ukava for example)> --memo [memo] --gas-prices 0.01ukava
```
### Query Transaction Status Using TX Hash
```
kava q tx <tx_hash>
```
### Query Transactions Using events
```
kava q txs --events message.actions=swap_deposit
```
### Adding a Key to Ledger
```
kava keys add <key-name> --account <account-index> --legacy-hd-path --ledger
```

View File

@ -1,201 +0,0 @@
Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
1. Definitions.
"License" shall mean the terms and conditions for use, reproduction,
and distribution as defined by Sections 1 through 9 of this document.
"Licensor" shall mean the copyright owner or entity authorized by
the copyright owner that is granting the License.
"Legal Entity" shall mean the union of the acting entity and all
other entities that control, are controlled by, or are under common
control with that entity. For the purposes of this definition,
"control" means (i) the power, direct or indirect, to cause the
direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity.
"You" (or "Your") shall mean an individual or Legal Entity
exercising permissions granted by this License.
"Source" form shall mean the preferred form for making modifications,
including but not limited to software source code, documentation
source, and configuration files.
"Object" form shall mean any form resulting from mechanical
transformation or translation of a Source form, including but
not limited to compiled object code, generated documentation,
and conversions to other media types.
"Work" shall mean the work of authorship, whether in Source or
Object form, made available under the License, as indicated by a
copyright notice that is included in or attached to the work
(an example is provided in the Appendix below).
"Derivative Works" shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including
the original version of the Work and any modifications or additions
to that Work or Derivative Works thereof, that is intentionally
submitted to Licensor for inclusion in the Work by the copyright owner
or by an individual or Legal Entity authorized to submit on behalf of
the copyright owner. For the purposes of this definition, "submitted"
means any form of electronic, verbal, or written communication sent
to the Licensor or its representatives, including but not limited to
communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the
Licensor for the purpose of discussing and improving the Work, but
excluding communication that is conspicuously marked or otherwise
designated in writing by the copyright owner as "Not a Contribution."
"Contributor" shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work.
2. Grant of Copyright License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works of,
publicly display, publicly perform, sublicense, and distribute the
Work and such Derivative Works in Source or Object form.
3. Grant of Patent License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except as stated in this section) patent license to make, have made,
use, offer to sell, sell, import, and otherwise transfer the Work,
where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their
Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted. If You
institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed.
4. Redistribution. You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You
meet the following conditions:
(a) You must give any other recipients of the Work or
Derivative Works a copy of this License; and
(b) You must cause any modified files to carry prominent notices
stating that You changed the files; and
(c) You must retain, in the Source form of any Derivative Works
that You distribute, all copyright, patent, trademark, and
attribution notices from the Source form of the Work,
excluding those notices that do not pertain to any part of
the Derivative Works; and
(d) If the Work includes a "NOTICE" text file as part of its
distribution, then any Derivative Works that You distribute must
include a readable copy of the attribution notices contained
within such NOTICE file, excluding those notices that do not
pertain to any part of the Derivative Works, in at least one
of the following places: within a NOTICE text file distributed
as part of the Derivative Works; within the Source form or
documentation, if provided along with the Derivative Works; or,
within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents
of the NOTICE file are for informational purposes only and
do not modify the License. You may add Your own attribution
notices within Derivative Works that You distribute, alongside
or as an addendum to the NOTICE text from the Work, provided
that such additional attribution notices cannot be construed
as modifying the License.
You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions
for use, reproduction, or distribution of Your modifications, or
for any such Derivative Works as a whole, provided Your use,
reproduction, and distribution of the Work otherwise complies with
the conditions stated in this License.
5. Submission of Contributions. Unless You explicitly state otherwise,
any Contribution intentionally submitted for inclusion in the Work
by You to the Licensor shall be under the terms and conditions of
this License, without any additional terms or conditions.
Notwithstanding the above, nothing herein shall supersede or modify
the terms of any separate license agreement you may have executed
with Licensor regarding such Contributions.
6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file.
7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.
8. Limitation of Liability. In no event and under no legal theory,
whether in tort (including negligence), contract, or otherwise,
unless required by applicable law (such as deliberate and grossly
negligent acts) or agreed to in writing, shall any Contributor be
liable to You for damages, including any direct, indirect, special,
incidental, or consequential damages of any character arising as a
result of this License or out of the use or inability to use the
Work (including but not limited to damages for loss of goodwill,
work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor
has been advised of the possibility of such damages.
9. Accepting Warranty or Additional Liability. While redistributing
the Work or Derivative Works thereof, You may choose to offer,
and charge a fee for, acceptance of support, warranty, indemnity,
or other liability obligations and/or rights consistent with this
License. However, in accepting such obligations, You may act only
on Your own behalf and on Your sole responsibility, not on behalf
of any other Contributor, and only if You agree to indemnify,
defend, and hold each Contributor harmless for any liability
incurred by, or claims asserted against, such Contributor by reason
of your accepting any such warranty or additional liability.
END OF TERMS AND CONDITIONS
APPENDIX: How to apply the Apache License to your work.
To apply the Apache License to your work, attach the following
boilerplate notice, with the fields enclosed by brackets "[]"
replaced with your own identifying information. (Don't include
the brackets!) The text should be enclosed in the appropriate
comment syntax for the file format. We also recommend that a
file or class name and description of purpose be included on the
same "printed page" as the copyright notice for easier
identification within third-party archives.
Copyright 2020 Kava Labs, Inc.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

View File

@ -1,33 +0,0 @@
# Become a Founding Member of Kava
> ### Validate & Earn Tokens
Every project begins with those brave few who have vision and grit. Fortune favors the bold, and the Kava community honors validators that participate in testnets and the mainnet launch with a badge commemorating their early validator services and entitling them to Kava tokens.
## Earn Your First Badge!
| | |
| ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <img src="./founder-badge.png" width="280"> | <h3>The “Founder” Badge</h3><p>Kava founders helped secure the network before it was the cool thing to do. Participate in the transition from Testnet #1 to Testnet #2 and stay live through Mainnet launch.</p><h4>Reward</h4><ul><li>3,000 KAVA</li></ul><h4>Qualification</h4><ul><li>Validate at least one (1) precommit of Testnet #1</li><li>Validate at least 90% of precommits for Testnet #2</li></ul> |
## Keep Going!
| | |
| ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <img src="./founder-plus.png" width="280"> | <h3>The “Founder PLUS” Badge</h3><p>Success doesnt follow from time and place alone, it requires persistence. Secure Kava as it goes live to the world and remain highly available as it upgrades in Mainnet environment.</p><h4>Reward</h4><ul><li>3,000 KAVA</li></ul><h4>Qualification</h4><ul><li>Validate at least 90% of precommits for the first six (6) consecutive thirty (30) day periods.</li><li>Obtain “Founder” badge</li></ul> |
### General Qualifications
- “Founder” badges restricted to first 100 Kava validators, measured by timestamp of first precommit.
- Only available to residents outside the following countries:
- Afghanistan, Balkans, Belarus, Burma (Myanmar), Burundi, Cambodia, the Cayman Islands, Central African Republic, the Peoples Republic of China, Cote D'Ivoire (Ivory Coast), Cuba, the Democratic Republic of Congo, Egypt, Guinea, Guinea-Bissau, Haiti, Iran, Iraq, Lebanon, Liberia, Libya, Maldives, Mali, Nicaragua, North Korea, Serbia, Somalia, Sudan and Darfur, South Sudan, Syria, Thailand, Tunisia, Turkey, the Crimea region of Ukraine, Ukraine/Russia, United States, Venezuela, Yemen, Zimbabwe
- Kava badge rewards are not available to entities that participated in the Kava fundraiser.
- Subject to registration and completion of KYC requirements. We will update participants on KYC proceedures at the end of testnet #1.
### Get Started
Follow the documentation [here](https://github.com/Kava-Labs/kava-devnet) to begin validating!
### Join the conversation
Join our community channels on [Riot](https://riot.im/app/#/room/#kava-validators:matrix.org) and [Telegram](https://t.me/kavalabs) to stay up to date and get your questions answered! _And make sure to watch out for future badge announcements!_

View File

@ -1,54 +0,0 @@
<!---
parent:
order: false
--->
# Community Tools
The Kava community has developed some amazing tools and services. If you've built something great on, for, or in support of the Kava ecosystem let us know and we'll add it to this list.
## User Interfaces
- [Kava Web App](https://app.kava.io/)
- Cosmostation Mobile App: [App Store](https://apps.apple.com/us/app/cosmostation/id1459830339), [Play Store](https://play.google.com/store/apps/details?id=wannabit.io.cosmostaion&hl=en)
- Frontier Mobile App: [App Store](https://apps.apple.com/us/app/frontier-defi-wallet/id1482380988), [Play Store](https://play.google.com/store/apps/details?id=com.frontierwallet&hl=en)
## Explorers
- [Mintscan](https://kava.mintscan.io/) by Cosmostation
- [Big Dipper](https://kava.bigdipper.live/) by Forbole
- [PING.pub](https://kava.ping.pub/#/parameter)
- [KAVAScan](https://kavascan.com)
## For Validators
- [QuickSync](https://kava.quicksync.io/) chain snapshots
## Staking
- [Staking rewards calculator](https://www.stakingrewards.com/earn/kava/calculate)
### Staking Providers
Listed in alphabetical order.
- [ATEAM](https://nodeateam.com/)
- [B-Harvest](https://bharvest.io/)
- [BNB48 Club](https://www.bnb48.club/)
- [Binance Staking](https://www.binance.com/en/earn)
- [ChainLayer](https://www.chainlayer.io/)
- [Chorus One](https://chorus.one/)
- [Cosmostation](https://www.cosmostation.io/)
- [Figment](https://figment.io/protocols/kava/)
- [Forbole](https://www.forbole.com/)
- [Huboi Pool](https://www.huobipool.com/)
- [Lemniscap](https://lemniscap.com/)
- [Kraken](https://www.kraken.com/)
- [OKEx Pool](https://www.okex.com/pool)
- [P2P](https://p2p.org/)
- [pylonvalidator](https://pylonvalidator.com/)
- [sikka](https://sikka.tech/)
- [SNZ Pool](https://snzholding.com/pool.html)
- [StakeWith.Us](https://www.stakewith.us/)
- [Staked](https://staked.us/)
- [stake.fish](https://stake.fish/en/)

File diff suppressed because it is too large Load Diff

Binary file not shown.

Before

Width:  |  Height:  |  Size: 75 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 84 KiB

View File

@ -1,36 +0,0 @@
# kava-8 Oracle Update Guide
The Kava blockchain is upgrading and minor updates are needed for oracles
## Update Guide For Standalone Oracle Operators
1. Install the latest version of kava-tools
2. In your `.env` configuration file, add an entry for `FEE`. This will set the default fee (in ukava) for each oracle transaction (can be 0).
- `FEE=”10000”`
3. In your `.env` configuration file, update the MARKET_IDS entry to include the latest markets for kava-5:
- `MARKET_IDS="bnb:usd,bnb:usd:30,btc:usd,btc:usd:30,xrp:usd,xrp:usd:30,busd:usd,busd:usd:30,kava:usd,kava:usd:30,hard:usd,hard:usd:30,usdx:usd,usdx:usd:30"`
4. Restart your oracle process
## Update Guide For Chainlink Oracle Operators
1. Pull the latest version of Kavas external-adapters-js repo
2. Install `yarn`
3. Build the latest version of the kava adapter
- from top level external-adapter-js directory
- make docker adapter=kava
4. Edit your configuration file and add an entry for `FEE`. This will set the default fee (in ukava) for each oracle transaction (can be 0).
- `FEE=”10000”`
5. Restart the kava adapter with the latest version
6. If necessary, create jobs for the following market_ids, if they do not already exist
- bnb:usd
- bnb:usd:30
- btc:usd
- btc:usd:30
- xrp:usd
- xrp:usd:30
- busd:usd
- busd:usd:30
- kava:usd
- kava:usd:30
- hard:usd
- hard:usd:30
- usdx:usd
- usdx:usd:30

View File

@ -1,70 +0,0 @@
# kava-8 Validator Update Guide
The kava-8 update includes new features. This document contains important information about the new functionality and breaking changes.
kava-8 will use the same major version of the cosmos-sdk (v0.39.x). kava-8 will have the same golang compatibility as kava-7, requiring v1.13+. Golang v1.15 has been tested and is suitable for use on kava-8 mainnet.
## Migration Procedure
The specific steps to migrate your node can be found [here](https://github.com/Kava-Labs/kava/blob/master/migrate/v0_15/migrate.md).
## Breaking Changes
#### Claiming Rewards
Reward claims in the `x/incentive` module have been updated to enable selective reward claiming by type and token denom. There are four primary reward claim message types:
- **MsgClaimUSDXMintingReward** has arguments Sender (sdk.AccAddress) and MultiplierName (string). This message will claim all USDX minting rewards for the user, applying the specified reward multiplier.
- **MsgClaimHardReward** takes three arguments: Sender (sdk.AccAddress), Multiplier Name (string), and Denoms To Claim ([]string). This message will claim any available HARD supply/borrow rewards of the specified denoms for the user, applying the specified reward multiplier.
- **MsgClaimDelegatorReward** takes three arguments: Sender (sdk.AccAddress), Multiplier Name (string), and Denoms To Claim ([]string). This message will claim any available delegation rewards of the specified denoms for the user, applying the specified reward multiplier.
- **MsgClaimSwapReward** takes three arguments: Sender (sdk.AccAddress), Multiplier Name (string), and Denoms To Claim ([]string). This message will claim any available SWAP protocol rewards of the specified denoms for the user, applying the specified reward multiplier.
#### Committee Voting
Voting in the `x/committee` module has been updated to support Yes, No, and Abstain votes.
- **MsgVote** takes three arguments: Proposal ID (uint64), Voter (sdk.AccAddress), and Vote Type (VoteType). Valid Vote Types are “yes”, “y,” “no”, “n”, “abstain”, and “a”.
## New Features
#### SWAP Protocol
Kava-8 introduces SWAP protocol, a decentralized exchange that enables users to swap tokens against liquidity pools. SWAP protocol has several new messages:
- **MsgDeposit** enables liquidity providers to deposit tokens into a liquidity pool. It takes five arguments - the depositor (sdk.AccAddress) that is providing liquidity, token A (sdk.Coin) that is being deposited, token B (sdk.Coin) that is being deposited, minimum acceptable slippage (sdk.Dec), and deadline (int64). After a successful deposit the liquidity provider will be credited deposit shares in the pool.
- **MsgWithdraw** enables liquidity providers to withdraw deposited tokens from a liquidity pool. It takes five arguments - the withdrawers address (sdk.AccAddress), the amount of shares (sdk.Int) to be withdrawn, the minimum accepted token A amount (sdk.Coin) to be received by the withdrawer, the minimum accepted token B amount (sdk.Coin) to be received, and the deadline (int64). After a successful withdrawal the liquidity provider will receive tokens.
- **MsgSwapExactForTokens** supports token swaps with an exact amount of input tokens. It takes five arguments - the requesters address (sdk.AccAddress), the exact input amount of token A (sdk.Coin), the desired output amount of token B (sdk.Coin), the minimum accepted slippage (sdk.Dec) i.e. percentage difference from the output amount, and the deadline (int64).
- **MsgSwapForExactTokens** supports token swaps for an exact amount of output tokens. It takes five arguments - the requesters address (sdk.AccAddress), the desired input amount of token A (sdk.Coin), the exact output amount of token B (sdk.Coin), the minimum accepted slippage (sdk.Dec) i.e. percentage difference from the input amount, and the deadline (int64).
#### Committee
kava-8 introduces HARD and SWAP protocol governance by token holders via two new committees. Both committees have a proposal voting duration of seven days, a minimum quorum of 33%, and enact proposals that receive over 50% Yes votes.
The **HARD Governance Committee** will have permissions to change the following parameters:
- Hard module permissions
- *Money markets*: whitelist of supported money markets.
- *Minimum borrow USD value*: minimum valid borrow amount in USD from a money market.
- Incentive module permissions
- *Hard supply reward periods*: HARD token rewards for HARD protocol suppliers.
- *Hard borrow reward periods*: HARD token rewards for HARD protocol borrowers.
- *Delegator reward periods*: HARD token rewards for KAVA delegators
The **SWP Governance Committee** will have permissions to change the following parameters:
- Swap module permissions
- *Allowed pools*: whitelist of supported token pairs.
- *Swap fee*: global trading fee paid by users to liquidity providers.
- Incentive module permissions
- *Swap reward periods*: SWP token rewards for SWAP protocol liquidity providers.
- *Delegator reward periods*: SWP token rewards for KAVA delegators.
## Kava REST API
Kavas REST API supports all Kava-8 changes and features. To minimize compatibility issues, commonly used endpoints are still supported and have not been deprecated. API documentation can be found here.
Testing
Kava-testnet-13000 is a publicly available testnet (http://app.swap-testnet.kava.io/) to test validation and external integrations. Publicly available REST and RPC endpoints are:
#### Pruning nodes:
- Rest: https://api.testnet.kava.io/node_info
- RPC: https://rpc.testnet.kava.io
#### Archive nodes:
- Rest: https://api.data-testnet.kava.io/node_info
- RPC: https://rpc.data-testnet.kava.io
## Questions/Feedback
Please reach out in your preferred communication channel (Discord, Slack, email) with any questions, or ask in [The Kava Platform Telegram](https://t.me/kavalabs).

View File

@ -1,51 +0,0 @@
# kava-8 Wallet Update Guide
The kava-8 update includes new features. This document contains important information about the new functionality and breaking changes.
kava-8 will use the same major version of the cosmos-sdk (v0.39.x). kava-8 will have the same golang compatibility as kava-7, requiring v1.13+. Golang v1.15 has been tested and is suitable for use on kava-8 mainnet.
## Breaking Changes
#### Claiming Rewards
Reward claims in the `x/incentive` module have been updated to enable selective reward claiming by type and token denom. There are four primary reward claim message types:
- **MsgClaimUSDXMintingReward** has arguments Sender (sdk.AccAddress) and MultiplierName (string). This message will claim all USDX minting rewards for the user, applying the specified reward multiplier.
- **MsgClaimHardReward** takes three arguments: Sender (sdk.AccAddress), Multiplier Name (string), and Denoms To Claim ([]string). This message will claim any available HARD supply/borrow rewards of the specified denoms for the user, applying the specified reward multiplier.
- **MsgClaimDelegatorReward** takes three arguments: Sender (sdk.AccAddress), Multiplier Name (string), and Denoms To Claim ([]string). This message will claim any available delegation rewards of the specified denoms for the user, applying the specified reward multiplier.
- **MsgClaimSwapReward takes** three arguments: Sender (sdk.AccAddress), Multiplier Name (string), and Denoms To Claim ([]string). This message will claim any available SWAP protocol rewards of the specified denoms for the user, applying the specified reward multiplier.
#### Committee Voting
Voting in the `x/committee` module has been updated to support Yes, No, and Abstain votes.
- **MsgVote takes three arguments: Proposal ID (uint64), Voter (sdk.AccAddress), and Vote Type (VoteType). Valid Vote Types are “yes”, “y,” “no”, “n”, “abstain”, and “a”.
## New Features
#### SWAP Protocol
Kava-8 introduces SWAP protocol, a decentralized exchange that enables users to swap tokens against liquidity pools. SWAP protocol has several new messages:
- **MsgDeposit** enables liquidity providers to deposit tokens into a liquidity pool. It takes five arguments - the depositor (sdk.AccAddress) that is providing liquidity, token A (sdk.Coin) that is being deposited, token B (sdk.Coin) that is being deposited, minimum acceptable slippage (sdk.Dec), and deadline (int64). After a successful deposit the liquidity provider will be credited deposit shares in the pool.
- **MsgWithdraw** enables liquidity providers to withdraw deposited tokens from a liquidity pool. It takes five arguments - the withdrawers address (sdk.AccAddress), the amount of shares (sdk.Int) to be withdrawn, the minimum accepted token A amount (sdk.Coin) to be received by the withdrawer, the minimum accepted token B amount (sdk.Coin) to be received, and the deadline (int64). After a successful withdrawal the liquidity provider will receive tokens.
- **MsgSwapExactForTokens** supports token swaps with an exact amount of input tokens. It takes five arguments - the requesters address (sdk.AccAddress), the exact input amount of token A (sdk.Coin), the desired output amount of token B (sdk.Coin), the minimum accepted slippage (sdk.Dec) i.e. percentage difference from the output amount, and the deadline (int64).
- **MsgSwapForExactTokens** supports token swaps for an exact amount of output tokens. It takes five arguments - the requesters address (sdk.AccAddress), the desired input amount of token A (sdk.Coin), the exact output amount of token B (sdk.Coin), the minimum accepted slippage (sdk.Dec) i.e. percentage difference from the input amount, and the deadline (int64).
#### Committee
kava-8 introduces HARD and SWAP protocol governance by token holders via two new committees. Both committees have a proposal voting duration of seven days, a minimum quorum of 33%, and enact proposals that receive over 50% Yes votes.
The **HARD Governance Committee** will have permissions to change the following parameters:
- Hard module permissions
- *Money markets*: whitelist of supported money markets.
- *Minimum borrow USD value*: minimum valid borrow amount in USD from a money market.
- Incentive module permissions
- *Hard supply reward periods*: HARD token rewards for HARD protocol suppliers.
- *Hard borrow reward periods*: HARD token rewards for HARD protocol borrowers.
- *Delegator reward periods*: HARD token rewards for KAVA delegators
The **SWP Governance Committee** will have permissions to change the following parameters:
- Swap module permissions
- *Allowed pools*: whitelist of supported token pairs.
- *Swap fee*: global trading fee paid by users to liquidity providers.
- Incentive module permissions
- *Swap reward periods*: SWP token rewards for SWAP protocol liquidity providers.
- *Delegator reward periods*: SWP token rewards for KAVA delegators.
Kava REST API
Kavas REST API supports all Kava-8 changes and features. To minimize compatibility issues, commonly used endpoints are still supported and have not been deprecated. API documentation can be found [here](https://swagger.kava.io/).

View File

@ -1,95 +0,0 @@
# Kava-9 Validator Guide
## Software Version and Key Dates
- We will be upgrading from chain-id "kava-8" to chain-id "kava-9".
- The version of Kava for kava-9 is v0.16.1
- The kava-8 chain will be shutdown with a `SoftwareUpgradeProposal` that activates at block height __1803250__, which is approximately 14:00 UTC on January, 19 2022.
- kava-9 genesis time is set to January 19, 2022 at 16:00 UTC
- The version of cosmos-sdk for kava-9 is v0.44.5
- The version of tendermint for kava-9 v0.34.14
- The minimum version of golang for kava-9 is __1.17+__.
__NOTE__: As part of the upgrade to kava-9, the `kvd` and `kvcli` binaries were combined into a single blockchain binary named `kava`. When restarting the chain, be sure to use `kava start` and not the deprecated `kvd start`.
### Risks
As a validator, performing the upgrade procedure on your consensus nodes carries a heightened risk of double-signing and being slashed. The most important piece of this procedure is verifying your software version and genesis file hash before starting your validator and signing.
The riskiest thing a validator can do is discover that they made a mistake and repeat the upgrade procedure again during the network startup. If you discover a mistake in the process, the best thing to do is wait for the network to start before correcting it. If the network is halted and you have started with a different genesis file than the expected one, seek advice from a Kava developer before resetting your validator.
### Recovery
Prior to exporting kava-8 state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snap-shotting depends heavily on infrastructure, but generally this can be done by backing up the .kvd and .kvcli directories.
It is critically important to back-up the .kvd/data/priv_validator_state.json file after stopping your kvd process. This file is updated every block as your validator participates in consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must downgrade back to v0.15.2 of the Kava software and restore to their latest snapshot before restarting their nodes.
## Upgrade Procedure
### Before the upgrade
Kava Labs has submitted a `SoftwareUpgradeProposal` that specifies block height __1803250__ as the final block height for kava-8. This height corresponds to approximately 14:00 UTC on January 19th. Once the proposal passes, the chain will shutdown automatically at the specified height and does not require manual intervention by validators.
### On the day of the upgrade
**The kava chain is expected to halt at block height __1803250__, at approximately 14:00 UTC, and restart with new software at 16:00 UTC January 19th. Do not stop your node and begin the upgrade before 14:00UTC on January 19th, or you may go offline and be unable to recover until after the upgrade!**
**Make sure the kvd process is stopped before proceeding and that you have backed up your validator**. Failure to backup your validator could make it impossible to restart your node if the upgrade fails.
1. Export State (this **MUST** be done using **v0.15.x**)
```sh
# verify version before export:
kvd version --long
# name: kava
# server_name: kvd
# client_name: kvcli
# version: 0.15.0 (any 0.15 version is fine)
# commit: 8691ac44ed0e65db7ebc4a2fe85c58c717f63c39
# build_tags: netgo,ledger
# go: go version go1.17.1 linux/amd64
# export genesis using v0.15.x
kvd export --for-zero-height --height 1803249 > export-genesis.json
```
**Note:** This can take a while!
2. Update to kava-9
```sh
# in the `kava` folder
git pull
git checkout v0.16.1
make install
# verify versions
kava version --long
# name: kava
# server_name: kava
# version: v0.16.1
# commit: [PLACEHOLDER]
# build_tags: netgo,ledger
# go: go version go1.17.1 linux/amd64
# Migrate genesis state
kava migrate export-genesis.json > genesis.json
# Verify output of genesis migration
kava validate-genesis genesis.json # should say it's valid
kava assert-invariants genesis.json # should say invariants pass
jq -S -c -M '' genesis.json | shasum -a 256
# [PLACEHOLDER]
# Restart node with migrated genesis state
cp genesis.json ~/.kava/config/genesis.json
kava unsafe-reset-all
# Restart node -
# ! Be sure to remove --halt-time flag if it is set in systemd/docker
# NOTE: THE BINARY IS NOW NAMED KAVA
kava start
```

View File

@ -1,90 +0,0 @@
# Kava-9 Upgrade Guide for Wallets, Explorers, and Exchanges
The Kava-9 Upgrade migrates the Kava blockchain from v0.39.x of the cosmos-sdk to v0.44.x of the cosmos-sdk. A full description of the v0.39 -> v0.40-42 REST changes can be found at:
https://github.com/cosmos/cosmos-sdk/blob/v0.42.11/docs/migrations/rest.md
**Note**: Kava engineers have implemented a custom POST /txs endpoint to preserve backwards compatibility (v0.42 -> v0.44 REST changes) for legacy encoded transaction:
https://docs.cosmos.network/master/migrations/rest.html
**Note**: Cosmos, Terra, and Osmosis blockchains have also been upgraded to v0.44 of the cosmos-sdk. Changes needed to support those chains will apply to Kava as well.
For wallets, explorers, and exchanges, there are a few particular changes to be aware of:
### Account data
Account data has been separated from balances data. In v0.15 of kava (kava-8), querying an account would return the following JSON, which contains both the account data and balance data:
```sh
curl /auth/accounts/kava173w2zz287s36ewnnkf4mjansnthnnsz7rtrxqc`
```
```json
{"height":"38","result":{"type":"cosmos-sdk/Account","value":{"address":"kava173w2zz287s36ewnnkf4mjansnthnnsz7rtrxqc","coins":[{"denom":"ukava","amount":"1000000000000"}],"public_key":null,"account_number":"16","sequence":"0"}}}`
```
In v0.16 (kava-9):
```sh
curl /auth/accounts/kava173w2zz287s36ewnnkf4mjansnthnnsz7rtrxqc`
```
```json
{"height":"6","result":{"type":"cosmos-sdk/BaseAccount","value":{"address":"kava173w2zz287s36ewnnkf4mjansnthnnsz7rtrxqc","account_number":"15"}}}`
```
Note: The `sequence` field is now omitted from the response if an account has not signed a transaction.
To get the balance data, the /bank/balances endpoint must be used in addition to /auth/accounts:
```sh
curl /bank/balances/kava173w2zz287s36ewnnkf4mjansnthnnsz7rtrxqc`
```
```json
{"height":"198","result":[{"denom":"ukava","amount":"10000000000000000"}]}`
```
### Vesting Account Data
The address, account sequence and account number fields for periodic vesting accounts have moved:
In v0.15 (kava-8):
```sh
curl /auth/accounts/kava1z3ytjpr6ancl8gw80z6f47z9smug7986x29vtj
```
```json
{"height":"3","result":{"type":"cosmos-sdk/PeriodicVestingAccount","value":{"address":"kava1z3ytjpr6ancl8gw80z6f47z9smug7986x29vtj","coins":[{"denom":"ukava","amount":"565077579"},{"denom":"usdx","amount":"1363200"}],"public_key":null,"account_number":"6","sequence":"0","original_vesting":[{"denom":"ukava","amount":"560159828"}],"delegated_free":[],"delegated_vesting":[],"end_time":"1628213878","start_time":"1596677878","vesting_periods":[{"length":"31536000","amount":[{"denom":"ukava","amount":"560159828"}]}]}}}
```
**Note**: address, account sequence and account number can be found at
- `.result.value.address`
- `.result.value.sequence`
- `.result.value.account_number`
In v0.16 (kava-9):
```sh
curl /auth/accounts/kava1z3ytjpr6ancl8gw80z6f47z9smug7986x29vtj`
```
```json
{"height":"4059","result":{"type":"cosmos-sdk/PeriodicVestingAccount","value":{"base_vesting_account":{"base_account":{"address":"kava1fwfwmt6vupf3m9uvpdsuuc4dga8p5dtl4npcqz","public_key":{"type":"tendermint/PubKeySecp256k1","value":"A3CJ0ejMGhGhxC9dRqKooEkiOj++kMh+lFDbdN283QHE"},"account_number":"18","sequence":"2"},"original_vesting":[{"denom":"ukava","amount":"560159828"}],"delegated_free":[],"delegated_vesting":[],"end_time":"1664632800"},"start_time":"1633096800","vesting_periods":[{"length":"31536000","amount":[{"denom":"ukava","amount":"560159828"}]}]}}}`
```
**Note**: address, account sequence and account number can be found at
- `.result.value.base_vesting_account.base_account.address`
- `.result.value.base_vesting_account.base_account.sequence`
- `.result.value.base_vesting_account.base_account.account_number`
### Legacy encoded transactions (POST /txs)
The Cosmos team found vulnerabilities in legacy transaction support and removed the [POST] /txs endpoints from v0.44.0 of the cosmos-sdk. To avoid this backwards incompatibility, kava-9 introduces a custom [POST] /txs endpoint that converts legacy (amino) transactions to the new proto encoding and broadcasts the converted tx. Implementation details can be found [here](https://github.com/Kava-Labs/kava/pull/1070).
### Javascript-SDK
The Kava Javascript-SDK has been updated to support kava-9, including the new [POST] /txs endpoint. This means that applications utilizing the Javascript-SDK can simply update:
`npm i @kava-labs/javascript-sdk@latest`

View File

@ -1,151 +0,0 @@
# Node Guide
This is an updated guide on setting up a mainnet full or light node. If you have questions, please join the active conversation in the #validators thread of our [__Discord Channel__](https://discord.com/invite/kQzh3Uv).
## Installing Kava
### Prerequisites
You should select an all-purpose server with at least 8GB of RAM, good connectivity, and a solid state drive with sufficient disk space. Storage requirements are discussed further in the section below. In addition, youll need to open **port 26656** to connect to the Kava peer-to-peer network. As the usage of the blockchain grows, the server requirements may increase as well, so you should have a plan for updating your server as well.
### Storage
The monthly storage requirements for a node are as follows. These are estimated values based on experience, but should serve as a good guide.
- A light node (`pruning = "everything"`) grows at a rate of ~5 GB per month.
- A full node (`pruning = "nothing"`) grows at a rate of ~100 GB per month
## Install Go
Kava is built using Go and requires Go version 1.13+. In this example, you will be installing Go on a fresh install of ubuntu 18.04.
```bash
# Update ubuntu
sudo apt update
sudo apt upgrade -y
# Install packages necessary to run go and jq for pretty formatting command line outputs
sudo apt install build-essential jq -y
# Install go
wget https://dl.google.com/go/go1.17.1.linux-amd64.tar.gz (or latest version at https://golang.org/dl/)
sudo tar -xvf go1.17.1.linux-amd64.tar.gz
sudo mv go /usr/local
# Updates environmental variables to include go
cat <<EOF>> ~/.profile
export GOROOT=/usr/local/go
export GOPATH=$HOME/go
export GO111MODULE=on
export PATH=$PATH:/usr/local/go/bin:$HOME/go/bin
EOF
source ~/.profile
```
To verify that Go is installed:
```bash
go version
# Should return go version go1.17.1 linux/amd64
```
## Install Kava
Install Kava using `git clone`. Note that version 0.15.1 is the correct version for mainnet.
```bash
git clone https://github.com/kava-labs/kava
cd kava
git checkout v0.15.1
make install
```
To verify that kava is installed:
```bash
kvd version --long
# name: kava
# server_name: kvd
# client_name: kvcli
# version: 0.15.1
# commit: f0c90f0cbf96d230a83cd2309b8fd032e52d7fb933881541472df1bf2703a939
# build_tags: netgo,ledger
# go: go version go1.15.14 linux/amd64
```
## Configuring Your Node
Next, download the correct genesis file and sync your node with the Kava mainnet. To download the genesis file:
```bash
# First, initialize kvd. Replace <name> with the public name of your node
kvd init --chain-id kava-8 <name>
# Download the genesis file
wget https://kava-genesis-files.s3.amazonaws.com/kava-8-genesis-migrated-from-block-1878508.json -O ~/.kvd/config/genesis.json
# Verify genesis hash
jq -S -c -M '' $HOME/.kvd/config/genesis.json | shasum -a 256
# f0c90f0cbf96d230a83cd2309b8fd032e52d7fb933881541472df1bf2703a939
```
Next, adjust some configurations. To open the config file:
```bash
vim $HOME/.kvd/config/config.toml
```
At line 160, add [seeds](https://docs.google.com/spreadsheets/d/1TWsD2lMi1idkPI6W9xFCn5W64x75yn9PDjvQaJVkIRk/edit?usp=sharing). These are used to connect to the peer-to-peer network:
At line 163, add some [persistent peers](https://docs.google.com/spreadsheets/d/1TWsD2lMi1idkPI6W9xFCn5W64x75yn9PDjvQaJVkIRk/edit?usp=sharing), which help maintain a connection to the peer-to-peer network
Next, chose how much historical state you want to store. To open the application config file:
```bash
vim $HOME/.kvd/config/app.toml
```
In this file, choose between `default`, `nothing`, and `everything`. To reduce hard drive storage, choose `everything` or `default`. To run an archival node, chose `nothing`.
```bash
pruning = "default"
```
In the same file, you will want to set minimum gas prices — setting a minimum prevents spam transactions:
```bash
minimum-gas-prices = "0.001ukava"
```
### Syncing Your Node
To sync your node, you will use systemd, which manages the Kava daemon and automatically restarts it in case of failure. To use systemd, you will create a service file. Be sure to replace `<your_user>` with the user on your server:
```bash
sudo tee /etc/systemd/system/kvd.service > /dev/null <<'EOF'
[Unit]
Description=Kava daemon
After=network-online.target
[Service]
User=<your_user>
ExecStart=/home/<your_user>/go/bin/kvd start
Restart=on-failure
RestartSec=3
LimitNOFILE=4096
[Install]
WantedBy=multi-user.target
EOF
```
To start syncing:
```bash
# Start the node
sudo systemctl enable kvd
sudo systemctl start kvd
```
To check on the status of syncing:
```bash
kvcli status --output json | jq '.sync_info'
```
This will give output like:
```bash
{
"latest_block_hash": "21D7E37A0A5992E1992DD43E42C05E4475A6E212694F746ABEE132267067847D",
"latest_app_hash": "FBE0E799BCCA57F12F781252787BD6340782E5D45E591294D01269F481B128AC",
"latest_block_height": "183566",
"latest_block_time": "2021-03-22T17:21:41.848445277Z",
"earliest_block_hash": "09E688467E5016159D74CEDE2EE870D671CAA772F76E6697AEEB685A398ACB08",
"earliest_app_hash": "",
"earliest_block_height": "1",
"earliest_block_time": "2021-03-05T06:00:00Z",
"catching_up": false
}
```
The main thing to watch is that the block height is increasing. Once you are caught up with the chain, `catching_up` will become false. At that point, you can start using your node to create a validator. If you need to sync using a snapshot, please use https://kava.quicksync.io/
To check the logs of the node:
```bash
sudo journalctl -u kvd -f
```
If you have questions, please join the active conversation in the #validators thread of the [__Kava Discord Channel__](https://discord.com/invite/kQzh3Uv).

10545
docs/package-lock.json generated

File diff suppressed because it is too large Load Diff

View File

@ -1,23 +0,0 @@
{
"name": "docs",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"preserve": "./pre.sh",
"serve": "trap 'exit 0' SIGINT; vuepress dev --no-cache",
"postserve": "./post.sh",
"prebuild": "./pre.sh",
"build": "trap 'exit 0' SIGINT; vuepress build --no-cache",
"postbuild": "./post.sh"
},
"keywords": [],
"author": "",
"license": "ISC",
"dependencies": {
"vuepress-theme-cosmos": "^1.0.168"
},
"devDependencies": {
"watchpack": "^1.6.1"
}
}

View File

@ -1,10 +0,0 @@
#!/usr/bin/env bash
# Modules
rm -rf Modules
# JavaScript SDK docs
rm -rf building
# Kava Tools docs
rm -rf tools

View File

@ -1,49 +0,0 @@
#!/usr/bin/env bash
# Clone each module's markdown files
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/* "$_"
fi
done
baseGitUrl="https://raw.githubusercontent.com/Kava-Labs"
# Client docs (JavaScript SDK)
clientGitRepo="javascript-sdk"
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"
toolDocs=("auction" "oracle")
mkdir -p "./${toolsDir}"
for T in ${toolDocs[@]}; do
curl "${baseGitUrl}/${toolsGitRepo}/master/${T}/README.md" -o "./${toolsDir}/${T}.md"
done
# Add Go tools
goToolsGitRepo="go-tools"
goToolsDocs=("sentinel")
for T in ${goToolsDocs[@]}; do
curl "${baseGitUrl}/${goToolsGitRepo}/master/${T}/README.md" -o "./${toolsDir}/${T}.md"
done
# Copy the community tools
cp communitytools.md "./${toolsDir}/community.md"
echo "---
parent:
order: false
---" > "./${toolsDir}/readme.md"

View File

@ -1,105 +0,0 @@
<!-- This file is auto-generated. Please do not modify it yourself. -->
# Protobuf Documentation
<a name="top"></a>
## Table of Contents
{{range .Files}}
{{$file_name := .Name}}- [{{.Name}}](#{{.Name}})
{{- if .Messages }}
{{range .Messages}} - [{{.LongName}}](#{{.FullName}})
{{end}}
{{- end -}}
{{- if .Enums }}
{{range .Enums}} - [{{.LongName}}](#{{.FullName}})
{{end}}
{{- end -}}
{{- if .Extensions }}
{{range .Extensions}} - [File-level Extensions](#{{$file_name}}-extensions)
{{end}}
{{- end -}}
{{- if .Services }}
{{range .Services}} - [{{.Name}}](#{{.FullName}})
{{end}}
{{- end -}}
{{end}}
- [Scalar Value Types](#scalar-value-types)
{{range .Files}}
{{$file_name := .Name}}
<a name="{{.Name}}"></a>
<p align="right"><a href="#top">Top</a></p>
## {{.Name}}
{{.Description}}
{{range .Messages}}
<a name="{{.FullName}}"></a>
### {{.LongName}}
{{.Description}}
{{if .HasFields}}
| Field | Type | Label | Description |
| ----- | ---- | ----- | ----------- |
{{range .Fields -}}
| `{{.Name}}` | [{{.LongType}}](#{{.FullType}}) | {{.Label}} | {{if (index .Options "deprecated"|default false)}}**Deprecated.** {{end}}{{nobr .Description}}{{if .DefaultValue}} Default: {{.DefaultValue}}{{end}} |
{{end}}
{{end}}
{{if .HasExtensions}}
| Extension | Type | Base | Number | Description |
| --------- | ---- | ---- | ------ | ----------- |
{{range .Extensions -}}
| `{{.Name}}` | {{.LongType}} | {{.ContainingLongType}} | {{.Number}} | {{nobr .Description}}{{if .DefaultValue}} Default: {{.DefaultValue}}{{end}} |
{{end}}
{{end}}
{{end}} <!-- end messages -->
{{range .Enums}}
<a name="{{.FullName}}"></a>
### {{.LongName}}
{{.Description}}
| Name | Number | Description |
| ---- | ------ | ----------- |
{{range .Values -}}
| {{.Name}} | {{.Number}} | {{nobr .Description}} |
{{end}}
{{end}} <!-- end enums -->
{{if .HasExtensions}}
<a name="{{$file_name}}-extensions"></a>
### File-level Extensions
| Extension | Type | Base | Number | Description |
| --------- | ---- | ---- | ------ | ----------- |
{{range .Extensions -}}
| `{{.Name}}` | {{.LongType}} | {{.ContainingLongType}} | {{.Number}} | {{nobr .Description}}{{if .DefaultValue}} Default: `{{.DefaultValue}}`{{end}} |
{{end}}
{{end}} <!-- end HasExtensions -->
{{range .Services}}
<a name="{{.FullName}}"></a>
### {{.Name}}
{{.Description}}
| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint |
| ----------- | ------------ | ------------- | ------------| ------- | -------- |
{{range .Methods -}}
| `{{.Name}}` | [{{.RequestLongType}}](#{{.RequestFullType}}){{if .RequestStreaming}} stream{{end}} | [{{.ResponseLongType}}](#{{.ResponseFullType}}){{if .ResponseStreaming}} stream{{end}} | {{nobr .Description}} | {{with (index .Options "google.api.http")}}{{range .Rules}}{{.Method}}|{{.Pattern}}{{end}}{{end}}|
{{end}}
{{end}} <!-- end services -->
{{end}}
## Scalar Value Types
| .proto Type | Notes | C++ | Java | Python | Go | C# | PHP | Ruby |
| ----------- | ----- | --- | ---- | ------ | -- | -- | --- | ---- |
{{range .Scalars -}}
| <a name="{{.ProtoType}}" /> {{.ProtoType}} | {{.Notes}} | {{.CppType}} | {{.JavaType}} | {{.PythonType}} | {{.GoType}} | {{.CSharp}} | {{.PhpType}} | {{.RubyType}} |
{{end}}

View File

@ -1,57 +0,0 @@
---
title: Kava Documentation
description: The documentation of Kava.
footer:
newsletter: false
aside: true
---
# Kava
## DeFi for Crypto.
Reference implementation of Kava, a blockchain for cross-chain DeFi. Built using the [cosmos-sdk](https://github.com/cosmos/cosmos-sdk).
## Mainnet
The current recommended version of the software for mainnet is [v0.15.1](https://github.com/Kava-Labs/kava/releases/tag/v0.15.1). The master branch of this repository often contains considerable development work since the last mainnet release and is __not__ runnable on mainnet.
### Installation
```bash
git checkout v0.15.1
make install
```
### Upgrade
The scheduled mainnet upgrade to `kava-9` took place on January 19th, 2022 at 15:00 UTC. The current version of Kava for `kava-9` is [__v0.16.1__](https://github.com/Kava-Labs/kava/releases/tag/v0.16.1).
The canonical genesis file can be found [here](https://github.com/Kava-Labs/launch/tree/master/kava-9)
The canonical genesis file hash is
```
jq -S -c -M '' genesis.json | shasum -a 256
5c688df5ae6cba9c9e5a9bab045eb367dd54ce9b7f5fab78cf3e636cf2e2b793 -
```
For additional information about upgrades:
- Upgrading a [Validator](https://github.com/Kava-Labs/kava/blob/master/docs/kava-8/upgrade_validator.md)
- Upgrading a [Wallet](https://github.com/Kava-Labs/kava/blob/master/docs//kava-8/upgrade_wallet.md)
- Upgrading an [Oracle](https://github.com/Kava-Labs/kava/blob/master/docs//kava-8/upgrade_oracle.md)
### Validator Guide
Use this [guide](https://github.com/Kava-Labs/kava/blob/master/docs/validator_guide.md) to set up a mainnet validator. Note that this is a minimal guide and does not cover more advanced topics like [sentry node architecture](https://github.com/stakefish/cosmos-validator-design) and [double signing protection](https://github.com/tendermint/tmkms). It is strongly recommended that any parties considering validating do additional research. If you have questions, please join the active conversation in the #validators thread of the [__Kava Discord Channel__](https://discord.com/invite/kQzh3Uv).
## Testnet
For further information on joining the testnet, head over to the [testnet repo](https://github.com/Kava-Labs/kava-testnets).
## License
Copyright © Kava Labs, Inc. All rights reserved.
Licensed under the [Apache v2 License](LICENSE.md).

View File

@ -1,194 +0,0 @@
# Validator Guide
This is an updated guide on setting up a mainnet validator. Note that this is a minimal guide and does not cover more advanced topics like [sentry node architecture](https://github.com/stakefish/cosmos-validator-design) and [double signing protection](https://github.com/tendermint/tmkms). It is strongly recommended that any parties considering validating do additional research. If you have questions, please join the active conversation in the #validators thread of our [__Discord Channel__](https://discord.com/invite/kQzh3Uv).
## Installing Kava
### Prerequisites
You should select an all-purpose server with at least 8GB of RAM, good connectivity, and a solid state drive with sufficient disk space. Storage requirements are discussed further in the section below. In addition, youll need to open **port 26656** to connect to the Kava peer-to-peer network. As the usage of the blockchain grows, the server requirements may increase as well, so you should have a plan for updating your server as well.
### Storage
The monthly storage requirements for a node are as follows. These are estimated values based on experience, but should serve as a good guide.
- An archival node (`pruning = "nothing"`) grows at a rate of ~100 GB per month
- A fully pruning node (`pruning = "everything"`) grows at a rate of ~5 GB per month
- A default pruning node (`pruning = “default”`) grows at a rate of ~25 GB per month
## Install Go
Kava is built using Go and requires Go version 1.17+. In this example, you will be installing Go on a fresh install of ubuntu 20.04.
```bash
# Update ubuntu
sudo apt update
sudo apt upgrade -y
# Install packages necessary to run go and jq for pretty formatting command line outputs
sudo apt install build-essential jq -y
# Install git
sudo apt install git
# Install go
wget https://dl.google.com/go/go1.17.6.linux-amd64.tar.gz (or latest version at https://golang.org/dl/)
sudo tar -xvf go1.17.6.linux-amd64.tar.gz
sudo mv go /usr/local
# Updates environmental variables to include go
cat <<EOF>> ~/.profile
export GOROOT=/usr/local/go
export GOPATH=$HOME/go
export GO111MODULE=on
export PATH=$PATH:/usr/local/go/bin:$HOME/go/bin
EOF
source ~/.profile
```
To verify that Go is installed:
```bash
go version
# Should return go version go1.17.6 linux/amd64
```
## Install Kava
Install Kava using `git clone`. Note that version 0.16.1 is the correct version for mainnet.
```bash
git clone https://github.com/kava-labs/kava
cd kava
git checkout v0.16.1
make install
```
To verify that kava is installed:
```bash
kava version --long
# name: kava
# server_name: kava
# version: 0.16.1
# commit: c2257c409659e2a6c1c8907fe5ae596c5e46f19d
# build_tags: netgo,ledger
# go: go version go1.17.6 linux/amd64
```
## Configuring Your Node
Next, download the correct genesis file and sync your node with the Kava mainnet. To download the genesis file:
```bash
# First, initialize kava. Replace <name> with the public name of your node
kava init --chain-id kava-9 <name>
# Download the genesis file
wget https://kava-genesis-files.s3.amazonaws.com/kava-9/genesis.json -O ~/.kava/config/genesis.json
# Verify genesis hash
jq -S -c -M '' $HOME/.kava/config/genesis.json | shasum -a 256
# 5c688df5ae6cba9c9e5a9bab045eb367dd54ce9b7f5fab78cf3e636cf2e2b793
```
Next, adjust some configurations. To open the config file:
```bash
vim $HOME/.kava/config/config.toml
```
At line 212, add [seeds](https://docs.google.com/spreadsheets/d/1j-e1HTkskNRS6mlhxLLQa0loB-ShcVUjz8WVVZxvPaY). These are used to connect to the peer-to-peer network:
At line 215, add some [persistent peers](https://docs.google.com/spreadsheets/d/1j-e1HTkskNRS6mlhxLLQa0loB-ShcVUjz8WVVZxvPaY), which help maintain a connection to the peer-to-peer network
Next, chose how much historical state you want to store. To open the application config file:
```bash
vim $HOME/.kava/config/app.toml
```
In this file, choose between `default`, `nothing`, and `everything`. To reduce hard drive storage, choose `everything` or `default`. To run an archival node, chose `nothing`.
```bash
pruning = "default"
```
In the same file, you will want to set minimum gas prices — setting a minimum prevents spam transactions:
```bash
minimum-gas-prices = "0.001ukava"
```
### Syncing Your Node
To sync your node, you will use systemd, which manages the Kava daemon and automatically restarts it in case of failure. To use systemd, you will create a service file. Be sure to replace `<your_user>` with the user on your server:
```bash
sudo tee /etc/systemd/system/kavad.service > /dev/null <<'EOF'
[Unit]
Description=Kava daemon
After=network-online.target
[Service]
User=<your_user>
ExecStart=/home/<your_user>/go/bin/kava start
Restart=on-failure
RestartSec=3
LimitNOFILE=4096
[Install]
WantedBy=multi-user.target
EOF
```
To start syncing:
```bash
# Start the node
sudo systemctl enable kavad
sudo systemctl start kavad
```
To check on the status of syncing:
```bash
kava status --log_format json | jq '.sync_info'
```
This will give output like:
```bash
{
"latest_block_hash": "03BC172D991C3D66BAAA12A41CAA1A4718C63605B71FD9E0EF09EC38C2DA9F85",
"latest_app_hash": "FBC020AC8258C4854D2D3384E78929384B0BFBA462F948D493E7883AD315B38C",
"latest_block_height": "36",
"latest_block_time": "2022-01-19T16:22:18.54790946Z",
"earliest_block_hash": "C124499F70881EC71F41231DAB111F448558C5A7794D044F0613E1509FA4C8DF",
"earliest_app_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855",
"earliest_block_height": "1",
"earliest_block_time": "2022-01-19T16:00:00Z",
"catching_up": true
}
```
The main thing to watch is that the block height is increasing. Once you are caught up with the chain, `catching_up` will become false. At that point, you can start using your node to create a validator. If you need to sync using a snapshot, please use https://kava.quicksync.io/
To check the logs of the node:
```bash
sudo journalctl -u kavad -f
```
## Creating a Validator
First, create a wallet, which will give you a private key / public key pair for your node.
```bash
# Replace <your-key-name> with a name for your key that you will remember
kava keys add <your-key-name>
# To see a list of wallets on your node
kava keys list
```
**Be sure to write down the mnemonic for your wallet and store it securely. Losing your mnemonic could result in the irrecoverable loss of KAVA tokens.**
To see the options when creating a validator:
```bash
kava tx staking create-validator -h
```
An example of creating a validator with 50KAVA self-delegation and 10% commission:
```bash
# Replace <key_name> with the key you created previously
kava tx staking create-validator \
--amount=50000000ukava \
--pubkey=$(kava tendermint show-validator) \
--moniker="choose moniker" \
--website="optional website for your validator" \
--details="optional details for your validator" \
--commission-rate="0.10" \
--commission-max-rate="0.20" \
--commission-max-change-rate="0.01" \
--min-self-delegation="1" \
--from=<your-key-name> \
--chain-id=kava-9 \
--gas=auto \
--gas-adjustment=1.4
```
To check on the status of your validator:
```bash
kava status --log_format json | jq '.ValidatorInfo'
```
After you have completed this guide, your validator should be up and ready to receive delegations. Note that only the top 100 validators by weighted stake (self-delegations + other delegations) are eligible for block rewards. To view the current validator list, checkout one of the Kava block explorers:
- https://www.mintscan.io/kava
- https://kava.bigdipper.live/
- https://kavascan.com/
If you have questions, please join the active conversation in the #validators thread of the [__Kava Discord Channel__](https://discord.com/invite/kQzh3Uv).