Skip to main content

Delegators

Overview​

Delegators are KIRA token holders who want to participate in network security by delegating assets as collateral to one or more consensus nodes' staking pools in exchange for a share of their revenue. Because delegators share revenue and responsibility with their chosen consensus nodes, they should carefully consider which nodes to delegate to and monitor their stakes regularly. Consensus nodes can also be delegators, but they are not required to. Staked assets are directly affected by the conduct of the elected nodes, so it is important for delegators to exercise diligence and diversification in their choices.

Native Liquid Staking​

KIRA’s Consensus nodes have staking pools that are designed equivalently to regular AMM liquidity pools like Uniswap, in order to achieve native liquid staking. When a certain number of tokens <denom> are deposited in the staking pool of a consensus node V<ID>, an equal number of derivative tokens V<ID>/<denom> are issued in return (similar to AMM LP tokens). These derivative tokens V<ID>/<denom> can be freely moved and traded on and off-chain, while the underlying <denom> tokens remain staked. If V1 is slashed for double signing, the staked <denom> tokens can either be moved to the treasury, a governance spending pool or destroyed, while the derivative tokens V<ID>/<denom> representing them would lose their 1-to-1 peg (similar to impermanent loss in AMM).

note

E.g.: If 50% of XYZ tokens staked with block proposer V1 get slashed, unstaking 2 V1/XYZ from V1's pool would only return 1 XYZ.

Staking Pools & Consensus Nodes Status​

In KIRA's network, each consensus node operates its own staking pool where delegators can stake their assets. The staking pool has a unique ID and is linked to the consensus node's address. The consensus node has control over the staking pool's status and can enable or disable it, as well as set the commission rate on block rewards. In addition, a consensus node can be active, inactive, paused, or jailed depending on its performance, behavior or choice. While it is important to understand that the status of the staking pool is independent of the status of the consensus node, if a consensus node's status is inactive, paused, or jailed , and/or if its staking pool is disabled, delegators are not able to delegate any additional tokens to that node’s staking pool. They will only be able to undelegate their existing stake.

For more information regarding consensus nodes status and ranking system please refer to the Consensus Nodes Ranking & Status Management module. For more information regarding consensus nodes staking pool status please refer to the Consensus nodes section.

Delegating and Associated Parameters​

KIRA allows users to delegate and pay execution fees with any token that has been whitelisted by governance. To ensure proper network functionality and security, specific management rules and limitations are defined and curated for each foreign token, such as exchange rates and staking pool rewards allowance. These rules are monitored by the Token Rates Registrar module, which sets bounds on the staking mechanism through the use of three parameters:

  • stake_cap : Sets the maximum share (%) of staking reward a given whitelisted staking token will be entitled per staking pool to prevent a malicious user from diluting the pool with any particular token in order to claim all the rewards. Setting specific shares also simplifies reward distribution by sidestepping the need to track how much eligible staking tokens are worth in terms of USD or KEX.
  • stake_min: Sets the minimum delegation and undelegation amount per transaction for a particular token. This is designed to prevent dust spam attacks, where an attacker might attempt to disrupt block production by continuously staking or withdrawing trivial amounts of tokens with numerous accounts. Importantly, this parameter also ensures that a user cannot undelegate an amount that would leave behind a residual stake less than this minimum. Such a residual would be locked and become non-withdrawable. Detailed considerations related to dust-spam can be found in the Fees and staking rewards distribution section.
  • fee_rate : Sets the conversation rate for foreign tokens in terms of KEX to use them as execution fees. fee_rate is also used to determine if the stake_min value is respected in case of delegation or if min_delegation_pushout is reached when a staking pool reaches its maximum delegators capacity.

For more information regarding delegators staking rewards distribution please refer to the Fees and staking rewards distribution page.

Registration Mechanism for Offshore Staking Pool Delegators​

As explained earlier, owning some staking pool's derivatives V<ID>/<denom> is equivalent to having some token <denom> staked with consensus node V<ID>. However, because the Cosmos SDK does not provide a hook on token transfers (yet?) and derivatives can be traded freely inside or outside the KIRA network, it is impossible to track staking pool delegators' shares in real time. To solve this problem, KIRA has implemented a registration mechanism where "offshore" delegators, such as users or smart contracts that acquired KIRA's native staking derivative tokens on the open market, can register those derivatives to the corresponding staking pool to earn the corresponding rewards. Additionally, each staking pool performs a balance check on its current delegators whenever it receives rewards (whenever the consensus nodes produces a block) and will automatically deregister any registered delegators that do not hold more than the minimum stake_min of derivative tokens.

Managing Staking Rewards​

Claiming Rewards​

With auto-compounding activated, rewards are automatically reinvested, increasing the delegator's stake. However, the staking derivatives, representing these newly compounded rewards, aren't instantly transferred to the delegator's address to reduce overhead. They accumulate in the staking pool and must be claimed manually. Conversely, if a delegator decides not to use auto-compounding, they will have to manually claim all the rewards they accrue. Hence, in both scenarios, the delegator must manually intervene to include their rewards or rewards’ derivatives into their active balance.

Enabling Auto-compounding​

