How to check the technical competence of a validator

There are many ways to choose a few validators to delegate to in your chosen Cosmos Ecosystem project. These include:

• Commission (current and max)
• Uptime
• Community involvement (providing assistance in Telegram, writing instructions/guides, etc.)
• Development of supporting infrastructure (block explorers, etc.)

Nevertheless, there is arguably no more important feature of a validator than technical competence. This is because one wrong move by the team could render that validator tombstoned (permanently jailed) and your funds instantly slashed by 5% (network dependent). It’s rare, but it does happen.

A little less dramatic would be validator downtime which also results in slashing (although at a much smaller rate) as well as a loss of staking rewards for the duration of the downtime.

Yet analysing a validator for technical competence remains one of the hardest things for most delegators to do. Where would one start?

It can be difficult to make sense of all of the data.

To help, Bliss Dynamics have created the following guide:

Check the website

The best way for a validator to describe the topology of their setup is through a website. At the time of publishing for example, a staggering 17 out of 64 validators on the Akash Network (over 26%!!) did not have any website linked to their validator.

Now while this isn’t the only way for them to prove their worth to you, if they haven’t had time to give you meaningful access to learn about them and their operations/setup then what else haven’t they had time to do?

On Big Dipper, the link to the website can be found here.

On Mintscan, the link to the website can be found here.

On Aneka, the link to the website can be found here.

Please remember that you’re not delegating to a validator because they are good at marketing or branding, so feel free to excuse a simple looking website. But once you’re there, there are some key points to check:

• Are there contact details in case you need to get in touch with them?
• Is there a description about their infrastructure topology?
• Do they describe their security considerations or have any certifications?
• Do they have industry experience or might they be new to validating?

Check for slashing

While past performance may not be a reliable indicator of future performance (said quickly in a “disclaimer” voice), a validator who has a history of downtime or even worse, double signing might be best avoided.

For downtime, one of the easiest ways to check is to compare “Delegator Shares” with “Tokens” and make sure that they are the same. When a validator is slashed for downtime, their delegated “Tokens” are reduced, while their “Delegator Shares” are not (don’t ask, it’s a Cosmos SDK thing).

An example on Big Dipper of a validator who has been slashed for downtime.

Once you have determined that a validator has experienced downtime, you can click on the “More…” button in the Uptime window on Big Dipper to see when and for how long they experienced this outage or outages.

Click “More…” to find out more about when a validator has experienced downtime.

The next window may take a minute or two to load fully as the network is being queried.

Missed blocks by time of day, shown on Big Dipper.

In the above example, you can see that the validator was down from 4pm Monday until 9am Tuesday. Scrolling down to the table will also give you a list of blocks missed and any long outages should clearly stand out from the rest of the list.

Now a single downtime event might not be enough to redelegate your tokens to another validator (especially if they have soft slash protection), but you might want to get in contact with them, find out what happened and see if they have put any measures in place to avoid it happening again. If you aren’t happy with their response then maybe a new validator would be in order.

At the time of publishing, 9 out of the 64 validators in the Akash Network (14%) have experienced at least one downtime event during the course of akashnet-2 (which has not even been going for 3 months yet).

As for double signing, this is the unforgiveable sin of validating and will not only render the validator node permanently jailed (tombstoned), but also the reputation of the team in tatters. While you won’t be able to delegate to a jailed validator, it might be worth checking the “inactive” validators list for any jailed validators run by the same team as a validator you’re looking at delegating to, as well as performing a google search to see if your chosen team have any hidden history (on any network they validate on).

An example of how a validator might look after double signing and being permanently jailed.

Ecosystem Participation

Like the humans of this planet, validators also come in all shapes and sizes. Some commons ones include:

• Blockchain software developers who validate because it’s easy to them
• Infrastructure builders who develop supporting software such as explorers, wallets, etc.
• Professional validators whose existence relies solely on validating income
• Exchanges who benefit from not having to pay anyone commission
• Hobbyists having a go

While almost any of these categories may have competent validators who you might like to support, keep in mind that if you are delegating to someone who you’ve never seen participating in that project’s chat, forum, twitter, github or (especially) governance, they are less likely to be keeping up to date on the latest project status including any necessary software patches or common issues and may be more likely to experience downtime.

At the end of the day, choose whichever validators you feel like supporting most and don’t worry, it’s still so early for the Cosmos Ecosystem, you’re in the right place.

Feel free to get in touch with any questions or comments at our Telegram Channel or via the contact details on our website.