Introduction to Incognito’s DPoS & Incentive Model

Introduction of Incognito’s DPoS & Incentive Model


In this section, we explain more clearly the concepts mentioned below:

  • Credit: Represents the collateral of stakers in the Incognito’s RDPoS model. Based on how the stakers receive the credit, we can categorize it into 2 types: Delegation Credit and Staking credit.

  • Delegation Credit: The credit that each shard’s staker receives when joining the shards’ committee for the first time. It will be revoked if the owner gets slashed out of the committee, or unstakes and gets removed from Incognito. Each shard’s staker can only get 1 credit.

  • Staking Credit: The amount of credit converted from the staking amount of the beacon’s staker. The conversion rate is 1750 PRV equal to 1 credit.

  • Delegating Credit: The act of giving delegation credit to a certain beacon staker of the shard’s staker. The shard’s stakers take part in the beacon committee selection process by delegating their own credits, and they can also delegate other beacon stakers after each epoch.

  • Delegates: These are beacon stakers that can receive credits. They may either be on the waiting list, have joined the beacon committee, or are on the pending list.

  • Delegator: A “delegator” is someone who wants to contribute their credit to a delegate for increasing the probability that the delegate will be selected for the beacon committee.

  • Performance Score: This is the measure of the stability of a beacon validator. This parameter is changed block-by-block according to the below formula. It is designed to incentivize validators to maintain the stability of their node so that they can participate in the consensus process continuously. Performance Score also directly affects the rewards of beacon validators and their delegators, so this is important reference for shard’s stakers to choose the right validator to delegate their credits.

  • Reputation Score: This is the measure of the credibility of a beacon validator. We use it to choose and slash the beacon committee members. This parameter is based on the total amount of Delegation Credit, Staking Credit, and Performance Score of a beacon validator, as the formula mentioned below.

New Solutions

We are introducing a Delegated Proof-of-Stake model specific to the Incognito chain, along with some new metrics that help enhance the security of the network.
These metrics are the credit point and reputation score, which directly affect the selection of beacon committees and the distribution of rewards. Shard’s staker, after receiving credit points, will delegate to the beacon’s staker they trust. In order to be added to the beacon’s list of substitutes, the beacon’s staker needs to stake a minimum amount of PRV and get a minimum amount of delegators. In addition, the total reward of an epoch is divided up equally among the total credits of the beacon committee. For every individual beacon committee validator, however, the actual reward that they and their corresponding delegators receive will change in accordance with their performance score.

Impact on Incognito’s performance

This design creates 3 main advantages:

  • Increase staker’s commitment: With this design, Shard’s stakers need to ensure that their node operates stably in order to avoid being slashed and monitor the beacon validators’ operability through reputation in order to choose reliable beacon validators to delegate to. The beacon validator must ensure their node’s operability, and at the same time, regularly check for updates because contributing to the consensus process will directly affect their reputation score.

  • Increase the security of the network: This design requires the attacker to gain control of at least ⅔ of the total credits of all beacon committee members and their delegators (shard’s stakers) to manipulate the beacon committee. The decentralization of the network is also significantly improved.

  • Rewards are divided more equitably: With the credit-based reward division mechanism, theoretically, there is no difference in the APY on top of every 1,750 PRV staked between the beacon stakers and shard stakers. This design enables equality in reward division between the foundation’s nodes and the community’s nodes.

