Fees and staking rewards distribution

Concept

Committee-based blockchains are among the most popular alternatives to proof-of-work based blockchains, such as Bitcoin. These blockchains use a committee, a.k.a consensus nodes set or “validator” set, that executes Byzantine fault tolerant distributed consensus to determine the next block to add to the blockchain. Unlike Bitcoin, where one creator produce a block based on probabilities, in a committee-based blockchain blocks are cooperatively created. As such, properly designing the consensus rewarding schemes is crucial to incentivize consensus nodes in achieving consensus while preventing centralization forces from arising, such as those stemming from miner extractable value (MEV) leakage. 

By designing the consensus rewarding schemes effectively, committee-based blockchains can achieve a balance between decentralization and incentivization.

Network Inflation & Dynamic Adjustments

KEX, the native asset of the KIRA network, undergoes controlled inflation as a strategy to stimulate activity and engagement. Its inflation parameters are defined by network governance, which, in tandem with the Token Rates Registrar, orchestrates a harmony of incentives that align with the broader strategic vision of the network. The central ambition here is not just about maintaining KEX's economic value, but also ensuring the very security fabric of the network through stakeholder retention and active transactions.

Here's a detailed look at the relevant network properties:

inflation_rate: Specifies the KEX inflation percentage.

Default: 18

Range: 0 (Minimum) to 50 (Maximum)

inflation_period: Denotes the time duration in seconds over which the current KEX supply is inflated based on the inflation_rate.

Default: 31557600 (equates to 1 year)

Range: 2629800 (roughly a month) to 31557600

max_annual_inflation: This sets a ceiling on the yearly percentage growth of the KEX total supply from the original genesis time.

The inflation is calculated on a per-block basis and adjusts dynamically through periodic snapshots of the KEX supply taken at the start of each inflation_period. This mechanism guarantees precise reward allocations and compliance with the set max_annual_inflation cap. It accounts for potential inflationary variations that could emerge from diverse sources like the UBI module or the L2 burning mechanisms. In this context, the network proactively assesses for any projected cap breaches and modulates minting from these sources, ensuring the network's stability is always maintained.

Inflation Equation

Given:

SstartS_{start}Sstart​﻿ = KEX token supply at the start of the inflation_period

RRR﻿ = inflation_rate

TblockT_{block}Tblock​﻿ = Time for a single block

The inflation for each block is computed as:
Inflation for block=Sstart×Rinflation_period×Tblock\boxed{\text{Inflation for block} = \dfrac{S_{\text{start}} \times R}{\text{inflation\_period}} \times T_{\text{block}}}Inflation for block=inflation_periodSstart​×R​×Tblock​​﻿​

Example over a period of 3′600 seconds 3'600 \text{ seconds}3′600 seconds﻿ : 
For a starting KEX token supply at T1\small T1T1﻿ of 300’500’000\small 300’500’000300’500’000﻿, an inflation_rate of 15\small 1515﻿%, and an inflation_period of 31′557′600\small31'557'60031′557′600﻿ seconds, all delegators staking their coins from T2−T1=3′600 seconds\small T2-T1 = 3'600 \text{ seconds}T2−T1=3′600 seconds﻿ would cumulatively qualify to claim 300’500’000×0.1531′557′600×3′600≈5142 KEX\small\dfrac{300’500’000 \times 0.15}{31'557'600} \times 3'600 \approx 5142 \text{ KEX}31′557′600300’500’000×0.15​×3′600≈5142 KEX﻿ at T2\small T2T2﻿.

Inflation and Fees Distribution Mechanisms

This section explores how block and fee rewards are calculated for each participant: Consensus nodes and Delegators. Both play distinct roles in maintaining and securing the KIRA network, and their reward mechanisms are underpinned by specific parameters that measure their contributions and engagement. For Consensus nodes, it is the performance parameter that evaluates their consistency and efficiency in the network's consensus. In contrast, for Delegators, it's about the magnitude of their stake, representing their vested interest and commitment to the network. These foundational parameters ensure that rewards are allocated fairly, recognizing genuine efforts and investments in the network's growth and stability.

Rewards are allocated to the proposer and its associated staking pools at the beginning of the following new block. Make sure to account for this one-block lag when considering rewards allocation across all roles in the network.

Consensus nodes rewards

Consensus nodes are not rewarded based on the amount of stake backing them. Instead, they charge a self-defined commission rate on block rewards (KEX inflation). They also benefit from up to 50% of fee rewards, which consist of a basket of different tokens used for paying transaction fees, including KEX. This percentage is defined by the validators_fee_share network property set by governance.

For more information regarding network consensus nodes commissions please refer to the Consensus nodes & staking pools - Staking pools status & commissions module.

Performance parameter

A critical aspect of reward distribution for Consensus nodes is the performance parameter, denoted as PPP﻿. This parameter evaluates a node's participation in the network consensus. Specifically, it measures how often that node has successfully signed blocks over the last snapshot-period, which defaults to 1000 blocks. The PPP﻿ value is then used to scale its rewards when it poposes a block; if PPP﻿ is below 100%, the node will only receive a corresponding fraction of the available rewards.

P=NsignedSperiod\boxed{P = \dfrac{N_{signed}}{S_{period}}}P=Speriod​Nsigned​​​﻿​

Block rewards distribution works as follow:

Assuming a block CCC﻿ yielding KKK﻿ukex, if CCC﻿’s proposer has a commission rate RRR﻿ and a performance PPP﻿ , it will be entitled to the following block reward BRcBR_cBRc​﻿: 

BRc=K∗R∗P\boxed{BR_{c} = K*R*P}BRc​=K∗R∗P​﻿ 

E.g: assuming a block yielding 100 KEX, if its proposer has a commission rate set to 30% and a current snapshot-period-performance of 50%, it will only receive 15 KEX and 15 KEX will be transferred to the community treasury. The remaining 70 KEX are split between its delegators and the proposer itself IF it has a self-stake. 

Fee rewards distribution works as follow:

The amount of fee rewards a block proposer will receive for a current block CCC﻿ carrying a basket of fee rewards [uethc,ubnbc,...,u<denom>c][\texttt{ueth}_{c},\texttt{ubnb}_{c},...,\texttt{u<denom>}_{c}][uethc​,ubnbc​,...,u<denom>c​]﻿ from its transactions, given a current network property validators_fee_share VFSVFSVFS﻿ and the proposer's current performance PPP﻿, is [Frcueth,Frcubnb,...,Frcu<denom>][Fr^\texttt{ueth}_{c},Fr^\texttt{ubnb}_{c},...,Fr^\texttt{u<denom>}_{c}][Frcueth​,Frcubnb​,...,Frcu<denom>​]﻿ with: 

 Frcu<denom>=u<denom>c∗VFS∗P\boxed{Fr^\texttt{u<denom>}_{c} = \texttt{u<denom>}_{c} * VFS * P}Frcu<denom>​=u<denom>c​∗VFS∗P​﻿​

Delegators rewards

The distribution of remaining rewards incentives to delegators is proportional to their shares, which are calculated in two distinct ways. Delegators' shares regarding block rewards are determined by their global stake (total staked to all consensus nodes), while the shares regarding fee rewards are determined by the stakes they have delegated locally (total staked to the block proposer). This means that consensus nodes with less stake and greater implied risk will offer better returns on investment to delegators than those with more stake and lower implied risk, provided they do not trigger any slashing events. This incentivizes delegators who are in the network solely for profit to gradually shift their preferences to lower-staked consensus nodes that gain a sufficient amount of reputation in order to maximize their revenues. As a result, stakes across consensus nodes will tend to be evenly distributed, preventing the centralization of stakes among a few consensus nodes.

Whitelisted tokens that are eligible for staking, including KEX, are entitled to a limited amount of rewards (block or fee rewards) as determined by governance through their individual Token Rate Registrar's parameter reward_cap. Allocating a defined percentage of rewards to each eligible staking token has the effect of attracting users from other networks. This is because if no one is staking a specific token, its annual percentage yield (APY) is infinite as no one is able to claim the respective share of rewards, which are instead sent to the community treasury. This incentivizes users to stake these tokens in order to receive a share of the rewards.

Delegators shares

Understanding the calculation of delegators shares is important due to the system's inherent token diversity. The key takeaway is that a delegator's share SDS_{D}SD​﻿ is obtained by calculating the distinctive share SDi<denom>S_{D_{i<denom>}}SDi<denom>​​﻿ for each of the eligible staking tokens i<denom>i_{<denom>}i<denom>​﻿. This allows to avoid comparing each token nominal value, or any other reference value, which would be an unnecessary overhead. The delegator's share SDS_DSD​﻿ is then calculated by summing each SDi<denom>S_{D_{i<denom>}}SDi<denom>​​﻿ multiplied by the corresponding token's reward_cap RCi<denom>RC_{i<denom>}RCi<denom>​﻿:

SD=∑i=1nSDi<denom>∗RCi<denom>\boxed{S_D = \sum_{i=1}^{n} S_{D_{i<denom>}} * RC_{i<denom>}}SD​=i=1∑n​SDi<denom>​​∗RCi<denom>​​﻿​

The difference lies in whether the calculation is intended to represent the delegator's global share for block rewards, which is determined by considering all different tokens staked by the delegator in the network, or the local share for fee rewards, which is determined by considering only the tokens staked by the delegator in the current block proposer's staking pool.

Block rewards distribution works as follow:

Assuming a block CCC﻿ yielding Kc∗R ukexK_c*R \texttt{ ukex}Kc​∗R ukex﻿ (RRR﻿ being the proposer commission rate), a delegator with a local share SDS_DSD​﻿ will be entitled to the following block reward BrcBr_cBrc​﻿: 

Brc=K∗R∗SD\boxed{Br_{c} = K*R*S_D}Brc​=K∗R∗SD​​﻿ 

Fee rewards distribution works as follow:

Given a current block CCC﻿ yielding a basket of fee rewards [uethc,ubnbc,...,u<denom>c][\texttt{ueth}_{c},\texttt{ubnb}_{c},...,\texttt{u<denom>}_{c}][uethc​,ubnbc​,...,u<denom>c​]﻿, with VFSVFSVFS﻿ the current validators_fee_share, a delegator with a global share SDS_DSD​﻿ will receive [Frcueth,Frcubnb,...,Frcu<denom>][Fr^\texttt{ueth}_{c},Fr^\texttt{ubnb}_{c},...,Fr^\texttt{u<denom>}_{c}][Frcueth​,Frcubnb​,...,Frcu<denom>​]﻿ with 

Frcu<denom>=u<denom>c∗SD∗VFS\boxed{Fr^\texttt{u<denom>}_{c} = \texttt{u<denom>}_{c} *S_D*VFS}Frcu<denom>​=u<denom>c​∗SD​∗VFS​﻿ 

Parameters

N/A

CLI syntax & examples

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. $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 flags configuration section

Governance

N/A

Transactions

N/A

Queries

query distributor

fees-treasury - Get fees treasury.

snapshot-period - Get snapshot period.

snapshot-period-performance - Get the current performance for a given consensus node.

fees-collected - Get fees collected.

Current Performance of a Given Validator

Retrieve the current performance of a specific validator using the snapshot-period-performance subcommand followed by the validator’s address.

Args

$ADDR Address of the consensus node.

Bash

Copy

sekaid query distributor snapshot-period-performance $ADDR $FLAGS_QR | jq

Treasury

Fetch the treasury details using the fees-treasury subcommand.

Bash

Copy

sekaid query distributor fees-treasury $FLAGS_QR | jq

Performance Snapshot Period

Retrieve the snapshot period performance details using the snapshot-period subcommand.

Bash

Copy

sekaid query distributor snapshot-period $FLAGS_QR | jq