How do Guardians monitor Validators?


Guardians are expected to monitor the Orbs network and also the operation of the validators.

How actually do they go about doing this? How can a guardian sense foul play when it comes to Validators?


Guardians should develop their own criteria, which should probably focus on technical aspects (such as Validator’s node uptime). For that, we expect Guardians to create monitoring and other tools.
For example, Guardians may decided to operate audit nodes, that will see the transactions on the various virtual chains and whether they were properly included in the blockchain to ensure that transactions weren’t censored.
Going forward, we plan to provide further suggestions to the Guardians


Validators have a public api that enables guardians to gather information from the validators on how the blockchain advances. Guardians can analyze information retrieved from the validators, run statistics on it, and present it in an accessible form to the public.

Using the public apis, guardians can easily detect the following behaviours, which are great causes to kick out validators:

  • A validator that fails (or is slow) to propose a block when his turn comes (thus slowing down the network).
  • A validator that runs an old version of the protocol.
  • A validator that proposes an empty block while many transactions are pending.
  • In case of a fork, it is easy to see which validators double signed.

Monitoring tools could become more and more sophisticated, driving validators to behave as best as possible for the platform. Validators should feel under constant scrutiny by the guardians so that they keep maintaining their nodes adequately.


Thanks David, thats an excellent answer. It makes a whole lot of sense now.

Does Orbs have any monitoring tools to start off with or is it expected from the the Delegators that they do it themselves

1 Like

We expect the Guardians to develop their own tools

1 Like

The true power of a community shines when the community members start contributing these types of tools, especially auditing tools

If we see that the process is slow to happen due to tech complexity, we can use this topic for an Orbs hackathon and show some examples of audit tools written during the hackathon to inspire Guardians to continue these projects and take them to the next level


is it possible to become Guardian at the same time being a Validator?
From the or validator few overlaps.

1 Like

Sure, the 3 roles (Delegator, Validator, Guardian) can be held by the same entity, as each role has distinct responsibilities in the ecosystem, so:

  • A Validator may delegate their stake to a Guardian
  • A Validator may also function as a Guardian
  • A Guardian is also a Delegator (implicitly delegating her voting power to herself)

Thanks Andrey.
If the Guardian, delegator and validator all held up in one role how can you sort out issues of probable cause of one behave with the intend not to follow the protocol?
Will this cause the conflict of interest which could harm the network?

From the article:
Validators play an essential role in the Orbs network. They operate the Orbs nodes, run the consensus algorithm, sign blocks and approve transactions for the decentralized apps. Validators should also provide assurances that they’re good actors and indeed follow the protocol.
If we want to increase the quality of votes, let’s try to characterize the ideal voter. We’ll call this voter a guardian because effort on their behalf — finding the best validators or rooting out problematic ones — is what’s essentially guarding the network and keeping it safe and secure.


Great questions, and definitely subtle issues you raise.

Separation between Guardians and Validators is indeed desired. However, since Guardians and Validators are identified only through their Ethereum addresses, it’s not straightforward to achieve in practice. As of now, since the validator list is still under the monitoring of Orbs Ltd., the concern is not super urgent. The question will re-arise in its full importance as the validator nomination process becomes permissionless.

One thing we can do is to restrict a single Ethereum address to a single role. This would definitely make it harder for entities to serve as Validators and Guardians simultaneously. But this restriction is not bulletproof as rich entities could always split their ORBS tokens into two different addresses, setting one as a Validator and the other as a Guardian.

To avoid this from happening, Guardians and Validators should be identified. This would happen if delegators choose to support only Guardians that supply sufficient identification information and that vouch to disapprove Validators that refuse to supply sufficient identification information.

Another thing to note is that when the validator nomination process becomes permissionless, becoming a validator should require (at least in my opinion) locking ORBS tokens in an Ethereum contract. Since locking is expensive and risky, I shall assume only 15-20% of the tokens in circulation will back Validators. On the contrary, I believe that even 70-75% can be delegated to guardians (where delegation entitles the Delegator to a reward, and does not require locking, being completely risk free). This means that a Validator that is also a Guardian will need to get the support of many Delegators in order to be influential. And so, if Delegators know who they are supporting they would be aware of the fact that they are supporting a Guardian that is also a Validator.

1 Like

Thanks David!
Some clarification regarding the current PoS model:
Validators - identified, go through technical due-dilligence and are approved by Orbs. No stake or lockup is yet required
Guardians - permissionless, anyone can register and participate as a Guardian. No stake or lockup is yet required.
The above is an initial configuration to kickstart the network and learn what works, and is subject to future changes, as will be agreed upon by the stakeholders.
Thus, at the current model, it is very easy for a Validator to create a Guardian entity with a different address, making a requirement to separate roles impractical.