Modules
Overview
Planq utilizes Ethermint and the Tendermint Core consensus engine underneath. Specifically, the Cosmos SDK is a framework that facilitates the development of secure state-machines on top of Tendermint. In particular, we utilize different SDK modules to facilitate the special features of Planq.
In this documentation, we will be focusing on some of the important modules we used, for example:
Bank - Token transfer functionalities and query support for the total supply of all assets;
Distribution - Fee distribution, and staking rewards to the validators and delegator;
Governance - On-chain proposals and voting;
Mint - Creation of new units of staking token;
Slashing - Validator punishment mechanisms;
Staking - Proof-of-Stake layer for public blockchains;
bank
bank
Introduction
The bank
module maintains the state of two primary objects:
Account balances by address;
Total supply of tokens of the chain
bank
module tracks and provides query support for the total supply of all assets used in the application. It also supports token transfer functionalities. Specifically, the total supply is updated whenever a token is:
Minted, e.g. Token created by the mint module; or
Burned, e.g. Token distorted by the slashing module.
Transactions and Queries
Transactions
tx bank send [from_key_or_address] [to_address] [amount] [network_id]
- Send Funds
tx bank send [from_key_or_address] [to_address] [amount] [network_id]
- Send FundsYou can transfer of tokens between to a designated address by the tx bank send
command. For example, we can send 1 atplanq from address_a
to address_b
by
Queries
query bank balances [address]
- Check the balance of a specified account
query bank balances [address]
- Check the balance of a specified accountOne can check the current balance of a specified account by:
query bank total
- Check the total supply of the token
query bank total
- Check the total supply of the tokenYou can also check the current total supply of the token by:
Appendix
bank
module: Network Parameters and configuration
bank
module: Network Parameters and configurationdistribution
distribution
Introduction
The distribution
module is responsible for the distribution of rewards to the validators and delegators.
Overview
Network Parameters
Below are all the network parameters for the distribution
module:
community_tax
- The rate of community tax;base_proposer_reward
- Base bonus on transaction fees collected in a valid block;bonus_proposer_reward
- Maximum bonus on transaction fees collected in a valid block;withdraw_addr_enabled
- Whether delegators can set a different address to withdraw their rewards.
Rewards
There are two main types of rewards
Block rewards, governed by the mint module; and
Block reward
Block rewards are distributed proportionally to all validators relative to their voting power. This means that even though each validator gains cro with each reward, all validators will maintain equal weight over time.
For the validator operator, the distribution information is updated if:
the amount of delegation to a validator is updated (delegation, unbond, slashing etc.);
a validator successfully proposes a block and receives the reward;
any delegator withdraws from a validator, or
the validator withdraws it's commission.
For delegators, once they have delegated to a validator, they will be entitled to a portion of the total reward obtained by the validators. The reward is proportional to their delegated amount, and the commission charged by the validator operator (if any).
Transaction Fees Bonus
When a validator is selected to propose the next block, they must include at least 66% precommits of the previous block. To incentivise validators to include more than 66% precommits, the module provide a bonus reward (portion of the transaction fee in the block) to the proposer.
This bonus reward is dependent linearly on the precommits from the other validators. Stating from 66% of the precommits, the basic bonus will be base_proposer_reward
and increase linearly to bonus_proposer_reward
when the validator includes 100% of the precommits.
This mechanism aims to incentivize non-empty block proposals, better networking between validators as well as to mitigate censorship. For further example, kindly refers to this link.
Community tax
The community_tax
is the tax rate to the reward obtained by the validator. Specifically, part of the reward will be taxed and send to the community pool. The funds in the community pool can be withdrawn by submitting a community pool spend proposal with the gov module.
Even if the community_tax
is set to be zero, the balance of the community pool could be non-zero. For example, the truncated remainder in some accounting edge cases will be sent to the community pool as well. Besides that, users can fund the community pool voluntary, and there could be funds allocated to the community pool in the genesis.
Transactions and Queries
Transactions
tx distribution withdraw-all-rewards
- Withdraw all delegations rewards for a delegator
tx distribution withdraw-all-rewards
- Withdraw all delegations rewards for a delegatorDelegator can withdraw their reward(s) from the validator(s) that they have delegated all at once.
tx distribution withdraw-rewards [validator-addr]
- Withdraw rewards from a given validator address
tx distribution withdraw-rewards [validator-addr]
- Withdraw rewards from a given validator addressDelegator can withdraw their reward from a specific validator.
:::tip Remark: Validator operation can withdraw the commission in addition to the rewards by adding the commission flag --commission
. :::
tx distribution set-withdraw-addr [withdraw-addr]
- Change the default withdraw address for rewards associated with an address
tx distribution set-withdraw-addr [withdraw-addr]
- Change the default withdraw address for rewards associated with an addressDelegator can set a different address to withdraw their rewards.
tx distribution fund-community-pool [amount]
- Funds the community pool with the specified amount
tx distribution fund-community-pool [amount]
- Funds the community pool with the specified amountUsers can make a contribution to the community pool with a specific amount.
Queries
query distribution commission [validator]
- Query distribution validator commission
query distribution commission [validator]
- Query distribution validator commissionWe can check the commission of a specific validator.
query distribution community-pool
- Query the amount of coins in the community pool
query distribution community-pool
- Query the amount of coins in the community poolWe can check the balance of the community pool.
query distribution rewards [delegator-addr] [validator-addr]
- Query all distribution delegator rewards or rewards from a particular validator
query distribution rewards [delegator-addr] [validator-addr]
- Query all distribution delegator rewards or rewards from a particular validatorwe can check the current rewards for a delegation on a specific validator.
query distribution slashes [validator] [start-height] [end-height]
- Query distribution validator slashes
query distribution slashes [validator] [start-height] [end-height]
- Query distribution validator slashesWe can check the history of slashing event of a validator.
query distribution validator-outstanding-rewards [validator]
- Query distribution outstanding rewards for a validator and all their delegations
query distribution validator-outstanding-rewards [validator]
- Query distribution outstanding rewards for a validator and all their delegationsWe can check distribution outstanding (un-withdrawn) rewards for a validator and all of their delegations.
query distribution params
- Query the current distribution parameters
query distribution params
- Query the current distribution parametersWe can query the current distribution parameters by
Appendix
distribution
module: Network Parameters and configuration
distribution
module: Network Parameters and configurationThe following tables show overall effects on different configurations of the distribution related network parameters:
gov
gov
Introduction
The gov
module enables on-chain governance which allows Planq token holder to participate in the decision-making processes. For example, users can:
Form an idea and seek the feedback;
Create the proposal and adjust according to feedback as needed;
Submit a proposal along with an initial deposit;
Deposit tokens and fund an active proposal;
Vote for an active proposal.
The details about the governance proposal process are available on The Proposal Process page.
Overview
Network parameters
Below are all the network parameters for the gov
module:
deposit_params
- Deposit related parameters:min_deposit
: Minimum deposit for a proposal to enter voting period; andmax_deposit_period
: Maximum period for Cro holders to deposit on a proposal.
voting_params
- Voting related parametersvoting_period
: The length of the voting period.
tally_params
- Tally related parametersquorum
: The minimum percentage of voting power that needs to be casted on a proposal for the result to be valid;threshold
: Minimum proportion ofYes
votes (excludingAbstain
votes) for the proposal to be accepted; andveto
: Minimum proportion ofVeto
votes to total votes ratio for proposal to be vetoed.
The Governance Procedure
Phase 0 - Submit a proposal along with an initial deposit:
Users can submit a proposal with an initial deposit. The proposal will then become "active" and entre the deposit period.
Phase 1 - Deposit period
During the deposit period, users can deposit and support an active proposal. Once the deposit of the proposal reached min_deposit
, it will enter the voting period. Otherwise, if the proposal is not successfully funded within max_deposit_period
, It will become inactive and all the deposit will be refunded.
Phase 2 - Voting period
During the voting period, staked (bonded) token will be able to participate in the voting. Users can choose one of the following option: "yes"
, "no"
, "no_with_veto"
and "abstain"
After the voting_period
has passed, there are several scenarios that a proposal will consider to be "Rejected", for example, if
No one votes (everyone
"abstain"
);Votes did not reach the
quorum
;More than
veto
of voters vote for"no_with_veto"
;More than
threshold
that non-abstaining voters vote"no"
.
Otherwise, the proposal will be accepted and changes will be implemented according to the proposal.
Transactions and Queries
Transactions
tx gov submit-proposal
- Submit a proposal along with an initial deposit
tx gov submit-proposal
- Submit a proposal along with an initial depositSubmit a parameter change proposal -
param-change [proposal-file]
Users can submit a proposal to modify network parameters during run time, Here is a demon proposal if we would like to change the parameter
MaxValidators
(maximum number of validator) in thestaking
module,Submit a community pool spend proposal -
community-pool-spend [proposal-file]
Users can submit a proposal and request funds from the community pool to support their projects or other usages.
Submit a software upgrade proposal-
software-upgrade [name] (--upgrade-height [height] | --upgrade-time [time]) (--upgrade-info [info])
Users can submit an upgrade proposal and suggest a software upgrade at a specific block height.
Cancel the current software upgrade proposal -
cancel-software-upgrade
On the other hand, users can submit a proposal to cancel the planned software upgrade.
tx gov deposit [proposal-id] [deposit]
- Deposit tokens for an active proposal
tx gov deposit [proposal-id] [deposit]
- Deposit tokens for an active proposalUsers can submit a deposit transaction to fund and support an active proposal.
tx gov vote [proposal-id] [option]
- Vote for an active proposal
tx gov vote [proposal-id] [option]
- Vote for an active proposalUsers can vote for an active proposal. Valid value of "option"
field can be "yes"
, "no"
, "no_with_veto"
and "abstain"
.
Queries
query gov proposals [proposal-id]
- Query proposals with optional filters
query gov proposals [proposal-id]
- Query proposals with optional filtersWe can check the proposal with optional filters by:
In the above example, there is only one proposal with "proposal_id": "1"
, with the title: "Staking Param Change"
that change the MaxValidators
parameter of the staking
module to 151
. We can also see that the status of the proposal is "PROPOSAL_STATUS_PASSED"
, which means that this proposal has bee passed.
query gov proposal [proposal-id]
Query details of a single proposal
query gov proposal [proposal-id]
Query details of a single proposalSimilarly, we can check the details of a proposal with a given "proposal_id"
.
query gov tally [proposal-id]
Get the tally of a proposal vote
query gov tally [proposal-id]
Get the tally of a proposal voteWe can also the tally of a proposal with a given "proposal_id"
.
query gov params
- Query the current gov parameters
query gov params
- Query the current gov parametersWe can query the current gov parameters by
Appendix
gov
module: Network Parameters and configuration
gov
module: Network Parameters and configurationThe following tables show overall effects on different configurations of the gov related network parameters:
mint
mint
Introduction
The mint
module is responsible for creating token in a flexible way to reward the validator who participate in the proof of stake consensus process (see also the distribution module). It is also designed in a way to bring a balance between market liquidity and staked supply.
Overview
Network parameters
Below are all the network parameters for the mint
module:
"blocks_per_year"
- The expected number of blocks being produced per year;"goal_bonded"
- Goal of bonded token in percentage;"inflation_max"
- Maximum annual inflation rate;"inflation_min"
- Minimum annual inflation rate;"inflation_rate_change"
- Maximum annual change in inflation rate;"mint_denom"
- Token type being minted.
The target annual inflation rate is recalculated for each previsions cycle. The inflation is also subject to a rate change (positive or negative) depending on the distance from the desired ratio ("goal_bonded"
). The maximum rate change possible is defined to be "inflation_rate_change"
per year, where the annual inflation is capped as between "inflation_min"
and "inflation_max"
.
mint
module: Queries
mint
module: QueriesQueries
query mint params
- Query the current minting annual provisions value
query mint params
- Query the current minting annual provisions valueWe can query the current minting annual provisions value, for example:
implies that the current minting annual provisions will be 109573801550200370
atplanq ( i.e. 1,095,738,015
cro)
query mint inflation
- Query the current minting inflation value
query mint inflation
- Query the current minting inflation valueWe can query the current minting inflation value, for example:
implies that the current minting annual provisions will be 0.013687008526984104
( i.e. 1.368%
)
query mint annual-provisions
- Query the current minting parameters
query mint annual-provisions
- Query the current minting parametersWe can query the current query parameters by
Appendix
gov
module: Network Parameters and configuration
gov
module: Network Parameters and configurationThe following tables show overall effects on different configurations of the mint related network parameters:
slashing
slashing
Introduction
Validators are responsible for signing or proposing block at each consensus round. A penalty should be imposed on validators' misbehavior to reinforce this.
Specifically, slashing
functionality that aims to dis-incentivize network-observable actions, such as faulty validations. The penalties may include losing some amount of their stake, losing their ability to perform the network functionality for a period of time, collect rewards etc.
Overview
Network parameters
Below are all the network parameters used to configure the behavior of validator punishments. Details of all these parameters and their effect on behavior of validator punishments is discussed later in this document.
signed_blocks_window
: Number of blocks for which the liveness is calculated for uptime tracking;min_signed_per_window
: Maximum percentage of blocks with faulty/missed validations allowed for an account in last;signed_blocks_window
blocks before it gets deactivated;downtime_jail_duration
: Duration for jailing;slash_fraction_double_sign
: Percentage of funds being slashed when validator makes a byzantine fault; andslash_fraction_downtime
: Percentage of funds being slashed when a validator is non-live.
Slashing mechanism
Punishments for a validator are triggered when they either make a byzantine fault or become non-live:
Liveness Faults (Low availability)
A validator is said to be non-live when they fail to sign at least
min_signed_per_window
blocks (in percentage) in the lastsigned_blocks_window
blocks successfully.signed_blocks_window
andmin_signed_per_window
are network parameters and can be configured during genesis and can be updated during runtime by the governance module.
:::tip Example: For example, if block_signing_window
is 2000
blocks and min_signed_per_window
is 0.5
, a validator will be marked as non-live and jailed if they fail to successfully sign at least 2000*0.5=1000
blocks in last 2000
blocks. :::
Byzantine Faults
A validator is said to make a byzantine fault when they sign conflicting messages/blocks at the same height and round. Tendermint has mechanisms to publish evidence of validators that signed conflicting votes so they can be punished by the slashing module. For example:
Validator who votes for two different blocks within a single round ("Equivocation validator"/ "Double signing");
Validator who signs commit messages for arbitrary application state ( "Lunatic validator").
Remark: The evidence of a set of validators attempting to mislead a light client can also be detected and captured. However, even the Amnesia attack can be detected, punishment can not be applied at this stage, as we can not deduce the malicious validators.
:::tip Implementation note: Tendermint passes Evidence
of a byzantine validator in BeginBlock
request. Before jailing any account due to byzantine fault, that evidence should be verified. Also, it should be checked that evidence provided by tendermint is not older than max_age
in tendermint. :::
Inactivity Slashing
It is important that the validators maintain excellent availability and network connectivity to perform their tasks. A penalty should be imposed on validators' misbehavior to reinforce this.
When a validator fails to successfully sign missed_block_threshold
blocks in last block_signing_window
blocks, it is immediately jailed and punished by deducting funds from their bonded and unbonded amount and removing them from active validator set. The funds to be deducted are calculated based on slash_fraction_downtime
. Kindly refer to this link on the logic of the liveness tracking.
Jailing
A validator is jailed when they make liveness or Byzantine fault, when a validator is jailed, it will no longer be considered as an active validator until they are un-jailed. Futhermore, it cannot be un-jailed before downtime_jail_duration
. This downtime_jail_duration
is a network parameter which can be configured during genesis.
:::warning Important: When a validator is jailed because of a byzantine fault, their validator public key is added to a list of permanently banned validators and cannot re-join the network as a validator with the same public key, see staking tombstone :::
Un-jailing
When a jailed validator wishes to resume normal operations (after downtime_jail_duration
has passed), they can create anunjail
transaction which marks them as un-jailed. Validator will then rejoin the validator set once it has bee successful un-jailed.
Slashing for Byzantine Fault
When there is byzantine fault detected, they are immediately slashed other than jailed. The funds to be deducted are calculated based on slash_fraction_double_sign
. Furthermore, validator who commit this double-signing fault will also be put into the "tombstone state", which means it will be blacklisted and jailed forever.
Transactions and Queries
Transactions
tx slashing unjail
- Unjailing a validator
tx slashing unjail
- Unjailing a validatorValidator could be punished and jailed due to network misbehaviour, for example if we check the validator set:
After the jailing period has passed, one can broadcast a unjail
transaction to unjail the validator and resume its normal operations by
Queries
query slashing params
- Query the current slashing parameters
query slashing params
- Query the current slashing parametersWe can query the current slashing parameters by
Appendix
slashing
module: Network Parameters and configuration
slashing
module: Network Parameters and configurationThe following tables show overall effects on different configurations of the slashing related network parameters:
staking
staking
Introduction
The staking
module handles Proof-of-Stake related logics, which plays a very import part to the underneath consensus protocol.
Overview
Planq is based on Tendermint Core's consensus engine, it relies on a set of validators to participate in the proof of stake (PoS) consensus protocol, and they are responsible for committing new blocks in the blockchain.
unbonding_time
: The time duration of unbonding;max_validators
: The maximum number of validator;max_entries
: The max entries for either unbonding delegation or redelegation;historical_entries
: The number of historical entries to persist; andbond_denom
: Coin denomination for staking.
Validator
Validators are responsible for signing or proposing block at each consensus round. It is important that the validators maintain excellent availability and network connectivity to perform their tasks. To incentivise the validator nodes to run the network, rewards are distributed to the validators according to their performance and amount of staked token (see distribution and mint). On the other hand, a penalty should be imposed on validators' misbehavior (see slashing).
Delegator
The staking
module enables PLQ owners to delegate their tokens to active validators and share part of the reward obtained by the validator during the proof of stake protocol(see distribution module). Specifically, It allows token owners to take part in the consensus process without running a validator themselves.
It is important to point out that the delegator and the validator are on the same boat: They share the reward and the risk. In particular, part of their delegated token could be slashed due to validator's misbehaviour (see slashing). Therefore, It is very important to choose a reliable validator to delegate. Kindly refer to this link for detailed specification and state transitions of delegation.
Transactions and Queries
Transactions
tx staking create-validator
- Create new validator initialized with a self-delegation
tx staking create-validator
- Create new validator initialized with a self-delegationFirst of all, we can create a validator with the create-validator
transaction, for example:
tx staking delegate [validator-addr] [amount]
- Delegate liquid tokens to a validator
tx staking delegate [validator-addr] [amount]
- Delegate liquid tokens to a validatorAs discussed in the delegator section, one can delegate their tokens to an active validators by:
tx staking unbond [validator-addr] [amount]
- Unbond shares from a validator
tx staking unbond [validator-addr] [amount]
- Unbond shares from a validatorDelegator can unbond their staked tokens by
Remark: Note that funds will only be available after the unbonding_time
has passed.
tx staking redelegate [src-validator-addr] [dst-validator-addr] [amount]
- Redelegate illiquid tokens from one validator to another
tx staking redelegate [src-validator-addr] [dst-validator-addr] [amount]
- Redelegate illiquid tokens from one validator to anotherWe can also move our staked tokens from one validator to another by:
Queries
We will be covering most of the commonly used queries here. Meanwhile, you can use
to check all the supported sub-commands.
query staking delegation [delegator-addr] [validator-addr]
- Query a delegation based on address and validator address
query staking delegation [delegator-addr] [validator-addr]
- Query a delegation based on address and validator addressWith a given delegator address and the validator account that it is associated with, we can check the by:
query staking delegations-to [validator-addr]
- Query all delegations made to one validator
query staking delegations-to [validator-addr]
- Query all delegations made to one validatorWe can check all the delegations made to a specific validator:
query staking pool
- Query the current staking pool values
query staking pool
- Query the current staking pool valuesWe can check the amount of bonded and unbonded amount in the staking pool:
query staking unbonding-delegation [delegator-addr] [validator-addr]
- Query an unbonding-delegation record based on delegator and validator address
query staking unbonding-delegation [delegator-addr] [validator-addr]
- Query an unbonding-delegation record based on delegator and validator addressquery staking validator [validator-addr]
- Query a specific validator
query staking validator [validator-addr]
- Query a specific validatorWe can query the details of a specific validator with its validator address (ethvaloper...) by:
query staking validators
- Query all validators
query staking validators
- Query all validatorsA full list of validators and their details can be found by this query.
query staking params
- Query the current staking parameters
query staking params
- Query the current staking parametersFinally, we can query the current staking parameters by
Appendix
staking
module: Network Parameters Configuration
staking
module: Network Parameters ConfigurationThe following tables show overall effects on different configurations of the staking related network parameters:
Last updated