Lifecycle of a Validator Explanation

The life cycle of a validator

This article will give a brief high-level overview of what being a validator looks like on the Incognito chain.

Interested in earning block rewards?
Here’s a brief explanation of what to expect >

First, let’s define some key features of Incognito that are relevant to this discussion:

1. Sharding

Most blockchains today are just a single chain of all the nodes in linear succession. With sharding, chains are expanded to consist of a main linear chain, called a beacon chain, and several “shards” branching off the beacon which each handle a portion of the process of block validation. This way, where a single chain can handle n number of transactions per second, a sharded chain can handle n(s) number of transactions, where s is the number of shards.

Screen Shot 2020-03-20 at 12.06.10 AM

The sharding model is designed to be inherently scalable, so that the transaction speed doesn’t suffer with an increasing number of transactions.

2. Proof-of-Stake (PoS) Validation

Most blockchains currently run on a Proof-of-Work (PoW) consensus mechanism, by which your validator earns rewards proportionate to the amount of work your CPU performs. However, this is slow and inefficient for a large scale, and leaves blockchain networks open to majority attacks. With Proof-of-Stake, validators instead stake the network-local coins, in this case PRV, to be entered into the validator pool, from which they will be randomly selected to perform the validation.

Having a pool of available validators that aren’t wasting time and energy competing to complete transactions (like with PoW) enables both Incognito Chain and the validators to be more efficient.

The Incognito validation process

Below is a diagram of the process overview.

The Shards and the Beacon Chain together make up the entire blockchain itself. The Beacon Chain coordinates the different Shards. Currently at 8 Shards, the number of Shards run by Incognito will grow over time with a goal of reaching 64 Shards in the near future.

The selected nodes are within each shard, and are called Validators. The row of icons to the left of the Shards are the Substitutes. Substitutes are nodes that are on hold, waiting to join the Validators. On the far left is the Selection pool, comprised of nodes which are waiting to be randomly selected. The process occurs in just six steps:

  1. You run a node and stake the required 1750 PRV. It is held as collateral in the network until you unstake it and stop running the node.

  2. Your node is placed into the Selection Pool.

  3. The node is then randomly selected to be moved to the Substitutes, currently comprised of eight substitutes per shard.

  4. Substitutes wait two full epochs (one epoch is 350 blocks, currently about 4 hours) before being moved to the Validators. During the waiting period, the substitutes must be online the entire time, and sync all block data for their shard, to be ready for validation.

Later this year (date TBD), if a substitute fails to stay online or sync all block data, it will be moved to a greylist, where they will wait for three epochs before they are returned to the Selection Pool. This is how the system will ensure nodes are healthy enough to perform the job of validation.

  1. Then, the substitute moves to a shard and becomes a validator. Here, the validator nodes sign (verify) blocks which contain transactions. They propose blocks in a Round Robin sequence. Once the transactions are validated, the validating nodes receive transaction fees (in the currency the transactor selected) and block rewards (in PRV). Block rewards are split evenly between the validators of the shard.

  2. Each epoch, the four oldest validators in each shard are recycled back into the Selection pool to be randomly selected again.

As mentioned earlier, in a PoW mechanism, validators are competing to see who can get the nonce the fastest, and receive the reward. With PoS, the competition is removed so the process is less wasteful.

Initial selection is completely random, so each node has equal chance every turn. Validators receive equal rewards split between them, to ensure fairness and profitability for all participants. In addition, Validators on a shard take turns proposing blocks, which are then signed by all validators together. This results in a fair, fast, and scalable process that is energy and cost efficient.

Screen Shot 2020-03-20 at 11.36.20 PM
(Comparison of TPS between various blockchains.)


Validators are given a time window within which they must propose a block, which is equal to the elapsed time of the previous three blocks combined. This ensures consistent time limits which don’t prevent functional blocks from participating, but which limits the time a problem can waste.

