Skip to main content

Consensus nodes

Overview​

Claiming a Validator Seat​

Before any Consensus node can participate in network validation, they must first "claim" their Validator Seat, a process parallel to how governance members claim their Councilor Seat. This action acknowledges the network Code of Conduct and allows the integration of the node in the consensus registrar. To submit a MsgClaimValidator transaction, the account must have permission 2[broken link] , which is assigned either through governance (mainnet) or granted by the sudo account (testnet). In addition, this transaction requires the node's globally unique moniker identifier as a parameter. This moniker is a friendly name with minimum 4 non-whitespace characters that can be set in advance by the account via the Identity Registrar module, or directly when submitting the transaction via the claim-validator-seat CLI if it has not been assigned a value yet. If a different value than the existing one is provided, the transaction will fail. This process ensures the unique identity of each consensus node in the network.

Staking Pools Status & Commissions​

Each consensus node operates its own staking pool where delegators can stake their assets. Each staking pool has a unique ID that is linked to the consensus node's address. The consensus node has the ability to enable or disable the staking pool, as well as set the commission rate on block rewards. Staking pools play a crucial role in reward distribution on KIRA network. All rewards are managed and distributed through these pools, which helps to streamline the process given the network's diverse range of staking tokens.

Before the block’s and fee rewards of a given block are distributed to proposer staking pool’s delegators, the proposer takes a percentage of both types of rewards as commissions. Regarding block rewards, subsidized by KEX inflation, each consensus node setup their own staking pool’s commission rate. The commission rate is a decimal value that cannot be set above 0.5 (50%) and under 0.01 (1%) to prevent them from over-charging delegators or undercharging them in order to make smaller consensus nodes unprofitable. Commissions over fee rewards from execution fees, however, are homogeneous to all staking pools and defined by a governance managed validators_fee_share network property. Likewise, validators_fee_share is capped at 0.5 (50%) but can be set to 0.

Performance-based Rewards​

Consensus nodes are subject to a performance evaluation and the amount of rewards they will actually receive from their commission is pro-rata to their participation in the consensus. If they fail to sign consecutive blocks during a given period, some of those rewards are cut off and sent to the community treasury. Outstanding block and fee rewards are then sent to the consensus node’s staking pool and become claimable by their respective delegators in proportion to the derivative tokens they have. Notice in particular that consensus nodes can be rewarded twice: once through both previous commissions they take as consensus nodes for their service, and once more as delegator if they delegate some assets.

For more information regarding network rewards distribution mechanisms please refer to the Fees and staking rewards distribution module. For more information regarding KIRA’s economics, please refer to the KIRA’s Economics[broken link] page of the Learn section.

Consensus Nodes Ranks and Statuses​

note

The status of a consensus node and the status of its staking pool are two distinct things. Consensus nodes that have not created a staking pool or have disabled it can still participate in the consensus process and produce blocks, but they will not be eligible for any rewards.

KIRA network uses a ranking system to incentivize consensus nodes to stay online, or active, and create a friendly, competitive environment. The ranking is based on the number of blocks a consensus node produces and the number of missed blocks. If a consensus node signs a block, their rank increases. If a consensus node consecutively fails to sign a block for a certain number of times, they are deemed offline, or inactive, and their rank decreases. The ranking system also includes a mechanism for consensus nodes to temporarily pause their node without affecting their rank, and for the governance to reset all ranks periodically. Inactive consensus nodes are removed from the consensus node set, cannot produce blocks and are unable to perform some actions such as editing their staking pool until they signal they are ready to be active again. If a consensus node is inactive, delegators cannot delegate any tokens; they can only undelegate their stake.

For more information regarding consensus nodes ranking system please refer to the Consensus Nodes Ranking & Status Management section of KIRA’s slashing module.

Consensus Node Faq​

The Cosmos Validator FAQ provides a wealth of information about being a consensus node for anyone interested in learning more about this role.

Parameters​

Staking pool properties

NAMETYPEDESCRIPTION
idintPool’s ID
commissionintDefines the staking pool’s commission rate over block rewards (cf. Untitled)
enabledbooleanDefines if the pool is enabled or disabled. If set to false the pool doesn’t accumulate any reward and delegators are only able to unstake.

CLI Syntax & Examples​

note

Each CLI command and proposal process in KIRA requires specific permissions. These permissions must be added to the account's whitelist or obtained as sudo permissions for direct changes. Refer to the Roles & Permissions documentation for more details.

note

$SIGNER represents the transaction signer's account name or address. For instructions on setting common flags as environment variables, such as $FLAGS_TX and $FLAGS_QR, see the CLI Guide page.

Transactions​

claim-validator-seatSubmit a transaction to claim a consensus node seat in KIRA’s consensus node set.
upsert-staking-poolSubmit a transaction to create or edit a staking pool as a consensus node.

Claiming a Consensus Node Seat​

To claim a seat in the consensus node set, use the claim-validator-seat CLI command. This requires a 2 permission, obtainable through governance (mainnet) or a sudo account (testnet). Ensure your node's unique moniker identifier is pre-set, via the Identity Registrar module, or provide it directly in the CLI command.

Flags

  • $MONIKER: Moniker identifier of the account claiming a consensus node seat.
  • $PUBKEY: Public key of the account claiming a consensus node seat.
sekaid tx customstaking claim-validator-seat \
--from=$SIGNER $FLAGS_TX \
--moniker=$MONIKER [ --pubkey=$PUBKEY ]

To confirm a successful claim, use the validator query which should return the following:

{
  "val_key": "kiravaloper1q0fkns62jl4mfxavxug4rvsp7d4770mfkzupzp",
  "pub_key": {
    "@type": "/cosmos.crypto.ed25519.PubKey",
    "key": "YMPiwZecoXe2m7UrO3hJtl51lYrMCGS+rlGuN1I7dpA="
  },
  "status": "ACTIVE",
  "rank": "49",
  "streak": "49"
}

Creating/editing a Staking Pool​

An active consensus node can use the upsert-staking-pool transaction to create or edit its staking pool. The commission rate must be within 0.01 (1%) to 0.5 (50%).

Args

  • $VAL: Address of the consensus node (kiravaloper...).

Flags

  • $COMMISSION: Commission rate of the staking pool.
  • $ENABLED: Status of the staking pool (default=true).
sekaid tx multistaking upsert-staking-pool \
--from=$SIGNER $FLAGS_TX \
--commission=$COMMISSION --enabled=$ENABLED \
$VAL
Building the future of trustless computing by enabling scalable solutions for resource-intensive applications
2024 KIRA Network, All rights reserved.
Ecosystem
HomeToken & EconomicsBuild on KIRARun a node
Resources
GithubCareersBlogContact us
Community
XTelegramDiscord
2024 KIRA Network, All rights reserved.