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 XYZ are deposited in the staking pool of a consensus node V1, an equal number of derivative tokens V1_XYZ are issued in return (similar to AMM LP tokens). These derivative tokens V1_XYZ can be freely moved and traded on and off-chain, while the underlying XYZ tokens remain staked. If V1 is slashed for double signing, the staked XYZ tokens can either be moved to the treasury, a governance spending pool or destroyed, while the derivative tokens V1_XYZ 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 Token Rate Registrar module, which sets bounds on the staking mechanism through the use of three parameters:

Owning some staking pool's derivatives V1_XYZ is equivalent to having some token XYZ staked with consensus node V1. 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 or received KIRA's native staking derivative tokens on the open market, can register those derivatives to the corresponding staking pool to earn 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 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.

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 XYZ can be claimed by providing the respective pool’s derivative V_XYZ 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).