# Introduction Welcome to the Panacea Core docs. * Features covers what you can do with the Panacea Core, and gives a high level intuition of its core mechanisms. * Guide offers setup instructions on how to setup a node, join existing networks. * Specifications contains detailed specifications for each module in the Panacea Core. # Tech Stack ![](https://1593867360-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4XhNqormtfUnsTNcYwRk%2Fuploads%2Fgit-blob-ca5153f9709edb009107e88631299ff677b46e0b%2Ftech-stack.png?alt=media) ## The benefit from Cosmos SDK and Tendermint The Panacea is a public blockchain based on the Cosmos SDK and the Tendermint. As the Tendermint implements a partially synchronous BFT (Byzantine fault-tolerant) consensus protocol, Panacea can provide a high-performance, consistent and secure decentralized network where strict fork-accountability guarantees hold over the behavior of malicious actors. On the top of that, the Cosmos SDK implements DPoS (Delegated Proof of Stake) model and provides various cryptographic operations such as tokens, governance and IBC (Inter-Blockchain Communication). Panacea inherits all of their strengths without reinventing the wheel. It means that Panacea can guarantee the fast finality and the solid network security and can be connected with them without any compatibility/safety issues. Based on the model of the Cosmos SDK and the Tendermint, new features have been added to Panacea for building the patient-centered health data ecosystem. We will cover details of each feature in next chapters. ## DID (Decentralized Identifier) ![](https://1593867360-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4XhNqormtfUnsTNcYwRk%2Fuploads%2Fgit-blob-8b522047384a819be7bd4e786a78238ca83894f6%2Fdid-vc.png?alt=media) Panacea provides a DID method which conforms to the specification of W3C (World Wide Web Consortium), so that users can verify their identity or the integrity of their data without relying on any third-party authorities. Anyone can create, update and deactivate DIDs on Panacea that guarantees the integrity of DID-related cryptographic data including DID public keys. The core usage of DID in the health data ecosystem is signing on the health data that needs to be shared to any parties that want to verify whether the data is forgery or not. As the mechanism of signing on data using DID and verifying signatures has been standardized by W3C, anyone can easily use the Panacea DID without any compatibility issue. Also, data holders can reveal only data that they really want to share using the DID-based ZKP(Zero-knowledge Proof). This mechanism is so essential for the health data ecosystem because patients can keep the ownership of their health data and choose the level of privacy by themselves. ## IBC (Inter-Blockchain Communication) Since Panacea is a Cosmos-based blockchain, it can be connected with other Cosmos-based blockchains through the IBC protocol. Also, bridges for non-Cosmos-based chains such as Bitcoin and Ethereum have being actively implemented by various participants in the Cosmos ecosystem. Of course, Panacea is going to be integrated with those inter-chain protocols for enabling more people to benefit from the Panacea-based health data ecosystem. # Getting started This section will guide the reader to install, deploy, and interact with the Panacea blockchain. ### Table of contents * **Installation**: Instructions on how to install *panacead*, the server daemon for nodes, the cli tool to interact with panacead. * **How to Join the network**: Panacea is the first official public network running the Panacea Blockchain. This section outlines step by step instructions on how to start operating a node on Panacea. * **How to deploy own Panacea testnet**: How to setup and deploy one's own testnet of the Panacea blockchain, in a single-node local, multi-node local, and remote network context. * **Introduction to panacead**: Using the `panacead` to interact with the Panacea blockchain. * **Clients**: How to spin up a light client daemon, that stores partial state and responds to REST API queries. * **Use the Ledger Nano**: How to interact with the Panacea blockchain using the Ledger Nano S. # Installation ## Install Go [Go 1.26.5](https://golang.org/doc/install) is required. ## Install the `panacead` If you want to install the `panacead` binary to run your node or to communicate with other nodes, please clone the `panacea-core` project and build it. ```bash # Make sure to checkout the correct branch. git clone -b v2.3.0 https://github.com/medibloc/panacea-core cd panacea-core make install # All binaries are installed in $GOPATH/bin ``` Verify that the `panacead` binary is installed successfully. ```bash $ panacead version 2.3.0 ``` ## Import `panacea-core` as a Go dependency If you want to develop Go applications by importing the `panacea-core`, you cannot run `go get github.com/medibloc/panacea-core/v2` directly due to [the design of Go Modules](https://github.com/golang/go/issues/30354) , which doesn't honor `replace` directives in the `go.mod` of the `panacea-core`. As a workaround, please add `replace` directives in your `go.mod` as below. ``` module your.com/yours go 1.26.5 replace ( github.com/99designs/keyring => github.com/cosmos/keyring v1.2.0 github.com/syndtr/goleveldb => github.com/syndtr/goleveldb v1.0.1-0.20210819022825-2ae1ddf74ef7 // If you are using a ledger, you may need to replace the line as shown below: github.com/cosmos/ledger-cosmos-go => github.com/cosmos/ledger-cosmos-go v0.12.4 ) ``` Then, you can `go get` the `panacea-core`. ```bash go get github.com/medibloc/panacea-core/v2 ``` # Join the Network This tutorial introduces deploying a new node on [AWS](https://aws.amazon.com/) and join the Panacea Mainnet. ## Launch an AWS EC2 Instance ### Choose an AMI Choose Ubuntu Server 20.04 LTS 64-bit (x86) with SSD Volume Type. ![](https://1593867360-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4XhNqormtfUnsTNcYwRk%2Fuploads%2Fgit-blob-46709c161eb073bb9357601b92a712c973619295%2Fec2-ami.png?alt=media) ### Choose the instance type Choose the `m5.large` instance type (minimum spec). ![](https://1593867360-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4XhNqormtfUnsTNcYwRk%2Fuploads%2Fgit-blob-5f92125c86655b3088f71ff0c8c6229868bcba0e%2Fec2-instance-type.png?alt=media) ### Configure instance details | Configuration | Value | | --------------------- | ----------------------------------------------------------------- | | Network | Choose an existing VPC or default one if you don't have any | | Subnet | Choose an existing subnet or default one if you don't have any | | Auto-assign Public IP | Enable only if you access a full node from the outside of its VPC | | Other fields | Follow default settings | ### Add a storage | Configuration | Value | | ------------- | --------------------------- | | Size | 500 GiB | | Volume Type | `General Purpose SSD (gp3)` | | IOPS | 3000 | | Throughput | 125 MB/s | ### Configure a Security Group | Type | Protocol | Port range | Description | | ---------- | -------- | ---------- | -------------------- | | SSH | TCP | 22 | | | Custom TCP | TCP | 26656 | P2P with other nodes | | Custom TCP | TCP | 26657 | RPC | | Custom TCP | TCP | 1317 | HTTP | The P2P `26656` port must be exposed to other Panacea nodes. If your node will be in the VPC guarded by Sentry nodes, expose `26656` to only Sentry nodes (recommended). If not, expose it to anywhere. For details about Sentry nodes, please see the [Tendermint guide](https://docs.tendermint.com/master/nodes/validators.html#local-configuration). The RPC `26657` and HTTP `1317` ports are for sending transactions/queries to your node. So, expose them to the network where you perform operational actions. ### Connect to your EC2 instance and install prerequisites. ```bash ssh ubuntu@ -i .pem ``` Install prerequisites by following the [Installation](/guide/installation) guide. ## Setup a New Node These instructions are for setting up a brand new full node from scratch. First, initialize the node and create the necessary config files: ```bash panacead init ``` {% hint style="warning" %} The `moniker` can contains only ASCII characters. Using Unicode characters will render your node unreachable. {% endhint %} Then, modify the `timeout_commit` in the `~/.panacead/config/config.toml` as below. ```toml [consensus] timeout_commit = "5s" ``` After that, edit the `~/.panacead/config/app.toml` file in order to enable the anti-spam mechanism and reject incoming transactions with less than the `minimum-gas-prices`: ```toml # Validators reject any tx from the mempool with less than the minimum-gas-prices. minimum-gas-prices = "5umed" # NOTE: For the Testnet, please set minimum-gas-prices as "", so that no fee is required. ``` Now, your full node has been initialized! ### Copy the Genesis file Fetch the `genesis.json` file of the latest chain from the following links, and place it to `~/.panacead/config/genesis.json`. * Mainnet: * Testnet: ### Configure Seed Nodes Your node needs to know how to find peers. Seed nodes can be found in: * Mainnet: * Testnet: Insert those `@`s with 26656 port to the `persistent_peers` field in `~/.panacead/config/config.toml`. ```toml # Comma separated list of nodes to keep persistent connections to persistent_peers = "2f75e475009b8514efdadf063e40f662be76dfdf@52.79.108.35:26656,0e030ab48abc25ff2918ab019fd74d5447d7582e@15.165.127.151:26656,f808eb775180345c3b443d55afcc3c148dd19183@3.37.237.120:26656" ``` For more information on seeds and peers, see the [Using Tendermint: Peers](https://docs.tendermint.com/master/tendermint-core/using-tendermint.html#peers). ### State Sync Your node can rapidly sync with the network using state sync without replaying historical blocks. For more details, please refer to [this](https://docs.tendermint.com/v0.34/tendermint-core/state-sync.html). To set state sync enabled, RPC servers and trusted block info (height and hash) are required. trusted block info can be obtained via RPC. ```shell curl -s https://rpc.gopanacea.org/block | jq -r '.result.block.header.height + "\n" + .result.block_id.hash' # 7700000 (height) # 0D3E53F02ABCDDA8AAC1520342D37A290DDABE4C28190EE6E2C6B0C819F74D4A (hash) ``` Then, you need to edit several things in `~/.panacea/config/config.toml` file. ```toml [statesync] enable = true rpc_servers = "https://rpc.gopanacea.org:443,https://rpc.gopanacea.org:443" # rpc addresses trust_height = trust_hash = "" trust_period = "336h0m0s" # 2/3 of 21 days (unbonding period) ``` If your node have block history data previously synced, you need to clear the data first. ```shell panacead tendermint unsafe-reset-all ``` ## Run a Full Node Start the full node with this command: ```bash panacead start ``` Check that everything is running smoothly: ```bash panacead status ``` View the status of the network with the Block Explorer * Mainnet: * Testnet: ## Join as a validator If you want to participate in validating blocks as a validator, you can register yourself into the validator set by submitting a transaction. For more details, see the [CLI guide](/guide/interaction-with-the-network-cli#staking). # Deploy a Testnet This document describes 2 ways to setup a network of `panacead` nodes. 1. [Using multiple machines](#using-multiple-machines) 2. [Using a single machine (using Docker)](#using-a-single-machine-using-docker) ## Using multiple machines ### Deploy the first node ```bash # Initialize the genesis.json file that will help you to bootstrap the network panacead init node1 --chain-id=testing # Create a key to hold your validator account panacead keys add validator # Add that key into the genesis.app_state.accounts array in the genesis file # NOTE: this command lets you set the number of coins. Make sure this account has some coins # with the genesis.app_state.staking.params.bond_denom denom. panacead genesis add-genesis-account $(panacead keys show validator -a) 100000000000000umed # Generate the transaction that creates your validator panacead genesis gentx validator 1000000000000umed --commission-rate 0.1 --commission-max-rate 0.2 --commission-max-change-rate 0.01 --min-self-delegation 1000000 --chain-id testing # Add the generated bonding transaction to the genesis file panacead genesis collect-gentxs # Now its safe to start `panacead` panacead start ``` This setup puts all the data for `panacead` in `~/.panacea`. You can examine the genesis file that you created at `~/.panacea/config/genesis.json`. ### Deploy the second node Init the second node using another moniker: `node2`. ```bash panacead init node2 --chain-id=testing ``` Overwrite `~/.panacea/config/genesis.json` with the first node's `genesis.json`. Get a node ID of the first node. ```bash panacead tendermint show-node-id # example response > 46046c89ec576daa0662613ee0142ab61dd2421e ``` Set a `persistent_peers` in the `~/.panacea/config/config.toml` of the second node. ```toml # Comma separated list of nodes to keep persistent connections to persistent_peers = "@:26656" ``` Start the second node. ```bash panacead start ``` # Interaction with the network: CLI For more information on the command usage, refer to its help screen: `panacead --help`. Here is a list of useful `panacead` commands, including usage examples. ## Keys ### Key Types There are three types of key representations that are used: * `panacea` * Derived from account keys generated by `panacead keys add` * Used to receive funds * e.g. `panacea17kmacx3czkdnhtfueqzzxk9xqzapj453f23m5a` * `panaceavaloper` * Used to associate a validator to it's operator * Used to invoke staking commands * e.g. `panaceavaloper17kmacx3czkdnhtfueqzzxk9xqzapj453wg3mgr` * `panaceapub` * Derived from account keys generated by `panacead keys add` * e.g. `panaceapub1addwnpepqwk3j2j3knuyah89skh8wtn5kr4qx32nhql6hzjadzmre2xlfmvxgy39ln8` * `panaceavalconspub` * Generated when the node is created with `panacead init`. * Get this value with `panacead tendermint show-validator` * e.g. `panaceavalconspub1zcjduepqktkqqsl9rchj77v9vg0crc87grp9h2u5ggpdtvcq74kxlr29lgwsa3dr66` ### Generate Keys You'll need an account private and public key pair (a.k.a. `sk, pk` respectively) to be able to receive funds, send txs, bond tx, etc. To generate a new *secp256k1* key: ```bash panacead keys add ``` Previously, you had to enter a password to save it to disk, but you do not currently need to. [Setting up the keyring](https://docs.cosmos.network/v0.47/learn/beginner/accounts#keyring) If you check your private keys, you'll now see ``: ```bash panacead keys show ``` View the validator operator's address via: ```bash panacead keys show --bech=val ``` You can see all your available keys by typing: ```bash panacead keys list ``` View the validator pubkey for your node by typing: ```bash panacead tendermint show-validator ``` Note that this is the Tendermint signing key, *not* the operator key you will use in delegation transactions. ::: danger Warning We strongly recommend *NOT* using the same passphrase for multiple keys. The MediBloc team will not be responsible for the loss of funds. ::: ## Fees & Gas Each transaction may either supply fees or gas prices, but not both. Most users will typically provide fees as this is the cost you will end up incurring for the transaction being included in the ledger. Validator's have a minimum gas price configuration and they use this value when determining if they should include the transaction in a block during `CheckTx`, where `gasPrices >= minGasPrices`. Note, your transaction must supply fees that are greater than or equal to minimum fee which the validator requires. **Note**: With such a mechanism in place, validators may start to prioritize txs by `gasPrice` in the mempool, so providing higher fees or gas prices may yield higher tx priority. e.g. ```bash panacead tx send ... --fees=1000000umed ``` or ```bash panacead tx send ... --gas-prices=5umed ``` ## Account ### Query Account To view your account information: ```bash panacead query account ``` ## Bank ### Query balance After receiving tokens to your address, you can view your account's balance by typing: ```bash panacead query bank balances ``` ::: warning Note When you query an account balance with zero tokens, you will get this error: `account does not exist.` This can also happen if you fund the account before your node has fully synced with the chain. These are both normal.::: ## Send Tokens The following command could be used to send coins from one account to another: ```bash panacead tx bank send \ \ \ \ --chain-id \ --from \ --fees 1000000umed ``` where `to_address` is a key matching the format: `panacea1y3mhszahwatjc3023datq46a0u2fv337tes4n9` ::: warning Note The `` accepts the format ` -> ex) 10000000umed`. ::: ::: tip Note You may want to cap the maximum gas that can be consumed by the transaction via the `--gas` flag. If you pass `--gas=auto`, the gas supply will be automatically estimated before executing the transaction. Gas estimate might be inaccurate as state changes could occur in between the end of the simulation and the actual execution of a transaction, thus an adjustment is applied on top of the original estimate in order to ensure the transaction is broadcasted successfully. The adjustment can be controlled via the `--gas-adjustment` flag, whose default value is 1.0. ::: Now, view the updated balances of the origin and destination accounts: ```bash panacead query bank balances panacead query bank balances ``` You can also check your balance at a given block by using the `--height` flag: ```bash panacead query account --height= ``` You can simulate a transaction without actually broadcasting it by appending the `--dry-run` flag to the command line: ```bash panacead tx bank send \ \ \ \ --from \ --chain-id \ --dry-run ``` Furthermore, you can build a transaction and print its JSON format to STDOUT by appending `--generate-only` to the list of the command line arguments: ```bash panacead tx bank send \ \ \ \ --chain-id \ --fees 1000000umed \ --generate-only > unsignedSendTx.json ``` ```bash panacead tx sign \ --chain-id \ --from \ unsignedSendTx.json > signedSendTx.json ``` You can validate the transaction's signatures by typing the following: ```bash panacead tx validate-signatures \ --chain-id \ signedSendTx.json ``` You can broadcast the signed transaction to a node by providing the JSON file to the following command: ```bash panacead tx broadcast --chain-id signedSendTx.json ``` ## Query Transactions ### Matching a set of events You can use the transaction search command to query for transactions that match a specific set of `events`, which are added on every transaction. Events are implemented in the Cosmos SDK as an alias of the ABCI `Event` type and take the form of: `{eventType}.{attributeKey}={attributeValue}`. Events can also be combined to query for a more specific result using the `&` symbol. The command for querying transactions using a `event` is the following: ```bash panacead query txs --events 'message.module=bank' ``` And for using multiple `events`: ```bash panacead query txs --events 'message.module=bank&tx.height=5' ``` The pagination is supported as well via `page` and `limit`: ```bash panacead query txs --events 'message.module=bank' --page 1 --limit 20 ``` ::: tip Note The action tag always equals the message type returned by the `Type()` function of the relevant message. You can find a list of available `tags` on each module by looking at the /tags directory of each module. ::: ### Matching a transaction's hash You can also query a single transaction by its hash using the following command: ```bash panacead query tx [hash] ``` ## Slashing ### Unjailing To unjail your jailed validator ```bash panacead tx slashing unjail \ --from \ --chain-id \ --fees 1000000umed ``` ### Signing Info To retrieve a validator's signing info: ```bash panacead query slashing signing-info ``` ### Query Parameters You can get the current slashing parameters via: ```bash panacead query slashing params ``` ## Staking ### Create your validator {% hint style="info" %} This guide assumes that you have already set up your full node by following [the guide](/guide/join-the-network). {% endhint %} Your `panaceavalconspub` address (public key) can be used to create a new validator by staking tokens. You can find your validator public key by: ```bash panacead tendermint show-validator ``` Execute the following command to create your validator: {% hint style="warning" %} Don't use more `umed` than you have! {% endhint %} ```bash panacead tx staking create-validator \ --pubkey $(panacead tendermint show-validator) \ --moniker "choose a moniker" \ --chain-id \ --commission-rate "0.10" \ --commission-max-rate "0.20" \ --commission-max-change-rate "0.01" \ --min-self-delegation "1" \ --amount 10000000umed \ --fees 1000000umed \ --from ``` * `pubkey`: A public key associated with the Tendermint private key (which was generated by `panacead init`). The public key can be resolved by `panacead tendermint show-validator` in the node that you want to make as a validator. For details about various key types, please see this [guide](#keys). * `moniker`: A validator nickname that will be displayed publicly * `commission-rate`: An initial commission rate on block rewards and fees charged to delegators * This shouldn't be smaller than the minimum commission rate (a genesis parameter) that can be queried by `panacead query staking params`. * `commission-max-rate`: A maximum commission rate which this validator can charge. This cannot be changed after the `create-validator` transaction is processed. * `commission-max-change-rate`: A maximum daily increase of the validator commission. This cannot be changed after the `create-validator` transaction is processed. This is used to measure % point change over the `commision-rate`. E.g. 1% to 2% is a 100% rate increase, but only 1% point. * `min-self-delegation`: A strictly positive integer in `umed` that represents the minimum amount of self-delegated voting power your validator must always have. If the validator's self-delegated stake falls below this limit, their entire staking pool will unbond. * `amount`: An amount of your self-delegation **Note:** A minimum amount of MEDs that must be delegated to be an active validator is `1med` (`1000000umed`). In other words, validators cannot be in the active set, if their total stake (= self-bonded stake + delegators stake) is under `1med`. You can confirm that you are in the validator set by the following command: ```bash panacead query staking validators ``` ### Edit validator description You can edit your validator's public description. This info is to identify your validator, and will be relied on by delegators to decide which validators to stake to. Make sure to provide input for every flag below. If a flag is not included in the command the field will default to empty (`--moniker` defaults to the machine name) if the field has never been set or remain the same if it has been set in the past. The `--from` option specifies which validator you are editing. ```bash panacead tx staking edit-validator \ --moniker "choose a new moniker" \ --website "https://example.com" \ --details "This is a detail description" \ --chain-id \ --commission-rate "0.15" \ --from \ --fees 1000000umed ``` **Note**: The `--commission-rate` value must adhere to the following invariants: * Must be between the minimum commission rate (a genesis parameter) and the validator's `commission-max-rate` * Must not exceed the validator's `commission-max-change-rate` which is maximum % point change rate **per day**. In other words, a validator can only change its commission once per day and within `commission-max-change-rate` bounds. ### Delegate to a Validator You can delegate `umed` to a validator. These delegators can receive part of the validator's fee revenue. **Query Validators** You can query the list of all validators of a specific chain: ```bash panacead query staking validators ``` If you want to get the information of a single validator you can check it with: ```bash panacead query staking validator ``` ### Bond Tokens Here's how you can bond tokens to a validator (*i.e.* delegate): ```bash panacead tx staking delegate \ \ 10000000umed \ --from \ --chain-id ``` `` is the operator address of the validator to which you intend to delegate. If you are running a local testnet, you can find this with: ```bash panacead keys show [name] --bech val ``` where `[name]` is the name of the key you specified when you initialized `panacead`. While tokens are bonded, they are pooled with all the other bonded tokens in the network. Validators and delegators obtain a percentage of shares that equal their stake in this pool. **Query Delegations** Once submitted a delegation to a validator, you can see it's information by using the following command: ```bash panacead query staking delegation ``` Or if you want to check all your current delegations with distinct validators: ```bash panacead query staking delegations ``` You can also get previous delegation(s) status by adding the `--height` flag. ### Unbond Tokens If for any reason the validator misbehaves, or you just want to unbond a certain amount of tokens, use this following command. ```bash panacead tx staking unbond \ \ 10000umed \ --from \ --chain-id ``` The unbonding will be automatically completed when the unbonding period has passed. **Query Unbonding-Delegations** Once you begin an unbonding-delegation, you can see it's information by using the following command: ```bash panacead query staking unbonding-delegation ``` Or if you want to check all your current unbonding-delegations with disctinct validators: ```bash panacead query staking unbonding-delegations ``` Additionally, as you can get all the unbonding-delegations from a particular validator: ```bash panacead query staking unbonding-delegations-from ``` To get previous unbonding-delegation(s) status on past blocks, try adding the `--height` flag. ### Redelegate Tokens A redelegation is a type delegation that allows you to bond illiquid tokens from one validator to another: ```bash panacead tx staking redelegate \ \ \ 10000umed \ --from \ --chain-id ``` The redelegation will be automatically completed when the unbonding period has passed. **Query Redelegations** Once you begin an redelegation, you can see it's information by using the following command: ```bash panacead query staking redelegation ``` Or if you want to check all your current unbonding-delegations with disctinct validators: ```bash panacead query staking redelegations ``` Additionally, as you can get all the outgoing redelegations from a particular validator: ```bash panacead query staking redelegations-from ``` To get previous redelegation(s) status on past blocks, try adding the `--height` flag. ### Query Parameters Parameters define high level settings for staking. You can get the current values by using: ```bash panacead query staking params ``` With the above command you will get the values for: * Unbonding time * Maximum numbers of validators * Maximum entries * Coin denomination for staking ### Query Pool A staking `Pool` defines the dynamic parameters of the current state. You can query them with the following command: ```bash panacead query staking pool ``` With the `pool` command you will get the values for: * Not-bonded and bonded tokens ## Fee Distribution ### Query distribution parameters To check the current distribution parameters, run: ```bash panacead query distribution params ``` ### Query validator commission To check the current outstanding commission for a validator, run: ```bash panacead query distribution commission ``` ### Query validator slashes To check historical slashes for a validator, run: ```bash panacead query distribution slashes ``` ### Query delegator rewards To check current rewards for a delegation (were they to be withdrawn), run: ```bash panacead query distribution rewards ``` ### Query all delegator rewards To check all current rewards for a delegation (were they to be withdrawn), run: ```bash panacead query distribution rewards ``` ## Multisig transactions Multisig transactions require signatures of multiple private keys. Thus, generating and signing a transaction from a multisig account involve cooperation among the parties involved. A multisig transaction can be initiated by any of the key holders, and at least one of them would need to import other parties' public keys into their Keybase and generate a multisig public key in order to finalize and broadcast the transaction. For example, given a multisig key comprising the keys `p1`, `p2`, and `p3`, each of which is held by a distinct party, the user holding `p1` would require to import both `p2` and `p3` in order to generate the multisig account public key: ``` panacead keys add \ p2 \ --pubkey '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"AhExixh..."}' panacead keys add \ p3 \ --pubkey '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"A3ntuPW..."}' panacead keys add \ p1p2p3 \ --multisig-threshold 2 \ --multisig p1,p2,p3 ``` A new multisig public key `p1p2p3` has been stored, and its address will be used as signer of multisig transactions: ```bash panacead keys show --address p1p2p3 ``` You may also view multisig threshold, pubkey constituents and respective weights by viewing the JSON output of the key or passing the `--show-multisig` flag: ```bash panacead keys show p1p2p3 --output json ``` The first step to create a multisig transaction is to initiate it on behalf of the multisig address created above: ```bash panacead tx bank send 10umed \ --from \ --chain-id \ --generate-only > unsignedTx.json ``` The file `unsignedTx.json` contains the unsigned transaction encoded in JSON. `p1` can now sign the transaction with its own private key: ```bash panacead tx sign \ unsignedTx.json \ --multisig \ --from p1 \ --output-document p1signature.json \ --chain-id ``` Once the signature is generated, `p1` transmits both `unsignedTx.json` and `p1signature.json` to `p2` or `p3`, which in turn will generate their respective signature: ```bash panacead tx sign \ unsignedTx.json \ --multisig \ --from p2 \ --output-document p2signature.json \ --chain-id ``` `p1p2p3` is a 2-of-3 multisig key, therefore one additional signature is sufficient. Any the key holders can now generate the multisig transaction by combining the required signature files: ```bash panacead tx multisign \ unsignedTx.json \ p1p2p3 \ p1signature.json p2signature.json \ --output-document signedTx.json \ --chain-id ``` The transaction can now be sent to the node: ```bash panacead tx broadcast signedTx.json \ --chain-id ``` ## Shells completion scripts Completion scripts for popular UNIX shell interpreters such as `Bash` and `Zsh` can be generated through the `completion` command, which is available for both `panacead`. If you want to generate `Bash` completion scripts run the following command: ```bash panacead completion > panacead_completion ``` If you want to generate `Zsh` completion scripts run the following command: ```bash panacead completion --zsh > panacead_completion ``` ::: tip Note On most UNIX systems, such scripts may be loaded in `.bashrc` or `.bash_profile` to enable Bash autocompletion: ```bash echo '. panacead_completion' >> ~/.bashrc ``` Refer to the user's manual of your interpreter provided by your operating system for information on how to enable shell autocompletion. ::: ## AOL ### Create Topic You can create topic with this: ```bash panacead tx aol create-topic \ --from \ ``` ### List Topics You can query the list of topics belong to specific account: `panacead query aol list-topics ` You can get the detail information of the topic with this: ```bash panacead query aol get-topic ``` **Add Writer** You can add writer to the specific topic. the list of all validators of a specific chain: ```bash panacead tx aol add-writer \ --from \ \ ``` ::: tip Note that the topic owner is not a writer as default. You need to add your self to the topic as a writer. ::: ### List Writers You can query the list of writers to the topic: ```bash panacead query aol list-writers ``` You can get the detail information of the writer with this: ```bash panacead query aol get-writer ``` where `[name]` is the name of the key you specified when you initialized `panacead`. While tokens are bonded, they are pooled with all the other bonded tokens in the network. Validators and delegators obtain a percentage of shares that equal their stake in this pool. ### Delete Writer Owner can delete writer from the topic. After owner delete the writer, writer can not add record to the topic anymore. ```bash panacead tx aol delete-writer \ --from \ \ ``` ::: Note that only owner can delete writer from the topic ::: ### Add Record Writer can add record to the topic with this: ```bash panacead tx aol add-record \ --from \ ``` ### Get Record You can query the record with this: ```bash panacead query aol get-record ``` ## DID ### Create(Issue) a DID ```bash panacead tx did create-did \ --chain-id \ --from
``` This doesn't require any parameter except `chain-id` and `from`. That is, it generates a Secp256k1 key-pair and derive a DID and a DID Document. The DID Document is stored in Panacea. To store the key-pair safely in your local, the command will prompt you to enter a passphrase. The encrypted key-pair file will be stored in your `~/did_keystore` directory. ### Resolve a DID ```bash panacead query did get-did ``` This returns a DID Document in JSON corresponding to that DID. If the DID doesn't exist, or was already deactivated, an error will be returned. ### Update a DID ```bash panacead tx did update-did \ --chain-id \ --from
``` A DID Document will be replaced to the new one written in a JSON file: ``. To prove that you are the DID owner, you must pass a `` that is one of `verificationMethod`s in the DID Document. Also, that command will prompt you to enter a passphrase of that key if the key-pair is stored in your keystore: `~/did_keystore`. The key-pair will be used to make a signature so that Panacea can verify that you are the DID owner. ### Deactivate a DID ```bash panacead tx did deactivate-did \ --chain-id \ --from
``` Like updating a DID, a `` must be specified and the corresponding key-pair should be used to make a signature so that Panacea can verify that you are the DID owner. Deactivating a DID is not the same as deleting a DID. DIDs cannot be deleted permanently. They can just be deactivated. And DIDs cannot be reused to create another DID Documents forever. ## NFT {% hint style="warning" %} Panacea v2.3 removes the legacy `pnft` runtime module, queries, and CLI commands. The `pnft` store remains mounted as an inactive, permanently reserved tombstone; no module or keeper reads or writes it, and its state is not migrated. Historical protobuf messages remain decode-only, and attempts to execute them fail. {% endhint %} ### Creating a class The class creator becomes its initial controller. The transfer policy, revocability, and lifetime maximum supply are immutable. A maximum supply of `0` means unlimited. ```bash panacead tx nft create-class \ \ --description \ --uri \ --uri-hash \ --from \ --chain-id \ --fees 1000000umed ``` The response contains the generated class ID in `:` form. ### Updating the controller Only the current controller can assign a new controller. ```bash panacead tx nft update-controller \ --from \ --chain-id \ --fees 1000000umed ``` ### Minting an NFT Only the current class controller can mint. The recipient becomes the initial owner. The optional `--data` flag accepts only a JSON-encoded `/panacea.nft.v1.BasicNFTData` value. ```bash panacead tx nft mint \ --uri \ --uri-hash \ --data '{"@type":"/panacea.nft.v1.BasicNFTData","name":"Certificate #1","description":"Completion certificate","image_uri":"https://example.com/nft-1.png"}' \ --from \ --chain-id \ --fees 1000000umed ``` ### Transferring an NFT Only the current owner can send an NFT, and the class transfer policy must allow owner transfers. ```bash panacead tx nft send \ --from \ --chain-id \ --fees 1000000umed ``` ### Revoking an NFT Only the current class controller can revoke an NFT, and the class must have been created as revocable. Revocation is irreversible but does not change the owner or live supply. ```bash panacead tx nft revoke \ --from \ --chain-id \ --fees 1000000umed ``` ### Burning an NFT Only the current owner can burn an NFT. Burn permanently removes the standard NFT and records a tombstone; the same NFT ID cannot be minted again. ```bash panacead tx nft burn \ --from \ --chain-id \ --fees 1000000umed ``` ### Querying NFTs Standard queries return live Cosmos NFT state: ```bash panacead query nft class panacead query nft classes panacead query nft nft panacead query nft nfts [class-id] --owner panacead query nft owner panacead query nft balance panacead query nft supply ``` Panacea queries include policy, lifecycle, and permanent burn tombstones: ```bash panacead query nft class-record panacead query nft nft-record panacead query nft nft-records --class-id --owner ``` `nfts` and `nft-records` accept class, owner, or both filters. List queries are paginated and return at most 100 entries per page. # Ledger Nano Support Using a hardware wallet to store your keys improves the security of your assets. The [Ledger](https://www.ledger.com/) device acts as an enclave of the seed and private keys, and the process of signing transaction takes place within it. The following is a short tutorial on using the Panacea Ledger app with the Panacea CLI. ## Install the Panacea Ledger app Installing the `Panacea` app on your Ledger device is required before using the Panacea CLI. 1. Install [Ledger Live](https://www.ledger.com/ledger-live/) on your machine. 2. Using Ledger Live, update your Ledger Nano device with the latest firmware. 3. Navigate to the `Manager` menu on the Ledger Live. 4. Connect your Ledger Nano device and allow Ledger Manager from it. 5. On the Ledger Live, search for `Panacea` and install it. ## Panacea CLI + Ledger Nano Note: You need to [install the `Panacea` app](#install-the-panacea-ledger-app) on your Ledger Nano device before using following this section. ### Before you begin Install `panacead` by following the [guide](/guide/installation). ### Add your Ledger key * Connect and unlock your Ledger Nano device. * Open the `Panacea` app on your Ledger Nano device. * Create an account in `panacead` from your Ledger key. ```bash panacead keys add --ledger ``` Note: Be sure to change the `` parameter to be a meaningful name. The `--ledger` flag tells `panacead` to use your Ledger to seed the account. Panacea uses HD wallets. This means you can setup many accounts using the same Ledger seed. To create another account from your Ledger device, run the following command by changing the integer `` to some value >= 0 to choose the account for HD derivation. ```bash panacead keys add --ledger --account ``` ### Confirm your address Run the following command to display your address on the Ledger Nano device. Use the `` you gave your Ledger key. ```bash panacead keys show -d ``` Confirm that the address displayed on the Ledger Nano device matches that displayed when you added the key. ### Sign a transaction (Send funds) You are now ready to start signing and sending transactions. ```bash panacead tx bank send umed \ --node https://rpc.gopanacea.org \ --chain-id panacea-3 \ --fees 1000000umed ``` Be sure to set a proper full node address to the `--node` parameter. In the above example, one of the [Panacea Mainnet full nodes](https://github.com/medibloc/panacea-launch) was used. Also, the `--chain-id` must be set as `panacea-2` which is the current chain ID of the Panacea Mainnet. For `--fees`, please set `1000000umed` which is the approximate minimum in the current Mainnet network. You will be prompted to review and approve the transaction on your Ledger Nano device. Be sure to inspect the transaction displayed on the screen. ### Receive funds To receive funds to the Panacea account on your Ledger Nano device, retrieve the address for your Ledger Nano device (the ones with `type: ledger`) with this command: ```bash panacead keys list - name: type: ledger address: panacea1... ``` ### Support For further support, * # AOL The AOL(Append Only Log), which can store various useful data such as healthcare data, is the key feature of the Panacea blockchain. It allows user to manage topics, authorities, and data. ### Overview #### Create Topic ```go // MsgCreateTopic - create topics type MsgCreateTopic struct { TopicName string `json:"topic_name"` Description string `json:"description"` OwnerAddress sdk.AccAddress `json:"owner_address"` } ``` A `MsgCreateTopic` is constructed to facilitate the AOL topic. Message sender can set a topic and description. The writer can add record after receiving the appropriate privileges. Each field has limit. See the [Limits](#limits) section. #### Add Writer ```go // MsgAddWriter - add writer to the topic type MsgAddWriter struct { TopicName string `json:"topic_name"` Moniker string `json:"moniker"` Description string `json:"description"` WriterAddress sdk.AccAddress `json:"writer_address"` OwnerAddress sdk.AccAddress `json:"owner_address"` } ``` The owner of the exist topics can manage writer privileges. Writer who received privileges from the topic owner can add record to the topic. This means that the owner authenticate the writer. This `MsgAddWriter` performs a function similar to issuing a certificate. Each field has limit. See the [Limits](#limits) section. #### Delete Writer ```go // MsgDeleteWriter - delete writer from the topic type MsgDeleteWriter struct { TopicName string `json:"topic_name"` WriterAddress sdk.AccAddress `json:"writer_address"` OwnerAddress sdk.AccAddress `json:"owner_address"` } ``` This `MsgDeleteWriter` removes writer from the topic. It is impossible to add record to the topic after being deprived of authority. Each field has limit. See the [Limits](#limits) section. #### Add Record ```go // MsgAddRecord - add record to topic type MsgAddRecord struct { TopicName string `json:"topic_name"` Key []byte `json:"key"` Value []byte `json:"value"` WriterAddress sdk.AccAddress `json:"writer_address"` OwnerAddress sdk.AccAddress `json:"owner_address"` FeePayerAddress sdk.AccAddress `json:"fee_payer_address"` } ``` This `MsgAddRecord` add record or any data to the topic. If `FeePayerAddress` is provided, node charges fee to FeePayer. Each field has limit. See the [Limits](#limits) section. ### Limits | Field | Min Length | Max Length | Charset | | ------------- | ---------- | ---------- | ------------------------------------- | | `TopicName` | 1 | 70 | `a-z`, `A-Z`, `0-9`, `.`, `_` and `-` | | `Moniker` | 0 | 70 | `a-z`, `A-Z`, `0-9`, `.`, `_` and `-` | | `Description` | 0 | 5,000 | Any | | `Key` | 0 | 70 | Any | | `Value` | 0 | 5,000 | Any | # DID Please see the [Official Panacea DID Specification](https://github.com/medibloc/panacea-core/blob/master/docs/did.md). # NFT Panacea v2.3 provides a policy-aware NFT module built on the standard Cosmos SDK NFT data model. It replaces the legacy PNFT module with standard class, NFT, owner, supply, message, query, and event contracts plus Panacea lifecycle and policy records. ## Classes and policies A class ID is generated as `:`. Class metadata and the following policies are fixed when the class is created: * transfer policy: locked or owner-transferable; * whether the controller may revoke an NFT; * maximum lifetime supply, where zero means unlimited. The creator is the initial controller. The controller may be transferred to another non-module account, but the creator and class policies do not change. ## NFT lifecycle The class controller mints each NFT to a recipient. An NFT ID can only be used once within its class, including after burn. * `send` transfers an owner-transferable NFT between non-module accounts; * `revoke` irreversibly marks a revocable NFT as revoked without changing its owner or live supply; * `burn` permanently removes the standard NFT and records a tombstone containing its mint, optional revocation, and burn provenance. NFT metadata is immutable. The optional protobuf `Any` data field accepts only `/panacea.nft.v1.BasicNFTData`. ## Query APIs Panacea exposes both the standard `cosmos.nft.v1beta1.Query` service and the `panacea.nft.v1.Query` service. Standard queries return live standard NFT state. Panacea record queries additionally return policy, lifecycle, and permanent burn tombstone information. List queries require bounded pagination. The maximum page size is 100. ## Legacy PNFT compatibility The `panacea.pnft.v2` module, REST and gRPC queries, and `pnft` CLI commands are removed in v2.3. The legacy `pnft` store remains mounted as an inactive, permanently reserved tombstone so every node retains the same committed store topology. No module or keeper reads or writes this state, and it is not migrated to the new NFT stores. Historical PNFT protobuf message types remain registered only so old transactions and existing governance, group, or authorization records can be decoded and exported. Executing a legacy PNFT message after the upgrade fails; decode compatibility does not provide a PNFT runtime service. See [Interaction with the network: CLI](/guide/interaction-with-the-network-cli#nft) for current transaction and query commands. # Validator FAQ ## General Concepts ### What is a validator? The role of validators is to run a full-node and participate in consensus by broadcasting votes which contain cryptographic signatures. Validators commit new blocks and receive rewards in exchange for their work. They must also participate in governance by voting on proposals. Validators are weighted according to their total stake. ### What is 'staking'? The Panacea is a public Delegated Proof-Of-Stake (dPoS) blockchain, meaning that the weight of validators is determined by the amount of staking tokens (MED) bonded as collateral. These MEDs can be self-delegated directly by the validator or delegated to them by other MED holders. Any user in the system can declare their intention to become a validator by sending a `create-validator` transaction. Initially, only the top 50 validators with the most voting power will be active validators. ### What is a full-node? A full-node is a program that fully validates transactions and blocks of a blockchain. It is distinct from a light-node that only processes block headers and a small subset of transactions. Running a full-node requires more resources than a light-node but is necessary in order to be a validator. In practice, running a full-node only implies running a non-compromised and up-to-date version of the software with low network latency and without downtime. Of course, it is possible and encouraged for users to run full-nodes even if they do not plan to be validators. ### What is a delegator? Delegators are MED holders who cannot, or do not want to run a validator node themselves. MED holders can delegate MEDs to a validator and obtain a part of their revenue in exchange. Because they share revenue with their validators, delegators also share risks. Should a validator misbehave, each of their delegators will be partially slashed in proportion to their delegated stake. This is why delegators should perform due diligence on validators before delegating, as well as spreading their stake over multiple validators. Delegators play a critical role in the system, as they are responsible for choosing validators. Being a delegator is not a passive role. Delegators should actively monitor the actions of their validators and participate in governance. ## Becoming a Validator ### How to become a validator? Any participant in the network can signal that they want to become a validator by sending a `create-validator` transaction, where they must fill out the following parameters: [link](/guide/interaction-with-the-network-cli#staking). Once a validator is created, MED holders can delegate MEDs to them, effectively adding stake to their pool. The total stake of an address is the combination of MEDs bonded by delegators and MEDs self-bonded by the entity which designated themselves. Out of all validator candidates that signaled themselves, the 50 with the most total stake are the ones who are designated as validators. They become validators If a validator's total stake falls below the top 50 then that validator loses their validator privileges: they don't participate in consensus and generate rewards anymore. Over time, the maximum number of validators may be increased via on-chain governance proposal. ### What are the different states a validator can be in? After a validator is created with a `create-validator` transaction, they can be in three states: * `in validator set`: Validator is in the active set and participates in consensus. Validator is earning rewards and can be slashed for misbehaviour. * `jailed`: Validator misbehaved and is in jail, i.e. outside of the validator set. If the jailing is due to being offline for too long, the validator can send an `unjail` transaction in order to re-enter the validator set. If the jailing is due to double signing, the validator cannot unjail. * `unbonded`: Validator is not in the active set, and therefore not signing blocks. Validator cannot be slashed, and does not earn any reward. It is still possible to delegate MEDs to this validator. Un-delegating from an `unbonded` validator is immediate. ### What is 'self-delegation'? How can I increase my 'self-delegation'? Self-delegation is delegation from a validator to themselves. This amount can be increases by sending a delegate transaction from your validator's application key. For details about the application key, please see the [Key Types](/guide/interaction-with-the-network-cli#key-types) guide. ### Is there a minimum amount of MEDs that must be delegated to be an active (=bonded) validator? The minimum is `1 med`. ### How will delegators choose their validators? Delegators are free to choose validators according to their own subjective criteria. This said, criteria anticipated to be important include: * **Amount of self-delegated MEDs**: Number of MEDs a validator self-delegated to themselves. A validator with a higher amount of self-delegated MEDs has more skin in the game, making them more liable for their actions. * **Amount of delegated MEDs**: Total number of MEDs delegated to a validator. A high voting power shows that the community trusts this validator, but it also means that this validator is a bigger target for hackers. Bigger validators also decrease the decentralisation of the network. * **Commission rate**: Commission applied on revenue by validators before it is distributed to their delegators. * **Track record**: Delegators will likely look at the track record of the validators they plan to delegate to. This includes seniority, past votes on proposals, historical average uptime and how often the node was compromised. ## Responsibilities ### Do validators need to be publicly identified? No, they do not. Each delegator will value validators based on their own criteria. Validators will be able to register a website address when they nominate themselves so that they can advertise their operation as they see fit. Some delegators may prefer a website that clearly displays the team operating the validator and their resume, while others might prefer anonymous validators with positive track records. ### What are the responsibilities of a validator? Validators have two main responsibilities: * **Be able to constantly run a correct version of the software**: Validators need to make sure that their servers are always online, and their private keys are not compromised. * **Actively participate in governance**: Validators are required to vote on every proposal. ### What does 'participate in governance' entail? Validators and delegators can vote on proposals to change operational parameters (such as the block gas limit), coordinate upgrades, or make a decision on any given matter. Validators play a special role in the governance system. Being the pillars of the system, they are required to vote on every proposal. It is especially important since delegators who do not vote will inherit the vote of their validator. ### What does staking imply? Staking MEDs can be thought of as a safety deposit on validation activities. When a validator or a delegator wants to retrieve part or all of their deposit, they send an `unbonding` transaction. Then, MEDs undergo a 3 weeks unbonding period during which they are liable to being slashed for potential misbehavior committed by the validator before the unbonding process started. Validators, and by association delegators, receive block rewards, fees, and have the right to participate in governance. If a validator misbehaves, a certain portion of their total stake is slashed. This means that every delegator that bonded MEDs to this validator gets penalized in proportion to their bonded stake. Delegators are therefore incentivized to delegate to validators that they anticipate will function safely. ### Can a validator run away with their delegators' MEDs? By delegating to a validator, a user delegates voting power. The more voting power a validator have, the more weight they have in the consensus and governance processes. This does not mean that the validator has custody of their delegators' MEDs. **By no means can a validator run away with its delegator's funds**. Even though delegated funds cannot be stolen by their validators, delegators are still liable if their validators misbehave. ### How often will a validator be chosen to propose the next block? Does it go up with the quantity of bonded MEDs? The validator that is selected to propose the next block is called proposer. Each proposer is selected deterministically, and the frequency of being chosen is proportional to the voting power of the validator. For example, if the total bonded stake across all validators is 100 MEDs and a validator's total stake is 10 MEDs, then this validator will proposer \~10% of the blocks. ## Incentives ### What is the incentive to stake? Each member of a validator's staking pool earns different types of revenue: * **Block rewards**: Native tokens of applications run by validators (e.g. MEDs on the Panacea) are inflated to produce block provisions. These provisions exist to incentivize MED holders to bond their stake, as non-bonded MED will be diluted over time. * **Transaction fees**: The Panacea maintains a whitelist of token that are accepted as fee payment. The initial fee token is the MED. This total revenue is divided among validators' staking pools according to each validator's weight. Then, within each validator's staking pool the revenue is divided among delegators in proportion to each delegator's stake. A commission on delegators' revenue is applied by the validator before it is distributed. ### What is the incentive to run a validator? Validators earn proportionally more revenue than their delegators because of commissions. Validators also play a major role in governance. If a delegator does not vote, they inherit the vote from their validator. This gives validators a major responsibility in the ecosystem. ### What are validators commission? Revenue received by a validator's pool is split between the validator and their delegators. The validator can apply a commission on the part of the revenue that goes to their delegators. This commission is set as a percentage. Each validator is free to set their initial commission, maximum daily commission change rate and maximum commission. The Panacea enforces the parameter that each validator sets. Only the commission rate can change after the validator is created. ### How are block rewards distributed? Block rewards are distributed proportionally to all validators relative to their voting power. This means that even though each validator gains MEDs with each reward, all validators will maintain equal weight over time. Let us take an example where we have 10 validators with equal voting power and a commission rate of 10%. Let us also assume that the reward for a block is 1000 MEDs and that each validator has 20% of self-bonded MEDs. These tokens do not go directly to the proposer. Instead, they are evenly spread among validators. So now each validator's pool has 100 MEDs. These 100 MEDs will be distributed according to each participant's stake: * Commission: `100 * 80% * 10% = 8 MEDs` * Validator gets: `100 * 20% + Commission = 28 MEDs` * All delegators get: `100 * 80% - Commission = 72 MEDs` Then, each delegator can claim their part of the 72 MEDs in proportion to their stake in the validator's staking pool. ### How are fees distributed? Fees are similarly distributed with the exception that the block proposer can get a bonus on the fees of the block they propose if they include more than the strict minimum of required precommits. When a validator is selected to propose the next block, they must include at least 2/3 precommits of the previous block. However, there is an incentive to include more than 2/3 precommits in the form of a bonus. The bonus is linear: it ranges from 1% if the proposer includes 2/3rd precommits (minimum for the block to be valid) to 5% if the proposer includes 100% precommits. Of course the proposer should not wait too long or other validators may timeout and move on to the next proposer. As such, validators have to find a balance between wait-time to get the most signatures and risk of losing out on proposing the next block. This mechanism aims to incentivize non-empty block proposals, better networking between validators as well as to mitigate censorship. Let's take a concrete example to illustrate the aforementioned concept. In this example, there are 10 validators with equal stake. Each of them applies a 10% commission rate and has 20% of self-delegated MEDs. Now comes a successful block that collects a total of 1025.51020408 MED in fees. First, a 2% tax is applied. The corresponding MED go to the reserved community pool. The community pool's funds can be allocated through governance. * `2% * 1025.51020408` = 20.51020408 MED go to the community pool 1005 MED now remain to be distributed to validators and delegators. Let's assume that the proposer included 100% of the signatures in its block. It thus obtains the full bonus of 5%. We have to solve this simple equation to find the reward `R` for each validator: ``` 9*R + R + R*5% = 1005 R = 1005/10.05 = 100 ``` * For the proposer validator: * The pool obtains `R + R * 5%`: 105 MED * Commission: `105 * 80% * 10%` = 8.4 MED * Validator's reward: `105 * 20% + Commission` = 29.4 MED * Delegators' rewards: `105 * 80% - Commission` = 75.6 MED (each delegator will be able to claim its portion of these rewards in proportion to their stake) * For each non-proposer validator: * The pool obtains `R`: 100 MED * Commission: `100 * 80% * 10%` = 8 MED * Validator's reward: `100 * 20% + Commission` = 28 MED * Delegators' rewards: `100 * 80% - Commission` = 72 MED (each delegator will be able to claim their portion of these rewards in proportion to their stake) ### What are the slashing conditions? If a validator misbehaves, their delegated stake will be partially slashed. There are currently two faults that can result in slashing of funds for a validator and their delegators: * **Double signing**: If someone reports on chain A that a validator signed two blocks at the same height on chain A and chain B, and if chain A and chain B share a common ancestor, then this validator will get slashed by 5% on chain A. * **Downtime**: If a validator misses more than 95% of the last 10,000 blocks, they will get slashed by 0.01%. ## Technical Requirements ### What are hardware requirements? Validators should expect to provision one or more data center locations with redundant power, networking, firewalls, HSMs and servers. We expect that a modest level of hardware specifications will be needed initially and that they might rise as network use increases. For details, please see the [Join the Network](/guide/join-the-network) guide. ### What are software requirements? In addition to running a Panacea node, validators should develop monitoring, alerting and management solutions. ### What are bandwidth requirements? The Panacea network has the capacity for very high throughput relative to chains like Ethereum or Bitcoin. We recommend that the data center nodes only connect to trusted full-nodes in the cloud or other validators that know each other socially. This relieves the data center node from the burden of mitigating denial-of-service attacks. Ultimately, as the network becomes more heavily used, multi-gigabyte per day bandwidth is very realistic. ### What does running a validator imply in terms of logistics? A successful validator operation will require the efforts of multiple highly skilled individuals and continuous operational attention. This will be considerably more involved than running a bitcoin miner for instance. ### How to handle key management? Validators should expect to run an HSM that supports ed25519 keys. Here are potential options: * YubiHSM 2 * Ledger Nano S * Ledger BOLOS SGX enclave * Thales nShield support The Tendermint team does not recommend one solution above the other. The community is encouraged to bolster the effort to improve HSMs and the security of key management. ### What can validators expect in terms of operations? Running effective operation is the key to avoiding unexpectedly unbonding or being slashed. This includes being able to respond to attacks, outages, as well as to maintain security and isolation in your data center. ### What are the maintenance requirements? Validators should expect to perform regular software updates to accommodate upgrades and bug fixes. There will inevitably be issues with the network early in its bootstrapping phase that will require substantial vigilance. ### How can validators protect themselves from denial-of-service attacks? Denial-of-service attacks occur when an attacker sends a flood of internet traffic to an IP address to prevent the server at the IP address from connecting to the internet. An attacker scans the network, tries to learn the IP address of various validator nodes and disconnect them from communication by flooding them with traffic. One recommended way to mitigate these risks is for validators to carefully structure their network topology in a so-called sentry node architecture. Validator nodes should only connect to full-nodes they trust because they operate them themselves or are run by other validators they know socially. A validator node will typically run in a data center. Most data centers provide direct links the networks of major cloud providers. The validator can use those links to connect to sentry nodes in the cloud. This shifts the burden of denial-of-service from the validator's node directly to its sentry nodes, and may require new sentry nodes be spun up or activated to mitigate attacks on existing ones. Sentry nodes can be quickly spun up or change their IP addresses. Because the links to the sentry nodes are in private IP space, an internet based attacked cannot disturb them directly. This will ensure validator block proposals and votes always make it to the rest of the network. It is expected that good operating procedures on that part of validators will completely mitigate these threats. For more on sentry node architecture, see [this](https://docs.tendermint.com/master/nodes/validators.html#setting-up-a-validator). # Introduction Welcome to the Panacea Core docs. * Features covers what you can do with the Panacea Core, and gives a high level intuition of its core mechanisms. * Guide offers setup instructions on how to setup a node, join existing networks. * Specifications contains detailed specifications for each module in the Panacea Core. # Tech Stack ![](https://3260386777-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ll1df1rXsjkx78wC8Rs-887967055%2Fuploads%2Fgit-blob-ca5153f9709edb009107e88631299ff677b46e0b%2Ftech-stack.png?alt=media) ## The benefit from Cosmos SDK and Tendermint The Panacea is a public blockchain based on the Cosmos SDK and the Tendermint. As the Tendermint implements a partially synchronous BFT (Byzantine fault-tolerant) consensus protocol, Panacea can provide a high-performance, consistent and secure decentralized network where strict fork-accountability guarantees hold over the behavior of malicious actors. On the top of that, the Cosmos SDK implements DPoS (Delegated Proof of Stake) model and provides various cryptographic operations such as tokens, governance and IBC (Inter-Blockchain Communication). Panacea inherits all of their strengths without reinventing the wheel. It means that Panacea can guarantee the fast finality and the solid network security and can be connected with them without any compatibility/safety issues. Based on the model of the Cosmos SDK and the Tendermint, new features have been added to Panacea for building the patient-centered health data ecosystem. We will cover details of each feature in next chapters. ## DID (Decentralized Identifier) ![](https://3260386777-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ll1df1rXsjkx78wC8Rs-887967055%2Fuploads%2Fgit-blob-8b522047384a819be7bd4e786a78238ca83894f6%2Fdid-vc.png?alt=media) Panacea provides a DID method which conforms to the specification of W3C (World Wide Web Consortium), so that users can verify their identity or the integrity of their data without relying on any third-party authorities. Anyone can create, update and deactivate DIDs on Panacea that guarantees the integrity of DID-related cryptographic data including DID public keys. The core usage of DID in the health data ecosystem is signing on the health data that needs to be shared to any parties that want to verify whether the data is forgery or not. As the mechanism of signing on data using DID and verifying signatures has been standardized by W3C, anyone can easily use the Panacea DID without any compatibility issue. Also, data holders can reveal only data that they really want to share using the DID-based ZKP(Zero-knowledge Proof). This mechanism is so essential for the health data ecosystem because patients can keep the ownership of their health data and choose the level of privacy by themselves. ## IBC (Inter-Blockchain Communication) Since Panacea is a Cosmos-based blockchain, it can be connected with other Cosmos-based blockchains through the IBC protocol. Also, bridges for non-Cosmos-based chains such as Bitcoin and Ethereum have being actively implemented by various participants in the Cosmos ecosystem. Of course, Panacea is going to be integrated with those inter-chain protocols for enabling more people to benefit from the Panacea-based health data ecosystem. # Getting started This section will guide the reader to install, deploy, and interact with the Panacea blockchain.‌ ### Table of contents * **Installation**: Instructions on how to install *panacead*, the server daemon for nodes, the cli tool to interact with panacead. * **How to Join the network**: Panacea is the first official public network running the Panacea Blockchain. This section outlines step by step instructions on how to start operating a node on Panacea. * **How to deploy own Panacea testnet**: How to setup and deploy one's own testnet of the Panacea blockchain, in a single-node local, multi-node local, and remote network context. * **Introduction to panacead**: Using the `panacead` to interact with the Panacea blockchain. * **Clients**: How to spin up a light client daemon, that stores partial state and responds to REST API queries. * **Use the Ledger Nano**: How to interact with the Panacea blockchain using the Ledger Nano S. # Installation ## Install Go [Go 1.19+](https://golang.org/doc/install) is required. ## Install the `panacead` If you want to install the `panacead` binary to run your node or to communicate with other nodes, please clone the `panacea-core` project and build it. ```bash # Make sure to checkout the correct branch. git clone -b v2.0.7-2 https://github.com/medibloc/panacea-core cd panacea-core make install # All binaries are installed in $GOPATH/bin ``` Verify that the `panacead` binary is installed successfully. ```bash $ panacead version 2.0.6 ``` ## Import `panacea-core` as a Go dependency If you want to develop Go applications by importing the `panacea-core`, you cannot run `go get github.com/medibloc/panacea-core/v2` directly due to [the design of Go Modules](https://github.com/golang/go/issues/30354) , which doesn't honor `replace` directives in the `go.mod` of the `panacea-core`. As a workaround, please add `replace` directives in your `go.mod` as below. ``` module your.com/yours go 1.19 replace ( github.com/cosmos/cosmos-sdk => github.com/medibloc/cosmos-sdk v0.45.12-panacea.1 github.com/gogo/protobuf => github.com/regen-network/protobuf v1.3.3-alpha.regen.1 github.com/tendermint/tendermint => github.com/informalsystems/tendermint v0.34.24 google.golang.org/grpc => google.golang.org/grpc v1.33.2 ) ``` Then, you can `go get` the `panacea-core`. ```bash go get github.com/medibloc/panacea-core/v2 ``` # Join the Network This tutorial introduces deploying a new node on [AWS](https://aws.amazon.com/) and join the Panacea Mainnet. ## Launch an AWS EC2 Instance ### Choose an AMI Choose Ubuntu Server 20.04 LTS 64-bit (x86) with SSD Volume Type. ![](https://3260386777-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ll1df1rXsjkx78wC8Rs-887967055%2Fuploads%2Fgit-blob-46709c161eb073bb9357601b92a712c973619295%2Fec2-ami.png?alt=media) ### Choose the instance type Choose the `m5.large` instance type (minimum spec). ![](https://3260386777-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ll1df1rXsjkx78wC8Rs-887967055%2Fuploads%2Fgit-blob-5f92125c86655b3088f71ff0c8c6229868bcba0e%2Fec2-instance-type.png?alt=media) ### Configure instance details | Configuration | Value | | --------------------- | ----------------------------------------------------------------- | | Network | Choose an existing VPC or default one if you don't have any | | Subnet | Choose an existing subnet or default one if you don't have any | | Auto-assign Public IP | Enable only if you access a full node from the outside of its VPC | | Other fields | Follow default settings | ### Add a storage | Configuration | Value | | ------------- | --------------------------- | | Size | 500 GiB | | Volume Type | `General Purpose SSD (gp3)` | | IOPS | 3000 | | Throughput | 125 MB/s | ### Configure a Security Group | Type | Protocol | Port range | Description | | ---------- | -------- | ---------- | -------------------- | | SSH | TCP | 22 | | | Custom TCP | TCP | 26656 | P2P with other nodes | | Custom TCP | TCP | 26657 | RPC | | Custom TCP | TCP | 1317 | HTTP | The P2P `26656` port must be exposed to other Panacea nodes. If your node will be in the VPC guarded by Sentry nodes, expose `26656` to only Sentry nodes (recommended). If not, expose it to anywhere. For details about Sentry nodes, please see the [Tendermint guide](https://docs.tendermint.com/master/nodes/validators.html#local-configuration). The RPC `26657` and HTTP `1317` ports are for sending transactions/queries to your node. So, expose them to the network where you perform operational actions. ### Connect to your EC2 instance and install prerequisites. ```bash ssh ubuntu@ -i .pem ``` Install prerequisites by following the [Installation](/v2.0/guide/installation) guide. ## Setup a New Node These instructions are for setting up a brand new full node from scratch. First, initialize the node and create the necessary config files: ```bash panacead init ``` {% hint style="warning" %} The `moniker` can contains only ASCII characters. Using Unicode characters will render your node unreachable. {% endhint %} Then, modify the `timeout_commit` in the `~/.panacead/config/config.toml` as below. ```toml [consensus] timeout_commit = "5s" ``` After that, edit the `~/.panacead/config/app.toml` file in order to enable the anti-spam mechanism and reject incoming transactions with less than the `minimum-gas-prices`: ```toml # Validators reject any tx from the mempool with less than the minimum-gas-prices. minimum-gas-prices = "5umed" # NOTE: For the Testnet, please set minimum-gas-prices as "", so that no fee is required. ``` Now, your full node has been initialized! ### Copy the Genesis file Fetch the `genesis.json` file of the latest chain from the following links, and place it to `~/.panacead/config/genesis.json`. * Mainnet: * Testnet: ### Configure Seed Nodes Your node needs to know how to find peers. Seed nodes can be found in: * Mainnet: * Testnet: Insert those `@`s with 26656 port to the `persistent_peers` field in `~/.panacead/config/config.toml`. ```toml # Comma separated list of nodes to keep persistent connections to persistent_peers = "8c41cc8a6fc59f05138ae6c16a9eec05d601ef71@13.209.177.91:26656,cc0285c4d9cec8489f8bfed0a749dd8636406a0d@54.180.169.37:26656,1fc4a41660986ee22106445b67444ec094221e76@52.78.132.151:26656" ``` For more information on seeds and peers, see the [Using Tendermint: Peers](https://docs.tendermint.com/master/tendermint-core/using-tendermint.html#peers). ### State Sync Your node can rapidly sync with the network using state sync without replaying historical blocks. For more details, please refer to [this](https://docs.tendermint.com/v0.34/tendermint-core/state-sync.html). To set state sync enabled, RPC servers and trusted block info (height and hash) are required. You can use the following public RPC endpoints provided by Medibloc team. * 3.35.82.40:26657 * 13.124.96.254:26657 * 52.79.108.35:26657 trusted block info can be obtained via RPC. ```shell curl -s 13.124.96.254:26657/block | jq -r '.result.block.header.height + "\n" + .result.block_id.hash' # 7700000 (height) # 0D3E53F02ABCDDA8AAC1520342D37A290DDABE4C28190EE6E2C6B0C819F74D4A (hash) ``` Then, you need to edit several things in `~/.panacea/config/config.toml` file. ```toml [statesync] enable = true rpc_servers = "3.35.82.40:26657,13.124.96.254:26657,52.79.108.35:26657" # rpc addresses trust_height = trust_hash = "" trust_period = "336h0m0s" # 2/3 of 21 days (unbonding period) ``` If your node have block history data previously synced, you need to clear the data first. ```shell panacead tendermint unsafe-reset-all ``` ## Run a Full Node Start the full node with this command: ```bash panacead start ``` Check that everything is running smoothly: ```bash panacead status ``` View the status of the network with the Block Explorer * Mainnet: * Testnet: ~~~~ ## Join as a validator If you want to participate in validating blocks as a validator, you can register yourself into the validator set by submitting a transaction. For more details, see the [CLI guide](/v2.0/guide/interaction-with-the-network-cli#staking). # Deploy a Testnet This document describes 2 ways to setup a network of `panacead` nodes. 1. [Using multiple machines](#using-multiple-machines) 2. [Using a single machine (using Docker)](#using-a-single-machine-using-docker) ## Using multiple machines ### Deploy the first node ```bash # Initialize the genesis.json file that will help you to bootstrap the network panacead init node1 --chain-id=testing # Create a key to hold your validator account panacead keys add validator # Add that key into the genesis.app_state.accounts array in the genesis file # NOTE: this command lets you set the number of coins. Make sure this account has some coins # with the genesis.app_state.staking.params.bond_denom denom. panacead add-genesis-account $(panacead keys show validator -a) 100000000000000umed # Generate the transaction that creates your validator panacead gentx validator 1000000000000umed --commission-rate 0.1 --commission-max-rate 0.2 --commission-max-change-rate 0.01 --min-self-delegation 1000000 --chain-id testing # Add the generated bonding transaction to the genesis file panacead collect-gentxs # Now its safe to start `panacead` panacead start ``` This setup puts all the data for `panacead` in `~/.panacea`. You can examine the genesis file that you created at `~/.panacea/config/genesis.json`. ### Deploy the second node Init the second node using another moniker: `node2`. ```bash panacead init node2 --chain-id=testing ``` Overwrite `~/.panacea/config/genesis.json` with the first node's `genesis.json`. Get a node ID of the first node. ```bash panacead tendermint show-node-id > 46046c89ec576daa0662613ee0142ab61dd2421e ``` Set a `persistent_peers` in the `~/.panacea/config/config.toml` of the second node. ```toml # Comma separated list of nodes to keep persistent connections to persistent_peers = "@:26656" ``` Start the second node. ```bash panacead start ``` # Interaction with the network: CLI For more information on the command usage, refer to its help screen: `panacead --help`. Here is a list of useful `panacead` commands, including usage examples. ## Keys ### Key Types There are three types of key representations that are used: * `panacea` * Derived from account keys generated by `panacead keys add` * Used to receive funds * e.g. `panacea17kmacx3czkdnhtfueqzzxk9xqzapj453f23m5a` * `panaceavaloper` * Used to associate a validator to it's operator * Used to invoke staking commands * e.g. `panaceavaloper17kmacx3czkdnhtfueqzzxk9xqzapj453wg3mgr` * `panaceapub` * Derived from account keys generated by `panacead keys add` * e.g. `panaceapub1addwnpepqwk3j2j3knuyah89skh8wtn5kr4qx32nhql6hzjadzmre2xlfmvxgy39ln8` * `panaceavalconspub` * Generated when the node is created with `panacead init`. * Get this value with `panacead tendermint show-validator` * e.g. `panaceavalconspub1zcjduepqktkqqsl9rchj77v9vg0crc87grp9h2u5ggpdtvcq74kxlr29lgwsa3dr66` ### Generate Keys You'll need an account private and public key pair (a.k.a. `sk, pk` respectively) to be able to receive funds, send txs, bond tx, etc. To generate a new *secp256k1* key: ```bash panacead keys add ``` Previously, you had to enter a password to save it to disk, but you do not currently need to. [Setting up the keyring](https://docs.cosmos.network/v0.42/run-node/keyring.html) If you check your private keys, you'll now see ``: ```bash panacead keys show ``` View the validator operator's address via: ```bash panacead keys show --bech=val ``` You can see all your available keys by typing: ```bash panacead keys list ``` View the validator pubkey for your node by typing: ```bash panacead tendermint show-validator ``` Note that this is the Tendermint signing key, *not* the operator key you will use in delegation transactions. ::: danger Warning We strongly recommend *NOT* using the same passphrase for multiple keys. The MediBloc team will not be responsible for the loss of funds. ::: ## Fees & Gas Each transaction may either supply fees or gas prices, but not both. Most users will typically provide fees as this is the cost you will end up incurring for the transaction being included in the ledger. Validator's have a minimum gas price configuration and they use this value when determining if they should include the transaction in a block during `CheckTx`, where `gasPrices >= minGasPrices`. Note, your transaction must supply fees that are greater than or equal to minimum fee which the validator requires. **Note**: With such a mechanism in place, validators may start to prioritize txs by `gasPrice` in the mempool, so providing higher fees or gas prices may yield higher tx priority. e.g. ```bash panacead tx send ... --fees=1000000umed ``` or ```bash panacead tx send ... --gas-prices=500.0umed ``` ## Account ### Query Account To view your account information: ```bash panacead query account ``` ## Bank ### Query balance After receiving tokens to your address, you can view your account's balance by typing: ```bash panacead query bank balances ``` ::: warning Note When you query an account balance with zero tokens, you will get this error: `account does not exist.` This can also happen if you fund the account before your node has fully synced with the chain. These are both normal.::: ## Send Tokens The following command could be used to send coins from one account to another: ```bash panacead tx bank send \ \ \ \ --chain-id \ ``` where `to_address` is a key matching the format: `panacea1y3mhszahwatjc3023datq46a0u2fv337tes4n9` ::: warning Note The `` accepts the format ` -> ex) 10000000umed`. ::: ::: tip Note You may want to cap the maximum gas that can be consumed by the transaction via the `--gas` flag. If you pass `--gas=auto`, the gas supply will be automatically estimated before executing the transaction. Gas estimate might be inaccurate as state changes could occur in between the end of the simulation and the actual execution of a transaction, thus an adjustment is applied on top of the original estimate in order to ensure the transaction is broadcasted successfully. The adjustment can be controlled via the `--gas-adjustment` flag, whose default value is 1.0. ::: Now, view the updated balances of the origin and destination accounts: ```bash panacead query bank balances panacead query bank balances ``` You can also check your balance at a given block by using the `--height` flag: ```bash panacead query account --height= ``` You can simulate a transaction without actually broadcasting it by appending the `--dry-run` flag to the command line: ```bash panacead tx bank send \ \ \ \ --chain-id \ --dry-run ``` Furthermore, you can build a transaction and print its JSON format to STDOUT by appending `--generate-only` to the list of the command line arguments: ```bash panacead tx bank send \ \ \ \ --chain-id \ --generate-only > unsignedSendTx.json ``` ```bash panacead tx sign \ --chain-id \ --from \ unsignedSendTx.json > signedSendTx.json ``` You can validate the transaction's signatures by typing the following: ```bash panacead tx validate-signatures \ --chain-id \ signedSendTx.json ``` You can broadcast the signed transaction to a node by providing the JSON file to the following command: ```bash panacead tx broadcast --chain-id signedSendTx.json ``` ## Query Transactions ### Matching a set of events You can use the transaction search command to query for transactions that match a specific set of `events`, which are added on every transaction. Events are implemented in the Cosmos SDK as an alias of the ABCI `Event` type and take the form of: `{eventType}.{attributeKey}={attributeValue}`. Events can also be combined to query for a more specific result using the `&` symbol. The command for querying transactions using a `event` is the following: ```bash panacead query txs --events 'message.module=bank' ``` And for using multiple `events`: ```bash panacead query txs --events 'message.module=bank&tx.height=5' ``` The pagination is supported as well via `page` and `limit`: ```bash panacead query txs --events 'message.module=bank' --page 1 --limit 20 ``` ::: tip Note The action tag always equals the message type returned by the `Type()` function of the relevant message. You can find a list of available `tags` on each module by looking at the /tags directory of each module. ::: ### Matching a transaction's hash You can also query a single transaction by its hash using the following command: ```bash panacead query tx [hash] ``` ## Slashing ### Unjailing To unjail your jailed validator ```bash panacead tx slashing unjail \ --from \ --chain-id ``` ### Signing Info To retrieve a validator's signing info: ```bash panacead query slashing signing-info ``` ### Query Parameters You can get the current slashing parameters via: ```bash panacead query slashing params ``` ## Staking ### Create your validator {% hint style="info" %} This guide assumes that you have already set up your full node by following [the guide](/v2.0/guide/join-the-network). {% endhint %} Your `panaceavalconspub` address (public key) can be used to create a new validator by staking tokens. You can find your validator public key by: ```bash panacead tendermint show-validator ``` Execute the following command to create your validator: {% hint style="warning" %} Don't use more `umed` than you have! {% endhint %} ```bash panacead tx staking create-validator \ --pubkey $(panacead tendermint show-validator) \ --moniker "choose a moniker" \ --chain-id \ --commission-rate "0.10" \ --commission-max-rate "0.20" \ --commission-max-change-rate "0.01" \ --min-self-delegation "1" \ --amount 10000000umed \ --fees "1000000umed" \ --from ``` * `pubkey`: A public key associated with the Tendermint private key (which was generated by `panacead init`). The public key can be resolved by `panacead tendermint show-validator` in the node that you want to make as a validator. For details about various key types, please see this [guide](#keys). * `moniker`: A validator nickname that will be displayed publicly * `commission-rate`: An initial commission rate on block rewards and fees charged to delegators * This shouldn't be smaller than the minimum commission rate (a genesis parameter) that can be queried by `panacead query staking params`. * `commission-max-rate`: A maximum commission rate which this validator can charge. This cannot be changed after the `create-validator` transaction is processed. * `commission-max-change-rate`: A maximum daily increase of the validator commission. This cannot be changed after the `create-validator` transaction is processed. This is used to measure % point change over the `commision-rate`. E.g. 1% to 2% is a 100% rate increase, but only 1% point. * `min-self-delegation`: A strictly positive integer in `umed` that represents the minimum amount of self-delegated voting power your validator must always have. If the validator's self-delegated stake falls below this limit, their entire staking pool will unbond. * `amount`: An amount of your self-delegation **Note:** A minimum amount of MEDs that must be delegated to be an active validator is `1med` (`1000000umed`). In other words, validators cannot be in the active set, if their total stake (= self-bonded stake + delegators stake) is under `1med`. You can confirm that you are in the validator set by the following command: ```bash panacead query staking validators ``` ### Edit validator description You can edit your validator's public description. This info is to identify your validator, and will be relied on by delegators to decide which validators to stake to. Make sure to provide input for every flag below. If a flag is not included in the command the field will default to empty (`--moniker` defaults to the machine name) if the field has never been set or remain the same if it has been set in the past. The `--from` option specifies which validator you are editing. ```bash panacead tx staking edit-validator \ --moniker "choose a new moniker" \ --website "https://example.com" \ --details "This is a detail description" \ --chain-id \ --commission-rate "0.15" \ --from \ --fees "1000000umed" ``` **Note**: The `--commission-rate` value must adhere to the following invariants: * Must be between the minimum commission rate (a genesis parameter) and the validator's `commission-max-rate` * Must not exceed the validator's `commission-max-change-rate` which is maximum % point change rate **per day**. In other words, a validator can only change its commission once per day and within `commission-max-change-rate` bounds. ### Delegate to a Validator You can delegate `umed` to a validator. These delegators can receive part of the validator's fee revenue. **Query Validators** You can query the list of all validators of a specific chain: ```bash panacead query staking validators ``` If you want to get the information of a single validator you can check it with: ```bash panacead query staking validator ``` ### Bond Tokens Here's how you can bond tokens to a validator (*i.e.* delegate): ```bash panacead tx staking delegate \ \ 10000000umed \ --from \ --chain-id ``` `` is the operator address of the validator to which you intend to delegate. If you are running a local testnet, you can find this with: ```bash panacead keys show [name] --bech val ``` where `[name]` is the name of the key you specified when you initialized `panacead`. While tokens are bonded, they are pooled with all the other bonded tokens in the network. Validators and delegators obtain a percentage of shares that equal their stake in this pool. **Query Delegations** Once submitted a delegation to a validator, you can see it's information by using the following command: ```bash panacead query staking delegation ``` Or if you want to check all your current delegations with distinct validators: ```bash panacead query staking delegations ``` You can also get previous delegation(s) status by adding the `--height` flag. ### Unbond Tokens If for any reason the validator misbehaves, or you just want to unbond a certain amount of tokens, use this following command. ```bash panacead tx staking unbond \ \ 10000umed \ --from \ --chain-id ``` The unbonding will be automatically completed when the unbonding period has passed. **Query Unbonding-Delegations** Once you begin an unbonding-delegation, you can see it's information by using the following command: ```bash panacead query staking unbonding-delegation ``` Or if you want to check all your current unbonding-delegations with disctinct validators: ```bash panacead query staking unbonding-delegations ``` Additionally, as you can get all the unbonding-delegations from a particular validator: ```bash panacead query staking unbonding-delegations-from ``` To get previous unbonding-delegation(s) status on past blocks, try adding the `--height` flag. ### Redelegate Tokens A redelegation is a type delegation that allows you to bond illiquid tokens from one validator to another: ```bash panacead tx staking redelegate \ \ \ 10000umed \ --from \ --chain-id ``` The redelegation will be automatically completed when the unbonding period has passed. **Query Redelegations** Once you begin an redelegation, you can see it's information by using the following command: ```bash panacead query staking redelegation ``` Or if you want to check all your current unbonding-delegations with disctinct validators: ```bash panacead query staking redelegations ``` Additionally, as you can get all the outgoing redelegations from a particular validator: ```bash panacead query staking redelegations-from ``` To get previous redelegation(s) status on past blocks, try adding the `--height` flag. ### Query Parameters Parameters define high level settings for staking. You can get the current values by using: ```bash panacead query staking params ``` With the above command you will get the values for: * Unbonding time * Maximum numbers of validators * Maximum entries * Coin denomination for staking ### Query Pool A staking `Pool` defines the dynamic parameters of the current state. You can query them with the following command: ```bash panacead query staking pool ``` With the `pool` command you will get the values for: * Not-bonded and bonded tokens ## Fee Distribution ### Query distribution parameters To check the current distribution parameters, run: ```bash panacead query distribution params ``` ### Query validator commission To check the current outstanding commission for a validator, run: ```bash panacead query distribution commission ``` ### Query validator slashes To check historical slashes for a validator, run: ```bash panacead query distribution slashes ``` ### Query delegator rewards To check current rewards for a delegation (were they to be withdrawn), run: ```bash panacead query distribution rewards ``` ### Query all delegator rewards To check all current rewards for a delegation (were they to be withdrawn), run: ```bash panacead query distribution rewards ``` ## Multisig transactions Multisig transactions require signatures of multiple private keys. Thus, generating and signing a transaction from a multisig account involve cooperation among the parties involved. A multisig transaction can be initiated by any of the key holders, and at least one of them would need to import other parties' public keys into their Keybase and generate a multisig public key in order to finalize and broadcast the transaction. For example, given a multisig key comprising the keys `p1`, `p2`, and `p3`, each of which is held by a distinct party, the user holding `p1` would require to import both `p2` and `p3` in order to generate the multisig account public key: ``` panacead keys add \ p2 \ --pubkey '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"AhExixh..."}' panacead keys add \ p3 \ --pubkey '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"A3ntuPW..."}' panacead keys add \ p1p2p3 \ --multisig-threshold 2 \ --multisig p1,p2,p3 ``` A new multisig public key `p1p2p3` has been stored, and its address will be used as signer of multisig transactions: ```bash panacead keys show --address p1p2p3 ``` You may also view multisig threshold, pubkey constituents and respective weights by viewing the JSON output of the key or passing the `--show-multisig` flag: ```bash panacead keys show p1p2p3 --output json ``` The first step to create a multisig transaction is to initiate it on behalf of the multisig address created above: ```bash panacead tx bank send 10umed \ --from \ --chain-id \ --generate-only > unsignedTx.json ``` The file `unsignedTx.json` contains the unsigned transaction encoded in JSON. `p1` can now sign the transaction with its own private key: ```bash panacead tx sign \ unsignedTx.json \ --multisig \ --from p1 \ --output-document p1signature.json \ --chain-id ``` Once the signature is generated, `p1` transmits both `unsignedTx.json` and `p1signature.json` to `p2` or `p3`, which in turn will generate their respective signature: ```bash panacead tx sign \ unsignedTx.json \ --multisig \ --from p2 \ --output-document p2signature.json \ --chain-id ``` `p1p2p3` is a 2-of-3 multisig key, therefore one additional signature is sufficient. Any the key holders can now generate the multisig transaction by combining the required signature files: ```bash panacead tx multisign \ unsignedTx.json \ p1p2p3 \ p1signature.json p2signature.json \ --output-document signedTx.json \ --chain-id ``` The transaction can now be sent to the node: ```bash panacead tx broadcast signedTx.json \ --chain-id ``` ## Shells completion scripts Completion scripts for popular UNIX shell interpreters such as `Bash` and `Zsh` can be generated through the `completion` command, which is available for both `panacead`. If you want to generate `Bash` completion scripts run the following command: ```bash panacead completion > panacead_completion ``` If you want to generate `Zsh` completion scripts run the following command: ```bash panacead completion --zsh > panacead_completion ``` ::: tip Note On most UNIX systems, such scripts may be loaded in `.bashrc` or `.bash_profile` to enable Bash autocompletion: ```bash echo '. panacead_completion' >> ~/.bashrc ``` Refer to the user's manual of your interpreter provided by your operating system for information on how to enable shell autocompletion. ::: ## AOL ### Create Topic You can create topic with this: ```bash panacead tx aol create-topic \ --from \ ``` ### List Topics You can query the list of topics belong to specific account: `panacead query aol list-topics ` You can get the detail information of the topic with this: ```bash panacead query aol get-topic ``` **Add Writer** You can add writer to the specific topic. the list of all validators of a specific chain: ```bash panacead tx aol add-writer \ --from \ \ ``` ::: tip Note that the topic owner is not a writer as default. You need to add your self to the topic as a writer. ::: ### List Writers You can query the list of writers to the topic: ```bash panacead query aol list-writers ``` You can get the detail information of the writer with this: ```bash panacead query aol get-writer ``` where `[name]` is the name of the key you specified when you initialized `panacead`. While tokens are bonded, they are pooled with all the other bonded tokens in the network. Validators and delegators obtain a percentage of shares that equal their stake in this pool. ### Delete Writer Owner can delete writer from the topic. After owner delete the writer, writer can not add record to the topic anymore. ```bash panacead tx aol delete-writer \ --from \ \ ``` ::: Note that only owner can delete writer from the topic ::: ### Add Record Writer can add record to the topic with this: ```bash panacead tx aol add-record \ --from \ ``` ### Get Record You can query the record with this: ```bash panacead query aol get-record ``` ## DID ### Create(Issue) a DID ```bash panacead tx did create-did \ --chain-id \ --from
``` This doesn't require any parameter except `chain-id` and `from`. That is, it generates a Secp256k1 key-pair and derive a DID and a DID Document. The DID Document is stored in Panacea. To store the key-pair safely in your local, the command will prompt you to enter a passphrase. The encrypted key-pair file will be stored in your `~/did_keystore` directory. ### Resolve a DID ```bash panacead query did get-did ``` This returns a DID Document in JSON corresponding to that DID. If the DID doesn't exist, or was already deactivated, an error will be returned. ### Update a DID ```bash panacead tx did update-did \ --chain-id \ --from
``` A DID Document will be replaced to the new one written in a JSON file: ``. To prove that you are the DID owner, you must pass a `` that is one of `verificationMethod`s in the DID Document. Also, that command will prompt you to enter a passphrase of that key if the key-pair is stored in your keystore: `~/did_keystore`. The key-pair will be used to make a signature so that Panacea can verify that you are the DID owner. ### Deactivate a DID ```bash panacead tx did deactivate-did \ --chain-id \ --from
``` Like updating a DID, a `` must be specified and the corresponding key-pair should be used to make a signature so that Panacea can verify that you are the DID owner. Deactivating a DID is not the same as deleting a DID. DIDs cannot be deleted permanently. They can just be deactivated. And DIDs cannot be reused to create another DID Documents forever. ## Token ### Issue a new token A new token can be issued by the following command. Anyone can issue a new token with fee paid. After issuing, the token would appear in the issuer's account. The symbol doesn't have to be unique. `-` followed by random 3 letters will be appended to the provided symbol to avoid uniqueness constraint. Those 3 letters are the first three letters of the Tx hash of the `issue` transaction. The generated symbol will be returned as a Tx response. For more details of each parameter, please see the [Token specification](/v2.0/specifications/token). ```bash # Note that the total supply must be in micro unit without a denomination. panacead tx token issue \ "my token" \ KAI \ 1000000000 \ --mintable \ --from panacea126r28pr7sstg7yfmedv3qq4st4a4exlwccx2vc \ --chain-id testing ``` ### Query a token ```bash # List all token symbols $ panacead query token list-tokens --chain-id testing - KAI-0C5 - KAI-0EA # Query a token $ panacead query token get-token KAI-0EA name: my secret token symbol: KAI-0EA totalsupply: denom: ukai0ea amount: "1000000000" mintable: true owneraddress: panacea126r28pr7sstg7yfmedv3qq4st4a4exlwccx2vc ``` ### Query account balances and send tokens Of course, the new token is visible in the account balance. ```bash $ panacead query account panacea126r28pr7sstg7yfmedv3qq4st4a4exlwccx2vc address: panacea126r28pr7sstg7yfmedv3qq4st4a4exlwccx2vc coins: - denom: ukai0c5 amount: "1000000000" - denom: ukai0ea amount: "999999900" - denom: ukai62e amount: "1000000000" - denom: umed amount: "99000000000000" pubkey: panaceapub1addwnpepqf2m7rxgazcem4e6x4hjnwexeagrqjfdlkvz65e0jpxv5sn76jurgpqmpd5 accountnumber: 0 sequence: 6 ``` Also, the new token can be sent to other accounts. Note that the `amount` must be specified with the micro-denomination that contains the 3-letter suffix (without `-`). ```bash panacead tx send 1000000ukai0ea ``` # Ledger Nano Support Using a hardware wallet to store your keys improves the security of your assets. The [Ledger](https://www.ledger.com/) device acts as an enclave of the seed and private keys, and the process of signing transaction takes place within it. The following is a short tutorial on using the Panacea Ledger app with the Panacea CLI. ## Install the Panacea Ledger app Installing the `Panacea` app on your Ledger device is required before using the Panacea CLI. 1. Install [Ledger Live](https://www.ledger.com/ledger-live/) on your machine. 2. Using Ledger Live, update your Ledger Nano device with the latest firmware. 3. Navigate to the `Manager` menu on the Ledger Live. 4. Connect your Ledger Nano device and allow Ledger Manager from it. 5. On the Ledger Live, search for `Panacea` and install it. ## Panacea CLI + Ledger Nano Note: You need to [install the `Panacea` app](#install-the-panacea-ledger-app) on your Ledger Nano device before using following this section. ### Before you begin Install `panacead` by following the [guide](/v2.0/guide/installation). ### Add your Ledger key * Connect and unlock your Ledger Nano device. * Open the `Panacea` app on your Ledger Nano device. * Create an account in `panacead` from your Ledger key. ```bash panacead keys add --ledger ``` Note: Be sure to change the `` parameter to be a meaningful name. The `--ledger` flag tells `panacead` to use your Ledger to seed the account. Panacea uses HD wallets. This means you can setup many accounts using the same Ledger seed. To create another account from your Ledger device, run the following command by changing the integer `` to some value >= 0 to choose the account for HD derivation. ```bash panacead keys add --ledger --account ``` ### Confirm your address Run the following command to display your address on the Ledger Nano device. Use the `` you gave your Ledger key. ```bash panacead keys show -d ``` Confirm that the address displayed on the Ledger Nano device matches that displayed when you added the key. ### Sign a transaction (Send funds) You are now ready to start signing and sending transactions. ```bash panacead tx bank send umed \ --node http://54.180.169.37:26657 \ --chain-id panacea-2 \ --fees 1000000umed ``` Be sure to set a proper full node address to the `--node` parameter. In the above example, one of the [Panacea Mainnet full nodes](https://github.com/medibloc/panacea-launch) was used. Also, the `--chain-id` must be set as `panacea-2` which is the current chain ID of the Panacea Mainnet. For `--fees`, please set `1000000umed` which is the approximate minimum in the current Mainnet network. You will be prompted to review and approve the transaction on your Ledger Nano device. Be sure to inspect the transaction displayed on the screen. ### Receive funds To receive funds to the Panacea account on your Ledger Nano device, retrieve the address for your Ledger Nano device (the ones with `type: ledger`) with this command: ```bash panacead keys list - name: type: ledger address: panacea1... ``` ### Support For further support, * # AOL The AOL(Append Only Log), which can store various useful data such as healthcare data, is the key feature of the Panacea blockchain. It allows user to manage topics, authorities, and data. ### Overview #### Create Topic ```go // MsgCreateTopic - create topics type MsgCreateTopic struct { TopicName string `json:"topic_name"` Description string `json:"description"` OwnerAddress sdk.AccAddress `json:"owner_address"` } ``` A `MsgCreateTopic` is constructed to facilitate the AOL topic. Message sender can set a topic and description. The writer can add record after receiving the appropriate privileges. Each field has limit. See the [Limits](#limits) section. #### Add Writer ```go // MsgAddWriter - add writer to the topic type MsgAddWriter struct { TopicName string `json:"topic_name"` Moniker string `json:"moniker"` Description string `json:"description"` WriterAddress sdk.AccAddress `json:"writer_address"` OwnerAddress sdk.AccAddress `json:"owner_address"` } ``` The owner of the exist topics can manage writer privileges. Writer who received privileges from the topic owner can add record to the topic. This means that the owner authenticate the writer. This `MsgAddWriter` performs a function similar to issuing a certificate. Each field has limit. See the [Limits](#limits) section. #### Delete Writer ```go // MsgDeleteWriter - delete writer from the topic type MsgDeleteWriter struct { TopicName string `json:"topic_name"` WriterAddress sdk.AccAddress `json:"writer_address"` OwnerAddress sdk.AccAddress `json:"owner_address"` } ``` This `MsgDeleteWriter` removes writer from the topic. It is impossible to add record to the topic after being deprived of authority. Each field has limit. See the [Limits](#limits) section. #### Add Record ```go // MsgAddRecord - add record to topic type MsgAddRecord struct { TopicName string `json:"topic_name"` Key []byte `json:"key"` Value []byte `json:"value"` WriterAddress sdk.AccAddress `json:"writer_address"` OwnerAddress sdk.AccAddress `json:"owner_address"` FeePayerAddress sdk.AccAddress `json:"fee_payer_address"` } ``` This `MsgAddRecord` add record or any data to the topic. If `FeePayerAddress` is provided, node charges fee to FeePayer. Each field has limit. See the [Limits](#limits) section. ### Limits | Field | Min Length | Max Length | Charset | | ------------- | ---------- | ---------- | ------------------------------------- | | `TopicName` | 1 | 70 | `a-z`, `A-Z`, `0-9`, `.`, `_` and `-` | | `Moniker` | 0 | 70 | `a-z`, `A-Z`, `0-9`, `.`, `_` and `-` | | `Description` | 0 | 5,000 | Any | | `Key` | 0 | 70 | Any | | `Value` | 0 | 5,000 | Any | # DID Please see the [Official Panacea DID Specification](https://github.com/medibloc/panacea-core/blob/master/docs/did.md). # Token The Token module, which can issue new tokens. ### Overview #### Issue a new token ```go type MsgIssueToken struct { Name Name `json:"name"` Symbol Symbol `json:"symbol"` TotalSupply sdk.Int `json:"total_supply"` Mintable bool `json:"mintable"` OwnerAddress sdk.AccAddress `json:"owner_address"` } ``` A new token can be issued by the transaction message above. Anyone can issue a new token with fee paid. Each field in the message has the following limits: **`Name`** A human-friendly name, limited to 32 characters, such as `Hello Token`. **`Symbol`** An identifier of the token, limited to alphanumeric characters and is case-insensitive, such as `KAI`. The first letter must be an alphabet character. The length of symbol should be between 3 and 13. The symbol doesn't have to be unique. `-` followed by random 3 letters will be appended to the provided symbol to avoid uniqueness constraint. For example, `KAI-0EA`. Those 3 letters are the first three letters of the Tx hash of the `issue` transaction. So, the total length of the generated symbol will be between 7 and 17. The generated symbol will be returned as a Tx response. **`TotalSupply`** An amount of the total supply in micro unit (by 1e6 for decimal part). The max total supply is 90 billion. **`Mintable`** That means whether this token can be minted in the future. **`OwnerAddress`** An issuer address of the transaction. It will become the owner of the token. All supplied tokens will be in this account. # Validator FAQ ## General Concepts ### What is a validator? The role of validators is to run a full-node and participate in consensus by broadcasting votes which contain cryptographic signatures. Validators commit new blocks and receive rewards in exchange for their work. They must also participate in governance by voting on proposals. Validators are weighted according to their total stake. ### What is 'staking'? The Panacea is a public Delegated Proof-Of-Stake (dPoS) blockchain, meaning that the weight of validators is determined by the amount of staking tokens (MED) bonded as collateral. These MEDs can be self-delegated directly by the validator or delegated to them by other MED holders. Any user in the system can declare their intention to become a validator by sending a `create-validator` transaction. Initially, only the top 50 validators with the most voting power will be active validators. ### What is a full-node? A full-node is a program that fully validates transactions and blocks of a blockchain. It is distinct from a light-node that only processes block headers and a small subset of transactions. Running a full-node requires more resources than a light-node but is necessary in order to be a validator. In practice, running a full-node only implies running a non-compromised and up-to-date version of the software with low network latency and without downtime. Of course, it is possible and encouraged for users to run full-nodes even if they do not plan to be validators. ### What is a delegator? Delegators are MED holders who cannot, or do not want to run a validator node themselves. MED holders can delegate MEDs to a validator and obtain a part of their revenue in exchange. Because they share revenue with their validators, delegators also share risks. Should a validator misbehave, each of their delegators will be partially slashed in proportion to their delegated stake. This is why delegators should perform due diligence on validators before delegating, as well as spreading their stake over multiple validators. Delegators play a critical role in the system, as they are responsible for choosing validators. Being a delegator is not a passive role. Delegators should actively monitor the actions of their validators and participate in governance. ## Becoming a Validator ### How to become a validator? Any participant in the network can signal that they want to become a validator by sending a `create-validator` transaction, where they must fill out the following parameters: [link](/v2.0/guide/interaction-with-the-network-cli#staking). Once a validator is created, MED holders can delegate MEDs to them, effectively adding stake to their pool. The total stake of an address is the combination of MEDs bonded by delegators and MEDs self-bonded by the entity which designated themselves. Out of all validator candidates that signaled themselves, the 50 with the most total stake are the ones who are designated as validators. They become validators If a validator's total stake falls below the top 50 then that validator loses their validator privileges: they don't participate in consensus and generate rewards anymore. Over time, the maximum number of validators may be increased via on-chain governance proposal. ### What are the different states a validator can be in? After a validator is created with a `create-validator` transaction, they can be in three states: * `in validator set`: Validator is in the active set and participates in consensus. Validator is earning rewards and can be slashed for misbehaviour. * `jailed`: Validator misbehaved and is in jail, i.e. outside of the validator set. If the jailing is due to being offline for too long, the validator can send an `unjail` transaction in order to re-enter the validator set. If the jailing is due to double signing, the validator cannot unjail. * `unbonded`: Validator is not in the active set, and therefore not signing blocks. Validator cannot be slashed, and does not earn any reward. It is still possible to delegate MEDs to this validator. Un-delegating from an `unbonded` validator is immediate. ### What is 'self-delegation'? How can I increase my 'self-delegation'? Self-delegation is delegation from a validator to themselves. This amount can be increases by sending a delegate transaction from your validator's application key. For details about the application key, please see the [Key Types](/v2.0/guide/interaction-with-the-network-cli#key-types) guide. ### Is there a minimum amount of MEDs that must be delegated to be an active (=bonded) validator? The minimum is `1 med`. ### How will delegators choose their validators? Delegators are free to choose validators according to their own subjective criteria. This said, criteria anticipated to be important include: * **Amount of self-delegated MEDs**: Number of MEDs a validator self-delegated to themselves. A validator with a higher amount of self-delegated MEDs has more skin in the game, making them more liable for their actions. * **Amount of delegated MEDs**: Total number of MEDs delegated to a validator. A high voting power shows that the community trusts this validator, but it also means that this validator is a bigger target for hackers. Bigger validators also decrease the decentralisation of the network. * **Commission rate**: Commission applied on revenue by validators before it is distributed to their delegators. * **Track record**: Delegators will likely look at the track record of the validators they plan to delegate to. This includes seniority, past votes on proposals, historical average uptime and how often the node was compromised. ## Responsibilities ### Do validators need to be publicly identified? No, they do not. Each delegator will value validators based on their own criteria. Validators will be able to register a website address when they nominate themselves so that they can advertise their operation as they see fit. Some delegators may prefer a website that clearly displays the team operating the validator and their resume, while others might prefer anonymous validators with positive track records. ### What are the responsibilities of a validator? Validators have two main responsibilities: * **Be able to constantly run a correct version of the software**: Validators need to make sure that their servers are always online, and their private keys are not compromised. * **Actively participate in governance**: Validators are required to vote on every proposal. ### What does 'participate in governance' entail? Validators and delegators can vote on proposals to change operational parameters (such as the block gas limit), coordinate upgrades, or make a decision on any given matter. Validators play a special role in the governance system. Being the pillars of the system, they are required to vote on every proposal. It is especially important since delegators who do not vote will inherit the vote of their validator. ### What does staking imply? Staking MEDs can be thought of as a safety deposit on validation activities. When a validator or a delegator wants to retrieve part or all of their deposit, they send an `unbonding` transaction. Then, MEDs undergo a 3 weeks unbonding period during which they are liable to being slashed for potential misbehavior committed by the validator before the unbonding process started. Validators, and by association delegators, receive block rewards, fees, and have the right to participate in governance. If a validator misbehaves, a certain portion of their total stake is slashed. This means that every delegator that bonded MEDs to this validator gets penalized in proportion to their bonded stake. Delegators are therefore incentivized to delegate to validators that they anticipate will function safely. ### Can a validator run away with their delegators' MEDs? By delegating to a validator, a user delegates voting power. The more voting power a validator have, the more weight they have in the consensus and governance processes. This does not mean that the validator has custody of their delegators' MEDs. **By no means can a validator run away with its delegator's funds**. Even though delegated funds cannot be stolen by their validators, delegators are still liable if their validators misbehave. ### How often will a validator be chosen to propose the next block? Does it go up with the quantity of bonded MEDs? The validator that is selected to propose the next block is called proposer. Each proposer is selected deterministically, and the frequency of being chosen is proportional to the voting power of the validator. For example, if the total bonded stake across all validators is 100 MEDs and a validator's total stake is 10 MEDs, then this validator will proposer \~10% of the blocks. ## Incentives ### What is the incentive to stake? Each member of a validator's staking pool earns different types of revenue: * **Block rewards**: Native tokens of applications run by validators (e.g. MEDs on the Panacea) are inflated to produce block provisions. These provisions exist to incentivize MED holders to bond their stake, as non-bonded MED will be diluted over time. * **Transaction fees**: The Panacea maintains a whitelist of token that are accepted as fee payment. The initial fee token is the MED. This total revenue is divided among validators' staking pools according to each validator's weight. Then, within each validator's staking pool the revenue is divided among delegators in proportion to each delegator's stake. A commission on delegators' revenue is applied by the validator before it is distributed. ### What is the incentive to run a validator? Validators earn proportionally more revenue than their delegators because of commissions. Validators also play a major role in governance. If a delegator does not vote, they inherit the vote from their validator. This gives validators a major responsibility in the ecosystem. ### What are validators commission? Revenue received by a validator's pool is split between the validator and their delegators. The validator can apply a commission on the part of the revenue that goes to their delegators. This commission is set as a percentage. Each validator is free to set their initial commission, maximum daily commission change rate and maximum commission. The Panacea enforces the parameter that each validator sets. Only the commission rate can change after the validator is created. ### How are block rewards distributed? Block rewards are distributed proportionally to all validators relative to their voting power. This means that even though each validator gains MEDs with each reward, all validators will maintain equal weight over time. Let us take an example where we have 10 validators with equal voting power and a commission rate of 10%. Let us also assume that the reward for a block is 1000 MEDs and that each validator has 20% of self-bonded MEDs. These tokens do not go directly to the proposer. Instead, they are evenly spread among validators. So now each validator's pool has 100 MEDs. These 100 MEDs will be distributed according to each participant's stake: * Commission: `100 * 80% * 10% = 8 MEDs` * Validator gets: `100 * 20% + Commission = 28 MEDs` * All delegators get: `100 * 80% - Commission = 72 MEDs` Then, each delegator can claim their part of the 72 MEDs in proportion to their stake in the validator's staking pool. ### How are fees distributed? Fees are similarly distributed with the exception that the block proposer can get a bonus on the fees of the block they propose if they include more than the strict minimum of required precommits. When a validator is selected to propose the next block, they must include at least 2/3 precommits of the previous block. However, there is an incentive to include more than 2/3 precommits in the form of a bonus. The bonus is linear: it ranges from 1% if the proposer includes 2/3rd precommits (minimum for the block to be valid) to 5% if the proposer includes 100% precommits. Of course the proposer should not wait too long or other validators may timeout and move on to the next proposer. As such, validators have to find a balance between wait-time to get the most signatures and risk of losing out on proposing the next block. This mechanism aims to incentivize non-empty block proposals, better networking between validators as well as to mitigate censorship. Let's take a concrete example to illustrate the aforementioned concept. In this example, there are 10 validators with equal stake. Each of them applies a 10% commission rate and has 20% of self-delegated MEDs. Now comes a successful block that collects a total of 1025.51020408 MED in fees. First, a 2% tax is applied. The corresponding MED go to the reserved community pool. The community pool's funds can be allocated through governance. * `2% * 1025.51020408` = 20.51020408 MED go to the community pool 1005 MED now remain to be distributed to validators and delegators. Let's assume that the proposer included 100% of the signatures in its block. It thus obtains the full bonus of 5%. We have to solve this simple equation to find the reward `R` for each validator: ``` 9*R + R + R*5% = 1005 R = 1005/10.05 = 100 ``` * For the proposer validator: * The pool obtains `R + R * 5%`: 105 MED * Commission: `105 * 80% * 10%` = 8.4 MED * Validator's reward: `105 * 20% + Commission` = 29.4 MED * Delegators' rewards: `105 * 80% - Commission` = 75.6 MED (each delegator will be able to claim its portion of these rewards in proportion to their stake) * For each non-proposer validator: * The pool obtains `R`: 100 MED * Commission: `100 * 80% * 10%` = 8 MED * Validator's reward: `100 * 20% + Commission` = 28 MED * Delegators' rewards: `100 * 80% - Commission` = 72 MED (each delegator will be able to claim their portion of these rewards in proportion to their stake) ### What are the slashing conditions? If a validator misbehaves, their delegated stake will be partially slashed. There are currently two faults that can result in slashing of funds for a validator and their delegators: * **Double signing**: If someone reports on chain A that a validator signed two blocks at the same height on chain A and chain B, and if chain A and chain B share a common ancestor, then this validator will get slashed by 5% on chain A. * **Downtime**: If a validator misses more than 95% of the last 10,000 blocks, they will get slashed by 0.01%. ## Technical Requirements ### What are hardware requirements? Validators should expect to provision one or more data center locations with redundant power, networking, firewalls, HSMs and servers. We expect that a modest level of hardware specifications will be needed initially and that they might rise as network use increases. For details, please see the [Join the Network](/v2.0/guide/join-the-network) guide. ### What are software requirements? In addition to running a Panacea node, validators should develop monitoring, alerting and management solutions. ### What are bandwidth requirements? The Panacea network has the capacity for very high throughput relative to chains like Ethereum or Bitcoin. We recommend that the data center nodes only connect to trusted full-nodes in the cloud or other validators that know each other socially. This relieves the data center node from the burden of mitigating denial-of-service attacks. Ultimately, as the network becomes more heavily used, multi-gigabyte per day bandwidth is very realistic. ### What does running a validator imply in terms of logistics? A successful validator operation will require the efforts of multiple highly skilled individuals and continuous operational attention. This will be considerably more involved than running a bitcoin miner for instance. ### How to handle key management? Validators should expect to run an HSM that supports ed25519 keys. Here are potential options: * YubiHSM 2 * Ledger Nano S * Ledger BOLOS SGX enclave * Thales nShield support The Tendermint team does not recommend one solution above the other. The community is encouraged to bolster the effort to improve HSMs and the security of key management. ### What can validators expect in terms of operations? Running effective operation is the key to avoiding unexpectedly unbonding or being slashed. This includes being able to respond to attacks, outages, as well as to maintain security and isolation in your data center. ### What are the maintenance requirements? Validators should expect to perform regular software updates to accommodate upgrades and bug fixes. There will inevitably be issues with the network early in its bootstrapping phase that will require substantial vigilance. ### How can validators protect themselves from denial-of-service attacks? Denial-of-service attacks occur when an attacker sends a flood of internet traffic to an IP address to prevent the server at the IP address from connecting to the internet. An attacker scans the network, tries to learn the IP address of various validator nodes and disconnect them from communication by flooding them with traffic. One recommended way to mitigate these risks is for validators to carefully structure their network topology in a so-called sentry node architecture. Validator nodes should only connect to full-nodes they trust because they operate them themselves or are run by other validators they know socially. A validator node will typically run in a data center. Most data centers provide direct links the networks of major cloud providers. The validator can use those links to connect to sentry nodes in the cloud. This shifts the burden of denial-of-service from the validator's node directly to its sentry nodes, and may require new sentry nodes be spun up or activated to mitigate attacks on existing ones. Sentry nodes can be quickly spun up or change their IP addresses. Because the links to the sentry nodes are in private IP space, an internet based attacked cannot disturb them directly. This will ensure validator block proposals and votes always make it to the rest of the network. It is expected that good operating procedures on that part of validators will completely mitigate these threats. For more on sentry node architecture, see [this](https://docs.tendermint.com/master/nodes/validators.html#setting-up-a-validator).