Governance Planning Epic

[Chris-Hibbert]

Governance

We'd like to build a governance system that supports voting on the Agoric chain. We may need several different combinations of voting features, so the pieces should be pluggable and reusable.

Scenarios

committee binary vote (binary choice, single winner, by vote count)
staked Majority Vote (binary choice, single winner, by weight)
stakeholder slate vote (multiple choice, single winner)
stakeholder elect a board (multiple choice, multiple winner)

Issues

• Who can vote? How do they get a ballot?
• who can nominate? is there a limit to the number of positions/candidates/outcomes?
• What format to support when there's more than one candidate or position? (e.g. STV)
• Is there a quorum? can a super-majority be required on some questions?
• How is the deadline determined?
• L Presuming a deadline, can the vote close early for urgent questions if the quorum is met?
• How do elections get opened and announced?
• Are the results automatically carried out? Are there "advisory" questions?
• for non-advisory votes, how do we make the results legible (in the sense of ERTP and "the Fred problem").
• can voters change their vote after casting?
• L If we elect members of a committee who have the ability to vote, more questions arise
  • scheduling elections
    • bring questions to a vote
  • replacing members who resign or aren't participating constructively
• L We've talked about some votes being subject to a veto. This raises more issues

Let's put off issues marked L for Later.

For the rest, we'll drive the answers by working on the scenarios in the order listed above.

Provisional Answers

We can have a library of routines that know how to execute some updates. An individual vote can take some terms that determine what it will automatically do when the vote closes (or when the vote concludes with a Yes outcome.) We can make this more sophisticated over time, and make it pluggable/upgradable in some future revision.

We want to connect some voting to ownership of staked tokens, but without requiring that the stake be dedicated to a single vote. We don't currently have a representation in Javascript of the amount staked. That data is accessible in the cosmos code we use to drive home.bank, so we could use that info to issue voteable certificates. The certificates would identify the associated delegationAddress, the amount of stake, and how long the stake is tied up. The lock-up period could be set to the unbonding period for now, and support more sophisticated lock-ups later.

The vote contract would track the vote by the voter's address in the certificate. Voters could vote again to change position or if they had added to their stake. The contract would refuse the ballot if the staking period wasn't as far out as the closing time. (Unless we have some ("urgent") votes that can end as soon as sufficient positive votes are received.)

For multiple choice, with a single outcome, Instant-Runoff (IRV) will be implemented first, and for multiple winners (like voting for members of a committee) Single Transferable Vote (STV). Other methods of counting have their proponents, sometimes very vocally.

Sometimes it makes sense to have a quorum. For electing rep's you usually don't, since you want to seat someone. For other questions, you might decide that if not enough people can be bothered to vote, then it wasn't important to make the change. The quorum needs to be pluggable in case we discover over time that it's hard to get people to vote. Many organizations ignore the quorum prescribed by their by-laws in order to be able to make progress, in the face of low participation.

Tasks (Updated 2021-12-15)

• contract-embeddable library for managed parameters (data driven as much as possible) Contract-embeddable library for managed parameters (Governance) #3186
• 1st draft declarations for vote manager, ballot, creating vote with multiple positions Declarations for vote manager, ballot, vote creation (Governance) #3187
• committee binary vote, invitation facet provided directly to voters, advisory vote Committee Binary Vote (Governance) #3188
  • no quorum, no super-majority, no early close
  • at least an interim solution for creating questions, deadline, re-voting,
• Contract Governance Update a contract to rely on managed parameters (Governance) #3189
• update Treasury to use contract Governance Update Treasury to use Contract Governance to manage parameters #3473
• Attestation Contract Attestation Contract Regarding Lien #3282
• OwnerRegistrar to rely on Attestation OwnerRegistrar - a Registrar using Attestations #3474
• staked binary outcome majority vote Staked binary outcome majority vote (Governance) #3191
• stakeholder slate vote Stakeholder Slate vote (Governance) #3192
• Internal Governance demo (Internal Governance Demo #3869)
• (After approval of claimRegistrar feat!: add a claimsRegistrar based on attestations #3622)
  • replace committeeRegistrar in install-on-chain.js with ClaimRegistrar
• A Contract for posing Governance Questions (A Contract for posing Governance Questions #4142)
• Stake-weighted voting depends on:
  • Voting power and delegation state query (Voting power and delegation state query #3971)
  • Counting Votes with Dynamic Token Shares (Counting Votes with Dynamic Token Shares #3969)
  • Cosmos report number of outstanding shares to enable quorum enforcement (Cosmos staking layer report number of outstanding shares to enable quorum enforcement #3627)
• govern passable data as contract parameter (govern passable data as contract parameter #5533)

Misc

Design sketch for ParameterController

• has named slots with values
• contract and others can ask for current value
• separate facets for setting & looking up values
• Contract knows its governing facet for legibility

How much legibility initially?

Legibility will be important for public votes that will directly cause changes, but aren't necessary in some of the early scenarios. We don't want to preclude legibility. Committee members don't need the same level of legibility support as public votes. Advisory votes don't require it either.

• For executive votes by the public, we will want to display
  • the subject contract,
  • the parameter value and name,
• and have a story about how the contract indicates it's controlling facet.
• first cut can just show that it uses a voting contract without replacement

[Chris-Hibbert]

Here is my expectation about how ballots would come to exist and what things voters or other observers would be able to verify. I'm going to give a specific example in terms of managing parameters for a contract. Other elections will also be supported, but this seems to be the case where we need to understand how to verify connections between the parts.

• The world starts with the creation of a Registrar. Two of the kinds that we understand now represent committees and stakeholders. The electorate may deal with many questions governing many things, so the electorate has to exist first.
• The next piece to be created is an ElectionManager. (a Contract Governor, for this example). It will be tied to a particular Registrar. It has rules for who can creates questions, what happens with the results, possibly limitations on which kinds of ballots it knows how to handle.
• Next we create a contract that uses the paramManager, and knows its ContractGovernor. This governor knows about a specific Contract and can see what params are subject to governance. It provides a private facet that carries the ability to request votes on changing particular parameters. Some day we may figure out how to make the selection of parameters to change also subject to governance, but that's too many meta-levels for this story.
• The party that has the question-creating facet of the ContractGovernor can now create a question that asks about changing a particular parameter on a particular contract instance. The registrar creates new questions, and makes a new instance of a BallotCounter so everyone can see how ballots will be counted.

ContractGovernor will have a public method to get from the question name (unique within the ContractGovernor) to a ballotKit.

a ballotKit for a question created by a ContractGovernor has { ballotTemplate, BallotCounterInstance, Registrar, ContractGovernor, contractInstance }.
This is sufficient for voters and others to verify that the contract is managed by the governor, the registrar is the one the governor uses, and a particular ballotCounter is in use.

Voters got their voting facet via an invitation, so they're sure they're connected to the Registrar that's responsible for this vote. They get a notifier from the registrar to find out about new questions. They can use the question name from the notifier to get a ballotKit. After they fill out a ballot, they submit it by sending it to their registrar, whcih they know and trust.