Delegators

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.

Consensus nodes on the Kira Network 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).

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.

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 The token rates registrar module, which sets bounds on the staking mechanism through the use of three parameters:

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.

Delegators can enable or disable the auto compounding mode 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.

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.

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.

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.

With auto-compounding activated, rewards are automatically reinvested, enhancing 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.

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.

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).

Retrieve the list of all delegators associated with a specific staking pool using the staking-pool-delegators query.

Query real-time metrics and parameters of all existing staking pools.

Retrieve information about pending undelegations using the undelegations query. This query allows for filtering based on the delegator's address and the validator's address.

Retrieve compounding information for a specific delegator using the compound-info query.

Retrieve all outstanding rewards for a specific delegator using the outstanding-rewards query.