As with substitutes that fail their tasks, validators that fail are temporarily moved to the greylist for three epochs and don’t receive their rewards, before being re-entered in the candidate pool. Unlike other PoS instances, with Incognito, you do not lose your staked PRV if your node is moved to the greylist.


Epochs are a measurement of a step in the cycle. Each epoch, validators are cycled through the existing shards to participate in block proposal and validation. The four validators which have been there the longest are released back into the Selection Pool to start the process anew*. Then, the four oldest members of the Substitute group are promoted to Validators, and four random node from the Selection pool are chosen to join the Substitutes. So, every group moves forward in batches of four nodes per shard.

*Note: If you choose to unstake your Node at any point in the process, the unstaking will take place after step 5 of the process. This can potentially cause a long wait, depending on the remaining length of the current cycle.

That’s all there is to it! It’s an automatic, easy process designed to bring fairness and efficiency to block validation. The transaction fees allow you to earn various popular cryptocurrencies like BTC or ETH, while earning block rewards in PRV.


So in every shard there is always some validators active, right? How many? And what happens if a validator in that moment goes down?

1 Like

Yes in the (currently) eight shards, validators are grouped into committees of a certain number, which require 2/3 of the vote to validate a proposed block. More on that here. As for what happens if one goes down and how many there are, I’m not sure off the top of my head.

I’ll tag @dungtran and @binh and hopefully they can answer/tag the correct person :slight_smile:


Does this mean that each time your node enters a shard it will earn for two epochs or 21.8 PRV (if you are staking 1750 yourself)? – in your diagram I thought there were 8 validators after further review it seems there are 6 and unrelated to the number of validators in each shard.

It is unclear to me how many validators per shard there are.


Under most circumstances, your node would earn for at least two consecutive epochs, possibly as many as three consecutive epochs.

Each committee shard has 32 validators. 10 of these are reserved for community nodes. The other 22 validators are fixed validators operated by the Incognito team. Each epoch, 4 validators of the community 10, are substituted out for new validators from the preparation pool.


Thank you Mike very helpful.

Is there a circumstance where the node would only earn once? I don’t believe there is since the process removes the 4 oldest validators.

My understanding is before the epoch completes the block results are sent to the beacon chain for each shard (so roughly 43.75 blocks per shard)?

I think there is a need to have all of this information in one place. It’s hard to follow the step by step process that happens during an epoch or even a block. I think a flow chart or something similar would be helpful to visualize the entire process. It could be me since I am more of a visual learner not an auditory learner.

1 Like
  • The Incognito team states that unstaking will not happen until after the next earning epoch. A node in the process of unstaking, therefore, would earn once then be kicked from committee.

  • If your node stopped participating in consensus during its second epoch, your node would be kicked from committee and wouldn’t be rewarded for the second epoch.

The reason for non-participation is irrelevant. It could be a local power/internet outage, act of God, act of toddler, electronic component failure in a pNode/vNode server, etc.

According to @aaron’s post, a “failed” validator would remain in the greylist for 3 epochs or ~12 hours. I do check the status of my nodes on quite frequently and FWIW I’ve never seen a validator(s) listed in the greylist.


The greylist is not active yet. I wrote this post before I was informed of that haha, and have forgotten to edit it. We are currently evaluating the greylist strategy, and once I know, I’ll update with the current status. Everything else is accurate, and thanks for writing the answers!


I made up this flowchart for the path that a node takes. Is this accurate? Is there anything that I should add or remove? I might try to make one for the path of a block as well.



I used a slightly different one in this post


All nodes in the Candidate Pool are staked with 1750 PRV. A node can be online but not staked, and therefore would not be a part of the Candidate Pool. This could be the case for a new vNode awaiting it’s private stake or an unstaked pNode awaiting it’s private stake. These nodes would not be a part of the Candidate Pool (again) until they are fully staked.

Jamie’s graphic is also a very good one.