Delegators have the flexibility to decide how they manage rewards earned from staking. They can opt for automatic reinvestment through the auto-compounding feature or claim them manually. This decision can be made for any token eligible for staking, as determined by the Token Rates Registrar . When enabled, rewards are automatically added to the delegator's stake. However, the corresponding staking derivatives are not sent to the delegator's address, as this would be too much of an overhead for the module to handle. Instead, they are simply accumulated in the staking pool and become claimable in the same way as standard rewards. In other words, when a user disables auto compounding, it will have to claim its rewards manually; when it is enabled, it will have to claim its newly issued staking derivatives manually. Each delegator has their unique auto-compounding schedule, distributing the computational demands and preventing the network from being overwhelmed by simultaneous compounding events. Configurations for this feature are maintained per user. Delegators can enable this feature for all tokens or for particular ones.

Auto-compounding operates based on a consistent interval set across the network by the autocompound_interval_num_blocks network property. The exact block at which a user's rewards get compounded depends on when they activate this feature. For example, with a network interval set at 10,000 blocks, a delegator enabling auto-compounding at block 3 will see their rewards compounded at blocks 10003, 20003 and so on. This property is set to 17280 blocks at genesis.

Undelegating & Cooling Period​

A delegator can undelegate their stake at anytime to get back its original tokens. Any undelegation will trigger a fixed cooling period during which the stake remain locked and do not yield any reward. Once the cooling period expires, staked tokens <denom> can be claimed by providing the respective pool’s derivative V<ID>/<denom> which are then burned. The cooling period is the same for all staking tokens and defined by the governance through the following unstaking_period network property (1 month by default).

Delegators Push Out​

KIRA has a feature that protects against dust spam attacks by limiting the maximum number of delegators for each individual staking pool with a network property called max_delegators (which is set to 100 by default). If this maximum number of delegators is reached, new delegators will need to provide a higher stake than the smallest delegator in the pool in order to push them out. To prevent large stakeholders from easily pushing out smaller delegators from good consensus nodes, the minimum required stake to push out a delegator is set by the min_delegation_pushout property (which is a multiplier of the smallest stake value, 10 by default). This network property can be adjusted by KIRA's governance and increased as the network grows. When a delegator is pushed out, they automatically receive any outstanding rewards they are owed.

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​

delegateDelegate to a pool.
undelegateStart undelegation from a pool.
claim-rewardsClaim rewards from a pool.
claim-undelegationClaim matured undelegation.
claim-matured-undelegationsClaim all matured undelegations in a single transaction.
set-compound-infoSet auto compounding mode.
register-delegatorRegister as a pool delegator when acquiring pool derivatives externally.

Delegating​

Delegate tokens to a specific staking pool. This action locks the specified amount of <denom> tokens to a staking pool using the consensus node’s address. It returns the corresponding pool’s derivative V<ID>/<denom>. The delegation amount cannot be lower than stake_min. Delegation is only possible to an active consensus node.

Args

  • $VAL: Consensus node’s address (kiravaloper...).
  • $COIN: Comma-separated list of coins and their amounts to delegate in the format <amount><denom> (e.g., 20000ukex).
sekaid tx multistaking delegate \
--from=$SIGNER $FLAGS_TX \
$VAL $COIN

Undelegating​

Undelegating burns the corresponding V<ID>/<denom> derivatives and initiates the claim of any outstanding rewards/compounds. The undelegated <denom> tokens are assigned an undelegation ID and become claimable after the unstaking_period. The undelegation amount must meet the stake_min requirements.

Args

  • $VAL: Consensus node’s address (kiravaloper...).
  • $COIN: Comma-separated list of coins and their amounts to undelegate in the format <amount><denom> (e.g., 20000ukex).
sekaid tx multistaking undelegate \
--from=$SIGNER $FLAGS_TX \
$VAL $COIN

Set Compounding Mode​

Delegators can activate or deactivate auto compounding for their staked tokens. This can be set for all tokens or specific denominations.

Args

  • $ALL: Set compound mode on all tokens (true/false).
  • $DENOM: Set compound mode on a specific token denomination (e.g., ukex).
sekaid tx multistaking set-compound-info \
--from=$SIGNER $FLAGS_TX \
$ALL $DENOM

Claim Rewards/pool’s Derivatives​

Delegators can claim all outstanding rewards (or pool’s derivatives if auto-compounding is active).

sekaid tx multistaking claim-rewards \
--from=$SIGNER $FLAGS_TX

Claim Undelegation​

Undelegations can be claimed using corresponding delegation ID and at the end of their respective unstaking_period.

Args

  • $ID: Undelegation ID.
sekaid tx multistaking claim-undelegation \
--from=$SIGNER $FLAGS_TX \
$ID

Claiming Matured Undelegations​

claim-matured-undelegations, allows users to submit a transaction to claim all matured undelegations in one action. It's a convenient way to handle multiple matured undelegations without specifying each ID individually.

sekaid tx multistaking claim-matured-undelegations \
--from=$SIGNER $FLAGS_TX

Delegator Registration​

Users or smart contracts that have acquired KIRA’s native staking derivative tokens can register as delegators to the respective staking pools. Registration is subject to the minimum staking amount requirement stake_min.

sekaid tx multistaking register-delegator \
--from=$SIGNER $FLAGS_TX
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.