[Proposal] to increase de number of active validators to 21

Hello, xDAI community,

The xDai network is currently limited to 19 validator seats on the mainnet. We understand these limits as an initial situation to let a controlled launching of the network in case of possible not expected situations that may occur.


  • the time that the network has been working properly with 19 validators.
  • that more validators are waiting to be part of the active validators.
  • A greater number of validators improves the decentralization of the network and the confidence of the users.

We believe it is time to propose to the community to increase the list of active validators to 21.

The reason for asking to advance only 2 more slots is because we believe that decentralization is a process that must be conquered over time, and growing in decentralization slowly helps to discover possible problems not contemplated. In addition, there are already several validators that are currently in and out of the list of active validators, and they are incurring costs and deserve to be on the list of active validators.
It also allows delegators to have more possibilities to choose where to delegate.

This is the initial debate, we will soon submit the proposal to a vote. Please, share your opinion.


It’s great to see the protocol working as designed. We (Nethermind) also think that increasing the number of active validators will benefit the xDai ecosystem in general.

Thanks for starting this thread. In view of the lower amount of $Stake needed to become a validator it seems of major importance to understand the impacts for xDAIChain.

The economic reasoning and the importance for decentralisation are points you mention, I go along with these, and will clearly support.

But also I like to have some more insight to the implication it might have for security and speed of xDAIChain. Unfortunatly my knowledge about the tech behind is too poor to figure this out myself.

I can guess:
1) the more validators the higher the probability of one behaving malicious OR the more validators the higher the probability that malicious behaviour will be detected.

2.) speed might be higher with more validators cause there is more computing power OR it might be lower cause there is more syncronisation neccessary.

Most likely adding just two more slots won’t make much difference, but anyway I would be glad if someone with more technical knowledge can give a comment on this.

Among the risks of increasing the number of validator nodes are that the new validators will be from existing entities, creating a concentration of stakeholders and validators that could be used maliciously against the network. However, it is not the case because the two validator nodes waiting to enter are not related to the existing ones.

Another risk we may encounter is that the new validator nodes do not offer a correct quality, producing delays in the network, however, is difficult to be a serious problem for the network because for a network stall to occur it would take 33% of the validator nodes in an incorrect state and here we are proposing an increase of validator nodes of less than 10%. In addition, the validator nodes that would enter when increasing the slots, are validator nodes that have already been part of the active set of validators, so they have demonstrated their efficiency previously.

As advantages, the ones already mentioned:

  • higher decentralization

  • higher distribution of block fees and rewards among different players

  • higher security, it will be more difficult to reach 67% control of the network.

  • and others…


Thanks for the reply :pray:. It makes no difference to your arguments but I can’t resist to mention that 2 isn’t less than 10% from 19, so you increase a little more than 10% but the added validators will be less than 10% of total :wink:

1 Like

This proposal is in contradiction to this recommendation in the POSDAO whitepaper:

According to this, 22 would be a better choice. However I think 22 isn’t a good choice either because it’s not recommended to run AuRa consensus with an even number of validators.

Overall I miss a good argument for changing the max. nr of active validators. The whole point of POSDAO is to allow for many more nodes to participate in consensus than AuRa (or HBBFT) would allow for with reasonable performance. The number of candidates being larger than the max. number of active validators is something we should be welcoming as it’s a prerequisite for POSDAO to operate as designed - with validator set randomization per epoch taking place.


seems a valid point to me, so maybe we can decide to increase to 25 candidates (f=8) in the future cause due to the lowered amount of $Stake necessary to become a validator the number of canditates might increase anyway beyond this number.

If I’m not mistaken that even number of validators in AuRa was advised against because it has 50% threshold to get consensus and finality, while POSDAO has 2/3 thus 3f+1 limit, so we always get a threshold + 1 when we are calculating majority, but the bigger the number of validators the less important this guideline is.

19 validators on POSDAO - 13 block finality
21 validators on POSDAO - 14 block finality
22 validators on POSDAO - 15 block finality

Increasing number of validators has it pros and cons:

  • Increasing decentralization
  • Keeping throughput high when some validators fail
  • Need to keep more validators online to achieve finalization
  • Longer chain needed to achieve finalization (potential longer reorgs in case of malicious behaviour)

Increasing the number of validators per se won’t increase throughput as block times are strictly based on time. It also increases ops burden ect. Overall I don’t have a strong opinion, but if decided on going with it. would do it in small increases. The biggest potential concern is the longer and longer finality that potentially increases chain volatility.


one more detail:
With the current set of pools, increasing the number of active validators would create an incentive for existing validators with unlocked stake to split up their validator into multiple instances. Those split-up validators would then occupy the newly created slots, leaving us with only the disadvantages (more communication overhead, thus lower max. protocol throughput).

This is because epoch rewards are evenly distributed over the active validator set, giving “lighter” validators a relative economic advantage.
If the number of active pools doesn’t exceed the number of active validators (which this proposal tries to avoid/delay), the mitigating effect of stake weighed validator selection can’t kick in, leading to this unproductive incentive for splitting validators.

1 Like