Cosmos-sdk: Validator terms of service link

[mdyring]

Summary

Ability to provide a link to terms of service, alongside "website" for a validator.

Problem Definition

For validators operating with terms of service, they need to make a best effort to ensure the delegator are aware of them before delegation.

Therefore, it would be nice to be able to prominently display a "terms of service" link in user interfaces, in the instances that it is populated.

We could also choose to link directly to ToS on the website, but IMHO it would be nice to differenciate between general information and ToS.

Proposal

Add --terms-of-service "https://validator.network#tos" or similar to gaiacli stake create-validator, and pass the link around alongside the other validator information.

Services like explorecosmos.network and similar would then hopefully display the ToS link prominently.

---

For Admin Use

• [ ] Not duplicate issue
• [ ] Appropriate labels applied
• [ ] Appropriate contributors tagged
• [ ] Contributor assigned/self-assigned

[sunnya97]

What kind of stuff would be in a validator's terms of service?

[mdyring]

That would depend on the validator. For instance, it could state that the validator can't be held liable for any losses (slashing, etc.).

[cwgoes]

I think this is a good candidate for a JSON description standard.

[jackzampolin]

Oh I like this! We could do a docs fix here and maybe even validate that the --description is JSON. Would love to see a proposal for this.

[cwgoes]

This is a good idea but I don't think it actually requires code changes in the SDK - rather, we should encourage validators to put JSON as their description and maybe alter clients (e.g. Voyager) to parse it.

[cwgoes]

Closing this in favor of a JSON standard for validator descriptions.

cc @faboweb thoughts on this?

[faboweb]

We already have a standard validator description:

"description": {
      "moniker": "local_2",
      "identity": "",
      "website": "",
      "details": ""
    }

Until more users require this extra field I propose to add the ToS into the details field. But open to changes.

[mdyring]

To me, details != terms of service.

I'd like to think that a "well-behaved" UI would present the user with the terms of service before enabling them to delegate.

Of course this is just a "best effort" from validators to ensure delegators have seen/accepted them.

To be honest I can't come up with other fields that would make sense to add, so short of inventing a JSON standard it could make sense to just add a tos field.

[faboweb]

Ok, nice idea, I will bring this up with the UI team.
Some thoughts:
This would only be the case in "well-behaving" UIs, as you said. User that use the CLI are not affected by this. You also (currently) can't poof that users accepted your terms of service. And you can't unbond delegates that didn't accept your terms of service, am I correct?

[mdyring]

@faboweb agreed, there is no way to prove the user accepted the terms. It is best effort, but would be nice to see it in the official tools.

AFAICS, the CLI could display the link to the terms as well and ask for confirmation. Something like

<moniker> has published the following Terms of Service:
<tos-link>

Please review these carefully before proceeding with the delegation.

Do you accept the Terms of Service? [y/N]

This prompt could overridden by a --accept-tos flag for automation purposes.

I fully anticipate some validators will not develop or publish ToS, so in the cases where the field is not populated behavior should be as-is.

[jbibla]

nice ideas @mdyring

[sunnya97]

The issue I have here is that the Terms of Service seems like it can be used as a vector for validators to be able to refuse delegation, something we do not want, as it opens an opportunity for the validator set to refuse new stakers from joining.

Things like the "validator can't be held liable for any losses (slashing, etc.)." should already be part of the "collective understanding" of the blockchain staking system.

[mdyring]

@sunnya97 To quote Avatar: "I see you".

Trouble is that in contrast to "the network" as a whole, validators need to consider meatspace issues such as abiding by prevailing law in their local jurisdiction. This include their liabilities towards delegators, staying compliant with anti-money laundering regulation etc.

A counter-argument can be made that delegators are not dealing directly with validators, but are simply counterpart to "the network". I'm unsure that is the prevailing sentiment today, so I'd love to see a collective understanding of what BPoS really "is" formed, to the mutual benefit of validators and delegators alike.

AFAIK there is no written material to support this understanding yet, leaving validators fending for themselves. So it would be great to see this developed by Tendermint or ICF.

Just to be be clear, this is not intended to refuse delegators at the protocol level. It still leaves delegators free to ignore the published ToS', but at the same time offers some protection for validators.

This is related to https://github.com/cosmos/cosmos-sdk/issues/3290 which can be used to reject delegations and is more contentious.