Protocol details




  • The states of a staker:
    • For beacon stakers, we expect them to have taken part in the Incognito network and be stable during that time. Therefore, we restrict the ability of shard’s stakers to create transaction stakes for beacons rather than letting any user stake to become a beacon validator. The requirement is: Participated in the shard’s committee for 50 epochs, and at those epochs, their voting percentage is greater than 90%. Transaction stakes for beacons must have a minimum staking amount of 87500, equivalent to 50 credits, staked amount can also be added via a special transaction type. The amount of PRV added per transaction must be a multiple of 1750. After staking successfully, the staker will be added to the waiting pool. Here, the staker’s nodes need to synchronize the network’s data and call the shard staker delegates for it. Once the required minimum number of delegators has been obtained and the synchronization is fully complete, the beacon stakers in the waiting pool will be moved to the pending pool.
      • Once added to the pending pool, each staker will have a performance score of 0.5. This list is sorted in descending order based on the reputation score of each validator. The first 32 positions will be selected for the committee. We will calculate the reputation score S of a validator as follows:
        • Eqn1 where SA is the Staking amount, D is the total delegator, and P is the performance score of that validator.
    • While in the pending pool, and not in the committee, a validator can unstake by creating an unstake transaction, this unstake command will be processed in the next epoch.
    • While in the committee, the performance score of each validator will change continuously from block to block, with value ranges from 0 to 1, calculated based on the validators’ voting behavior:
      • Eqn2 if validator_i’s vote is correct in block t.
      • Eqn3 if validator_i’s vote is invalid in block t.
    • In case the performance score of a validator at the end of the epoch is lower than 0.3, we will slash this validator.
    • After validators successfully execute unstake orders, or are slashed from the committee, we will lock their staked amount in t epochs: Eqn4. t is the number of locked epochs, P is the validator’s performance score.

New incentive mechanism



  • The new reward distribution mechanism has absolutely no effect on the previously introduced tokenomics. The total supply and the amount of PRV released each year will not change, we only change the way we distribute the rewards to the validators.
  • In the diagram above, we specify where the rewards come from and reiterate the sharing of the total reward at each epoch for the DAO address. Regarding the reward distribution for validators, we summarize the steps:
    • After the beacon committee calculates the total reward of an epoch and shares a portion with the DAO address, the rest is divided equally among the total credits associated with the beacon committee. This total credit includes credits converted from the staked amount of the beacon stakers on the current committee and the total credit delegated to them.
    • Once the amount of reward per credit has been obtained, each beacon validator will know the total reward that they and their delegators can receive. However, the amount of reward they actually receive will be modified in accordance with the performance score of each beacon validator. For example:
      • Let base_reward be the reward for each credit at an epoch
      • bi be the beacon validator i
      • SABi be the total staking amount of bi
      • PBi be the performance score of bi
      • DjBi be the delegator j of bi
      • rewX be the reward that a validator X received
      • rewBi
      • rewdjbi
  • Thus, theoretically, shard’s stakers and beacon’s stakers would both have the same APY. But in reality, each beacon validator’s performance score is different, resulting in a change in the number of rewards that stakers can receive. Accordingly, shard’s stakers will have the incentive to find high-performance beacon stakers to delegate, and low-performance beacon validators will gradually lose credibility from shard’s stakers.
  • To make it easier to understand, we will simulate the APY of each credit in the following conditions:
    • Total shard’s stakers: 3204
    • Number of the beacon committee members: 24 (7 foundation’s node and 17 community’s node)
    • The staked amount of each beacon’s validator from the foundation: 350000 PRV (200 credits)
    • The staked amount of each beacon’s validator from the community: 87500 PRV (50 credits)
    • Assume that all delegates of shard’s stakers are beacon committee members, so the total number of credits that belong to beacon committee is 5454.
    • With the current Mainnet parameters:
      • Block-time: 20s.
      • Epoch-time: 350 blocks.
      • The number of epochs per year: 4508.
      • Base reward for a block (block-time 20s): 0,693333 PRV
      • Reward amount of an epoch: 1941,3324 PRV
        • Reward for DAO (10% of total reward, reduced by years): 194,13324 PRV
        • Reward amount for beacon committee and their delegators (TotalReward): 1747,19916 PRV
      • baserew
      • Assume performance of all beacon validators is 100%:
        • Reward that a beacon’s validator from the community bi receives per epoch:
          • rewBi
          • rewbi
          • rewbi2
        • Reward that a delegator receives per epoch:
          • rewdjbi
          • rewdjbi2
        • Thus, after each epoch, each credit is received baserew3 and the reward it gets in a year is:
          • rewperyear
        • So, with this setup, the expected APY per credit is 82,52%.


  • Compare the new model with the old design, in the case of full 32 validators in the beacon committee.
  • Note that the problems with beacon committees in the old design only occurred in theory, in practice, Incognito-chain does not yet allow staking beacons.
