ADR 037: Governance Split Votes

[sunnya97]

Description

This ADR introduces the concept of governance split votes. Please see the ADR for details.

Coauthored with @antstalepresh

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (see CONTRIBUTING.md)
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Code follows the module structure standards.
• Wrote unit and integration tests
• Updated relevant documentation (docs/) or specification (x/<module>/spec/)
• Added relevant godoc comments.
• Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
• Re-reviewed Files changed in the Github PR explorer
• Review Codecov Report in the comment section below once CI passes

[sunnya97]

Is there any preference to whether the vote struct is done as currently proposed in the ADR:

Vote {
    ProposalId  int64
    Voter           sdk.Address
    options       []Option
    rates           []sdk.Dec
}

vs creating a new SubVote struct that contains Option+Rate?

Vote {
    ProposalId  int64
    Voter           sdk.Address
    subvotes    []SubVotes
}

SubVote {
    Option  option
    Rate     sdk.Dec
}

[alexanderbez]

Concept ACK!

[alexanderbez]

I prefer the sub-vote option @sunnya97. I don't see any merit to splitting up the types, since they're logically so connected.

[zmanian]

This is a very important feature to me. I am trying to reach out to custodians to see if they would embrace it.

[aaronc]

This does break backwards compatibility and I see that as a negative but it is not listed.

Please try to find a way to do this that doesn't break existing APIs, esp MsgVote. Introduce a new msg instead. I see this a rather niche use case and shouldn't be exposed to users by default.

[alexanderbez]

I do agree that we should avoid breaking existing message types and APIs, but I don't see this as niche at all. I think this will be very useful, even for the average user. ACK

[sunnya97]

@aaronc If we want to keep the types the same for easier wallet compatibility, could we just create a new Msg type, but not a separate underlying struct?

If SimpleVote and WeightedVote were two different structs in state, we'd have to create a new vote interface that both of those satisfy, and this will likely be a larger change.

Instead, the on-chain Vote struct could include weighted votes, and a simple MsgVote (backwards compatible) received by the chain is just converted to a single Option WeightedVote that's stored in state.

So we'd have:

type MsgVote struct {
  ProposalID int64
  Voter      sdk.Address
  Option   Option
}

type MsgWeightedVote struct {
  ProposalID int64
  Voter      sdk.Address
  Options    []WeightedVoteOption
}

type Vote struct {
  ProposalID int64
  Voter      sdk.Address
  Options    []WeightedVoteOption
}

[aaronc]

@sunnya97 that could work 👍

We could also do this for Vote and it wouldn't even be breaking at all:

type Vote struct {
  ProposalID int64
  Voter      sdk.Address
  Option     VoteOption // if set to VOTE_OPTION_UNSPECIFIED, then Options is set instead
  Options    []WeightedVoteOption
}

Btw, I'm not completely opposed to breaking changes in .proto files we've marked as beta, but I would prefer to reserve those changes for cases where we find architectural problems as opposed to want to add new features. This seems more or less like a new, additive feature.

[zmanian]

We really want to encourage large custodians to build a proxy voting infrastructure to go with their staking operations.

This is a complement to efforts like staking derivatives to ensure the viability of proof of stake as large custodians become more and more important.

[amaury1093]

This looks sensible to me.

Completed

[robert-zaremba]

Very interesting add on for custodians.