Baseline for Lido validators on Terra

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.


Agreed with the deregistration criteria in general. I like the focus on governance participation, it will certainly improve overall participation rates in Terra governance. I do think keeping the participation rate at 80% or high (e.g. 8 votes out of last 10 governance proposals) might be a more reasonable target.


The criteria seem to be pretty well balanced

I find all the rules from the underperforming more than reasonable except the last one: missing a vote on the Terra governance.
This may happen due to various reasons and the impact is not that high, compared with the missing oracles votes for example
Beside that on the first look everything else looks quite reasonable and OK from my perspective

agree with the above, 80% on governance seems resonable.

1 Like

Thank you for your feedback @clawmvp @syncnode @SmartStake!
Since these rules are going to define the “red lines” for validators I agree that it is reasonable to make the 80% threshold for votes — the same as for performance requirements. To give some more flexibility here my proposal is to replace
“missing a vote on the Terra governance”
“missing more than 4 out of 20 latest votes on the Terra governance”.
Still, I want to reemphasize that from the perspective of ecosystem health, it’s pretty critical for validators to participate in network governance. Validators have a lot of voting power and of great responsibility to support the network governance process.


Any update on these considerations?

1 Like

The baseline (with the amendment for 80% threshold for votes) was passed by the DAO in a snapshot vote: Snapshot

@kai can you add this to the main post please?

1 Like