Delegators need more information on validators

[nylira]

UI Version: 0.7.0

Delegating is the number one feature of Voyager. Delegators need more information be able to easily differentiate between validators.

Current Validators Info

On the staking page, each validator shows this information:

• Validator Moniker
• Validator's Voting Power (Percentage)
• Validator's Voting Power (Number)
• Your Votes (Number)

Proposed Validator Info Changes

Don't show validator's voting power in two different ways. Percentage of vote is what's important, let's only show that. Ditch the number of votes and the bar graph.

Show validator's commission rate. A validator's commission rate directly affects their number of delegators. A high commission rate means delegators may look to another validator for lower taxation. We need to clearly show this.

Show the number of times the validator has been slashed. An attractively low commission rate cannot be the only basis for validator selection. We also need to see how many times this validator has been slashed in the past x weeks / months. There should also be a details view where it tells the user why the validator was slashed, and what number or percentage of staking tokens the validator lost).

Show a portion of the validator's public key. It's easy for malicious validators to impersonate reputable validators by choosing a similar name, logo, or website url. Because public keys are random, displaying and letting delegators confirm public keys can remove this attack vector.

Show the validator's avatar. Monikers and public keys are not always easy to remember. But showing avatars (queried from the validator's keybase id) alongside those two text strings will make it easier for users to find their desired validator. Avatar example from Explorer: https://explorecosmos.network/validators

Hard Difficulty: Show validator uptime. With the Game of Steaks we're making to easy to find high uptime validators by locking their steak to 1000 each. However, on other testnets, and on mainnet, validators will have wildly different amounts of steak. However, uptime is one of the most important statistics for delegators because it directly affects their income and chance of being slashed. Tendermint needs to run a server that saves this historical uptime data for every single block from genesis onwards, and we can show this uptime data in Voyager.

Hard Difficulty: Show projected income. Calculated using the validator's commission rate, uptime for the last X months, number of times it was slashed, and a set amount of staking tokens from the delegator, let's show the delegator's projected income after one week and one month.

---

The staking feature is not done until we address all of these points. Delegators have the critical need to make informed decisions, and we need to provide that information.

Addendum 1: This sort of validator data should be shown in the Explorer as well as Voyager.

Addendum 2: I can see the benefit of even more data on Validator profile pages (like server hardware, server location, website, description, third party audits), but I will leave that for another issue.

[jbibla]

amazing proposal @nylira - i am strongly in favour of all the above points. thank you for articulating it so clearly.

💯 💯 💯

Show validator uptime

because this is difficult and because we will show how many times they have been slashed i don't know if we need to show validator uptime pre-launch. is a date available for when the validator declared candidacy or can we tell how many blocks in a row (ostensibly, for how long) a validator has been validating?

Show projected income

i would love to do this but we will have to check with legal.

---

i would add to the above list - that we need to determine the mechanism for encouraging a relatively even distribution. in the past we've talking about randomizing the list but perhaps we can consider other options. alternatively, an argument could be made that the market will decide and we should not try to intervene.

[faboweb]

i would add to the above list - that we need to determine the mechanism for encouraging a relatively even distribution. in the past we've talking about randomizing the list but perhaps we can consider other options. alternatively, an argument could be made that the market will decide and we should not try to intervene.

How about showing a warning if you try to delegate to the top 20%?

[faboweb]

or can we tell how many blocks in a row (ostensibly, for how long) a validator has been validating

I think this is uptime for us. There is no time in a decentralized world I guess. :)

@rigelrozanski are slashes stored (with block-height and reason)?

[rigelrozanski]

Slashes are stored in the block history and log but there is no explicit history stored in the validator object

[faboweb]

Are slashes indexed transactions? Or if not could they be?

[rigelrozanski]

@cwgoes

[cwgoes]

Are slashes indexed transactions? Or if not could they be?

They will be; blocked on tendermint/tendermint#1803.

[jbibla]

please see wireframes here https://sketch.cloud/s/xKnxA/p/page-1

[faboweb]

A bunch of very good ideas. I like the "my active stake" overview. I like the coupling of technical and political performance for decision making. I like the enforcement on informed decisions and therefor the limiting on one delegation at a time.

Comments:

• staking now has several nesting layers. can we do this with fewer? if not we may need breadcrumps + back button
• showing txs per denomination seems random. If I want to gather my tx history I would need to click through several views.

[nylira]

I made my comments on Sketch Cloud. Awesome work @jolesbi! Agreed with @faboweb on his comments, and I gave a solution to the tx history page -- allow users to switch between denominations through a denom list, instead of having to click back.

[jbibla]

thank you @faboweb and @nylira!

staking now has several nesting layers. can we do this with fewer? if not we may need breadcrumps + back button

it is one more level of nesting. i can't keep up with the state of the back button - but that should be fine. breadcrumbs would also be nice - but not sure if we need them.

showing txs per denomination seems random. If I want to gather my tx history I would need to click through several views.

this is a fairly common convention (see coinbase as a good example). we should still keep the full tx history page - but if we have individual wallet pages for each denom - we should filter those tx's for that history as well.

[NodeGuy]

I love all of your ideas presented here, @nylira.

[faboweb]

Wait for #1010 to be implemented and wait for Jordans designs

[faboweb]

Consider closing after #1100

[fedekunze]

Closing. Will open independent issues for slashing, uptime and projected income