mirror of
https://github.com/0glabs/0g-chain.git
synced 2024-11-10 10:05:18 +00:00
removal of docs dir, migrated to discrete repo (#1169)
This commit is contained in:
stephensprinkle
GitHub
parent
c5dad2f19c
commit
666f136661
@ -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 |
@ -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 |
@ -1,3 +0,0 @@
|
|||||||
:root
|
|
||||||
--color-link #ff554f
|
|
||||||
--color-primary #ff554f
|
|
||||||
@ -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.
|
|
||||||
@ -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 CDP’s 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.
|
|
||||||
@ -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 don’t 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.
|
|
||||||
@ -1,3 +0,0 @@
|
|||||||
# Application Process
|
|
||||||
|
|
||||||
We are working on updating our entire documentation to provide a better user experience, please check back later!
|
|
||||||
@ -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!
|
|
||||||
@ -1,3 +0,0 @@
|
|||||||
# Mainnet Upgrade
|
|
||||||
|
|
||||||
We are working on updating our entire documentation to provide a better user experience, please check back later!
|
|
||||||
@ -1,3 +0,0 @@
|
|||||||
# Testnet
|
|
||||||
|
|
||||||
We are working on updating our entire documentation to provide a better user experience, please check back later!
|
|
||||||
@ -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.
|
|
||||||
```
|
|
||||||
@ -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
|
|
||||||
```
|
|
||||||
|
|
||||||
@ -1,3 +0,0 @@
|
|||||||
# Lite Paper
|
|
||||||
|
|
||||||
We are working on updating our entire documentation to provide a better user experience, please check back later!
|
|
||||||
@ -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
|
|
||||||
```
|
|
||||||
|
|
||||||
@ -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
|
|
||||||
```
|
|
||||||
|
|
||||||
@ -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
|
|
||||||
```
|
|
||||||
|
|
||||||
@ -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
|
|
||||||
```
|
|
||||||
@ -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
|
|
||||||
|
|
||||||
```
|
|
||||||
@ -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
|
|
||||||
|
|
||||||
```
|
|
||||||
@ -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
|
|
||||||
|
|
||||||
```
|
|
||||||
@ -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
|
|
||||||
```
|
|
||||||
@ -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
|
|
||||||
```
|
|
||||||
@ -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
|
|
||||||
```
|
|
||||||
@ -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
|
|
||||||
```
|
|
||||||
@ -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
|
|
||||||
```
|
|
||||||
@ -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
|
|
||||||
|
|
||||||
```
|
|
||||||
@ -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
|
|
||||||
|
|
||||||
```
|
|
||||||
@ -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
|
|
||||||
|
|
||||||
```
|
|
||||||
@ -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
|
|
||||||
```
|
|
||||||
201
docs/LICENSE.md
201
docs/LICENSE.md
@ -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.
|
|
||||||
@ -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 doesn’t 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 People’s 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!_
|
|
||||||
@ -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 |
@ -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 Kava’s 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
|
|
||||||
|
|
||||||
@ -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 withdrawer’s 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 requester’s 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 requester’s 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
|
|
||||||
Kava’s 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).
|
|
||||||
@ -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 withdrawer’s 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 requester’s 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 requester’s 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
|
|
||||||
Kava’s 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/).
|
|
||||||
@ -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
|
|
||||||
```
|
|
||||||
@ -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`
|
|
||||||
|
|
||||||
@ -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, you’ll 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
10545
docs/package-lock.json
generated
File diff suppressed because it is too large
Load Diff
@ -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"
|
|
||||||
}
|
|
||||||
}
|
|
||||||
10
docs/post.sh
10
docs/post.sh
@ -1,10 +0,0 @@
|
|||||||
#!/usr/bin/env bash
|
|
||||||
|
|
||||||
# Modules
|
|
||||||
rm -rf Modules
|
|
||||||
|
|
||||||
# JavaScript SDK docs
|
|
||||||
rm -rf building
|
|
||||||
|
|
||||||
# Kava Tools docs
|
|
||||||
rm -rf tools
|
|
||||||
49
docs/pre.sh
49
docs/pre.sh
@ -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"
|
|
||||||
@ -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}}
|
|
||||||
@ -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).
|
|
||||||
@ -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, you’ll 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).
|
|
||||||
Loading…
Reference in New Issue
Block a user