Old beacon staking design New model
Control ⅓ committee 115500 PRV 1/3 of the entire network’s credits, including shard staker’s credit and credits converted from beacon staked amount.
Incentive mechanism Inequality between beacon committees and shard committees APY is the same for each 1,750 PRV staked.
Create block ⅔+1 foundation nodes ⅔+1 credits from committee & ⅔+1 foundation nodes

Interesting idea, thanks for the efforts in trying to decentralize to remove single point of failures! :+1:

Is delegation an active choice from the shard validators (stakers)? Will beacon validators have to contend in a populistic beauty pageant to try to score more votes?

So there is no monetary incentive to run a beacon validator? Unless you account for the operating cost is 1/(50+n) of running an equivalent (50+n) number of shard validator nodes? At the same time, isn’t there’s an increased risk of putting all your PRV eggs in one basket? As in, if you get a power outage during committee, the potential loss in reward is greater?

Let me know if I misunderstood the whole model. I’m a bit tired and I may have read the text too fast. :crazy_face:

1 Like

To me, continuous earning. Whereas shard stakers are in committee at different times and earn money in cycle whose duration increase by #shard_validators, the beacon stakers will always be in committee unless their credits and performance scores are low.

1 Like

Either Appendix should go below or it should be “below formula”.

not 5 x 17 but 50 x 17

1 Like

Aren’t the beacon nodes rotated as well? Or does “Swap by credit & voting score” mean that you have to constantly beat the top 32 nodes in credit?

Not rotated. As long as you keep two things decently: credit (i.e. staking power), voting score (i.e. performance), you are always in the committee imo. Ofc, you must be one of the top 32 in terms of staking power :slight_smile:

1 Like

Ok, so in that case it becomes a competition in persuading the most number of shard validators that your beacon node is the awesomest or getting the most votes with any other questionable method.

By the way. If you give me your shard stake credit I’ll send nudes.


As long as you keep that awesomeness :slight_smile: , yes. However, in case of slashing (no reward, maybe penalty at future) or low performance (low reward), be ready for angry shard validators who want even your clothes for compensation :slight_smile:

I think this is so bullish for PRV. Hey beacon committee candidates, you should start collecting 85000 PRV (very cheap now, ~$26000).


It is great to hear you feel that way! I think Incognito-chain will have a significant improvement in decentralization in the new version. We all know that decentralization is one of our ultimate aims, and the Incognito team is still working toward that goal.

Your mind is still sharp! In this design, there is no difference in APY between beacon’s staker and shard’s staker. This design aims at increasing the commitment of beacon’s stakers in their work of helping maintain the security of the network. Shard’s staker and beacon’s staker will be different in operation. With shard’s staker, you need to regularly check the performance of beacon validators to choose the right delegate. With beacon’s staker, you just need to control node’s performance.
Each person will have their own strategy. Some like to split assets and own many shard’s nodes, with flexible staking/unstaking capabilities, some choose to put all their eggs in one basket.


Yah, in terms of user experience, it’s continuous earning. In fact, you will get credit-based rewards. The team will announce soon the detailed implementation part.

Silly me! Thank you, I updated the post


You guys are right! With this design, the beacon’s stakers and the shard’s stakers will manage each other. Beacon’s staker must find a way to gain the trust of shard’s stakers to get their credits. Conversely, the shard’s stakers have the power to change their favorite delegate and participate in the beacon committee selection process, right?


@hyng Beacon validator is already for staking?

Hey @GalaxyNode.IO, yes it is.
We will be publishing a guide for users who want to stake and become Beacon validators tomorrow. Can’t wait to see more validators to join and secure the beacon chain :muscle: