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.

Rewards distribution

The current reward distribution system does not take into account MEV, but this will be addressed by pipelining rewards and updated at a later date

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, as well as benefit from up to 50% of fee rewards (defined the validators_fee_share parameter defined by governance). However, consensus nodes are also subject to a performance parameter called snapshot-period-performance, which evaluates their participation in the network consensus as the number of blocks they have signed over an arbitrary numbers of blocks (snapshot-period, 1000 blocks by default). If a consensus node has a snapshot-period-performance below 100%, it will only receive the corresponding percentage of rewards, with the remaining amount being sent to the community treasury.

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

Block rewards distribution works as follow:

Assuming a block CCC﻿ yielding Kc ukexK_c \texttt{ ukex}Kc​ 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 10 KEX, if its proposer has a commission rate set to 30% and a current snapshot-period-performance of 50%, it will only receive 1.5 KEX and 1.5 KEX will be transferred to the community treasury. The remaining 7 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∗PVFS\boxed{Fr^\texttt{u<denom>}_{c} = \dfrac{\texttt{u<denom>}_{c} * P}{VFS}}Frcu<denom>​=VFSu<denom>c​∗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>. 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>cVFS][\dfrac{\texttt{ueth}_{c},\texttt{ubnb}_{c},...,\texttt{u<denom>}_{c}}{VFS}][VFSuethc​,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∗SDVFS\boxed{Fr^\texttt{u<denom>}_{c} = \dfrac{\texttt{u<denom>}_{c} *S_D}{VFS}}Frcu<denom>​=VFSu<denom>c​∗SD​​​﻿ 

Rewards distribution (future update)

To achieve this, all rewards are pipelined (accumulated during a period before being distributed) using the Fee Reward Distributor v1 module which distributes a percentage of all the accumulated execution fee rewards (paid by users) to all ACTIVE validators — INACTIVE validators aren’t entitled to any reward. The exact percentage of fee rewards (decimal between 0 and 1) that is granted to validators is configurable using validators_fee_share in the network properties (default 50%).

However, depending on the size of the validator set and the denomination of a token, the given token might not be sufficiently divisible to be split equally. Furthermore, although chances to produce a block are equal among all validators in KIRA, fee rewards cannot be distributed “per block” to the proposer as this give rise to a range of challenging problems such as MEV, spamming, or DDOS incentivization.

Hence, to mitigate such cases as much as possible and ensure a fair distribution, rewards are averaged over a period of NNN﻿ blocks snap_period and distributed proportionally to proposers individual participation to further incentivise staying online. Because averaged rewards are distributed in each block, they can be visualized in real time in the network explorer.

Distribution works as follow :

A snapshot of all the current balances [S¹B,S²B,...,SⁿB][S¹_B,S²_B,...,Sⁿ_B][S¹B​,S²B​,...,SⁿB​]﻿ snap_balances at block BBB﻿ snap_block of the different tokens accumulated by the C=[B,B+N]C = [B,B+N] C=[B,B+N]﻿module is taken. 
For each block C=[B,B+N[C = [B,B+N[C=[B,B+N[﻿  , CCC﻿’s proposer is entitled to a MAXIMUM amount of rewards [R¹max,R²max,...,Rⁿmax][R¹_{max},R²_{max},...,Rⁿ_{max}][R¹max​,R²max​,...,Rⁿmax​]﻿ for each token iii﻿ listed in the snap_balances so that 

Rⁱmax=floor(SⁱBN)\boxed{Rⁱ_{max} = floor (\dfrac{Sⁱ_B}{N})}Rⁱmax​=floor(NSⁱB​​)​﻿ (we should only send non 0 amounts)

However, the finalfinalfinal﻿ amount of rewards CCC﻿’s proposer will actually receive is proportional to its participation which is defined by taking the ratio of the number of blocks it signed during N  NN﻿, blocks_signed BsignedNB^N_{signed}BsignedN​﻿, to the period NNN﻿, so that 
 Rⁱfinal=floor(SⁱBN∗BsignedNN)\boxed{Rⁱ_{final} = floor (\dfrac{Sⁱ_B}{N} * \dfrac{B^N_{signed}}{N})}Rⁱfinal​=floor(NSⁱB​​∗NBsignedN​​)​﻿​

Meanwhile new incoming fee rewards are being accumulated and when C=B+NC = B+NC=B+N﻿,  a new snapshot snap_balances is taken to repeat the process.

Bash

Copy

{
  snap_period: <integer>,
  snap_block: <integer>,
	snap_balances: [ { 
		denom: <string>, 
		amount: <integer> }, 
	{ ... }, ... ]
}

Parameters

CLI functions description

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

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

$VAL*

string

Consensus node’s address kiravaloper...

Current performance of a given validator

Bash

Copy

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

Treasury

Bash

Copy

sekaid query distributor fees-treasury $FLAGS_QR | jq

Performance snapshot period

Bash

Copy

sekaid query distributor snapshot-period $FLAGS_QR | jq

All fees collected 

Bash

Copy

sekaid query distributor fees-collected $FLAGS_QR | jq