bLuna/stLuna validators are a core part of the Terra ecosystem and their behavior is of special attention to the community. To that end, strict performance and operational expectations will be put in place for bLuna/stLuna validators.
Underperforming validators will be deregistered from the whitelist, disallowing bLuna/stLuna minters from making new delegations to them, and removing bLuna/stLuna-related delegations.
What happens to deregistered validators’ delegations?
Following deregistration, the bLuna/stLuna contract automatically redelegates existing delegations equally among the set of remaining validators.
What about intentional misbehavior?
The Terra blockchain permanently disables validator addresses that have double signed a block (i.e. tombstoned). Tombstoned validators are also deregistered, with their remaining delegations redelegated.
What does “underperforming” mean?
Actions or performance that would cause being deregistered from the whitelist include:
- being slashed/jailed/tombstoned,
- signing less than 80% of the latest 100 000 blocks,
- 6-hours period without signed blocks,
- providing less than 80% of oracle votes for a month,
- 6-hours period with no oracle votes,
- missing a network update (being offline for 3 hours after network migration/security-related fork),
- setting the commission rate more than 10%,
- missing a vote on the Terra governance.
Why we don’t require near-100% uptime?
Unfortunately, it is really hard to keep uptime close to 100%. Redeployment operations, network-wide problems (such as possible bugs in terrad, for example), etc. could lead to uptime degradation.
Even in emergency conditions, uptime falling below 80% would almost certainly lead to a validator being considered underperforming and getting deregistered. While validator uptime slightly above 80% would be acceptable for small periods of time, consistent performance at this level or consistent uptime volatility would be considered strong signs of underperformance.
What happens with validators with lower (but still above the baseline) performance?
Lower performance leads to a lower reward amount for users. We are going to keep bLuna/stLuna APR high (because it’s critical for dependent protocols, such as Anchor) so that we are working on the penalties for the validators whose performance is lower than the threshold.
How will we monitor this?
In Lido we have a network monitoring system that can detect events described above. That system showed itself a good one and increased validators’ performance a lot. In a way to full transparency, we have a plan to publish a dashboard with validators’ performance so everyone could see evidence of validators’ misbehavior.
Who makes a decision of deregistering a validator?
For now, the decision of deregistering a validator is made by the Lido DAO. It means that removing a validator will be put on a DAO voting. Rules described in this post are going also be put on a DAO voting so that it would be possible to instantly deregister a validator breaking the rules.
All the reasons for deregistering should be proved by on-chain information.
Could a validator be deregistered in any other condition?
The short answer is yes. The rules described in this post cause immediate deregistering. But a validator could be removed from the set (permanently or temporary) in other conditions considered by the DAO as harmful.
What’s next?
We are highly responsive to keep the network healthy, so we are going to support diversification e.g. in the field of cloud providers and oracle feeder software. Such requirements are gonna be developed soon.