Why is my validator node jailed
Everything you need to know about jailing of the validator node, strike counts, and unjailing.
- When a validator node is down and not actively participating in the consensus process, it negatively affects the block processing timing and network throughput.
- At cycle's end, the consensus checks to see if a validator has validated at least 70% of their projected number of blocks; if they haven't, they're removed from the list of pending validators, moved to the list of jailed Validators, and given a strike.
- To calculate the total jail time, add
(endOfTheNewCycle + (numberOfBlocksPerCycle * strike count)).
- To prevent operators from failing to keep up with node operation, a strike system was implemented for those who repeatedly break the rule.
- 1st strike - 1 cycle min jail time
- 2nd strike - 2 cycle min jail time
- 3rd strike - 3 cycle min jail time
- 4th strike - 4 cycle min jail time
- 5th (max) strike - 5 cycle min jail time
- Strikes get reset after 50 cycles of not being jailed.
- During the time that you are in jail, your validator node will not be visible in the UI, but it will still be included in the list of old validators.
- The purpose of a node's jail time is primarily to maintain network stability than as a form of punishment. While in jail, a user's ability to run nodes will be taken away, they will still be able to receive rewards. Although restaking a large portion of one's fuse to another node after being jailed may result in the loss of delegators and voting rights, it will allow the node to continue to collect rewards (minus a 15% fee).
- As part of FIP11, a new function named
maintenance()was introduced; it temporarily jails a validator without increasing the strike count while moving it from the pending list to the jailed list for one cycle. That way, Validators can do maintenance without fear of sanctions or negative effects on the network.