Oversight Committee Spec for Optimistic Governance

Conversation Governance Meta
1

Context

Historically, community spend proposals on the Hub have assigned a multisig of well-known community members to safeguard the funds and ensure that the funded team is subject to oversight by a third party. Between analysis of past spend proposals and Elijah’s thoughts on the future of the Cosmos Hub, there has been much discussion of governance and oversight structures on the Hub, with lots of emphasis on accountability for community-funded work. This idea was developed through conversation with @uditvira, @jtremback, and @ala.tusz.am on the state of current Hub oversight measures.

There are many technical improvements that can be made to governance tooling on the Cosmos Hub, but new tooling takes time. In the absence of new technical developments, this spec puts forward an improvement to the current models (e.g multisig committees which must act to release funds) that can be made with no technical changes.

The critical aspect of this proposed method is not a technical change – it’s the acknowledgement that the community is the ultimate decision maker.

Premise

In this short spec that follows, you’ll see two terms often:

  1. Performer, referring to the one doing the work.
  2. Customer, referring to the one who holds the performer responsible for doing that work, because it solves a need held by the customer.

These terms make the assumption that the customer is able to act as a single, coherent body. But this is not the case, because the customer of a community spend proposal is the entire network – with its varied viewpoints and all.

We propose that an oversight committee’s role is to help this decentralized customer make sense of the performer’s work, and thus empower the customer to make good decisions about the continued funding of the performer, not to make decisions that overrule the customer.

The community spend proposal can be seen as two things simultaneously:

  1. An agreement by the customer to fund the performer, and
  2. An approval of the proposed committee that will act as a bridge and sense-maker.

Both the customer and performer must have a part in selecting the oversight committee: The performer nominates them, and the customer approves them via governance.

In this model, the community’s initial funding decision is made by approving the community spend proposal in its entirety, and that decision is upheld via a funding mechanism that continues unless action is taken to halt it. In the same way that an optimistic proposal passes unless vetoed, funds will be released to the performer unless the community dissolves the workstream.

A simple version of the specification can be found below:

Core principles:

The oversight committee is built around five principles from which the purpose and scope are derived. These principles apply only to the committee structure outlined in this specification.

  1. The funding release format is optimistic and assumes that the working group will continuously perform at an acceptable standard. Funding is released via vesting, and requires active intervention to suspend still-vesting tokens rather than approve their release
  2. It is not scalable for the entire community to make sense of available information to the extent necessary to make good decisions for all community-funded workstreams.
  3. The community’s powers should not be diminished just because it cannot make sense of everything; rather, sense-making should be prioritized as a way to help the community make decisions.
  4. The committee acts as a sensor that provides information for the community’s decision-making abilities and, as such, it is an extension of the community.
  5. At all times, both the community and committee have the capacity to dissolve the working group and return still-vesting funds to the community pool.

Purpose

The oversight committee exists to oversee, advise, and guide both performers and customers in regards to the specified work throughout the funding period.

The committee has the same powers as the community in that it can dissolve the workstream via an on-chain vote, however it has more credibility in its decision to raise such a proposal because of its proximity to the work that’s being done.

The committee represents various stakeholder groups in the community that are equipped to

  1. Understand the performer’s work and its impacts, and
  2. Act as a bridge between the customer and the performer.

Scope

With these things in mind, the oversight committee will:

  • provide oversight to the performer.
  • report to the community in order to provide insight and awareness about the impact and quality of work performed, and facilitate a feedback loop between the customers and the performers.

The oversight committee will not:

  • act as a body overseeing any other ratified workstreams. Other community pool funded efforts are out of scope, and may have their own committees or other accountability structures.
  • be ultimately responsible for the work completed by the performer. They are a check on the performer’s work – but they are not responsible (in the sense of a manager) for the work being done.
  • act as a lasting governing body. The committee’s membership, together with the performers’, is put in place by governance approving the proposal and will only act as such until the term of the proposal is completed.

Flow

  • Ratification: The proposal passes via on-chain governance, which both funds the performer and approves the committee named in the proposal.
  • Funding: The funds are released into a vesting wallet controlled by the performer. (Technical details for this step are included in the footnotes.)
  • Dissolution and return of funds: At any time, the committee or the community can raise a proposal to dissolve the workstream and return the vesting funds from the vesting wallet to the community pool.

Conclusion

The above is just a brief overview of the committee, and may seem obvious. Still, it’s worth stating again: the network has, and always should have, the ultimate veto power for anything happening in relation to the network. This is in alignment with the principles which govern the blockchain.

Any time the community grants authority and funding to a performer, the community must also have the capacity to dissolve that authority and funding if necessary. In this proposed model, the approval of the community spend proposal continues until the community acts to stop it.

In other oversight structures such as an unvested multisig, a small group’s continuous approval is needed to uphold the community’s original decision, and the multisig itself becomes unanswerable to the community as a whole.

Although the vesting and accountability tweaks to the current multisig model might seem trivial, they represent a dramatically different approach to accountability in funding by acknowledging this core truth:

The network should always have the ultimate authority and it is vital to help the network make sense of what is happening so that it can exercise that authority effectively.

6 Likes
2

Footnotes

The exact implementation involves several compromises because of the inflexibility of the currently available tools running on the Cosmos Hub. Improvements to the implementation could come with updated versions of the SDK or new features on the Cosmos Hub, but are not strictly required.

Currently available tools:

  • Cosmos Hub community pool
  • Classic Cosmos SDK 0.45 vesting multisig
  • Cosmos Hub software upgrade proposal

Implementation details

  • Community pool release: Community pool funds cannot be sent directly into a vesting wallet due to the governance tooling currently available on the Hub. Funds will need to be released into a simple multisig account controlled by members of the oversight committee (or another party) and immediately sent to a vesting multisig account.
  • Multisig control: The vesting multisig will be controlled by representatives of the performer, not the oversight committee. However, representatives will only be able to withdraw funds that have already vested.
  • Vesting schedule: The only type of vesting possible in a classic vesting account is continuous vesting. To approximate payments at the beginning of the month (or payroll period), vesting needs to start before the working period defined by the proposal.
  • Dissolution: To end funding, an upgrade proposal containing migration code moving the funds out of the vesting multisig and back to the community pool must be passed via governance on the Cosmos Hub. It is possible for anyone in the community to introduce this proposal, but doing so is an explicit part of the mandate of the oversight committee. This is not technical control, but due to the weight of the committee’s opinion, it is very likely that this proposal would pass.
2 Likes
3

Is the intention of this spec that one oversight committee would oversee all community spend props?

I have been thinking about oversight for a long time and I think the experience we have had with an internal oversight committee within Atom Accelerator DAO is worth looking into.

Depending on how intensive the oversight work is it can be very time consuming and requires a wide variety of skills etc.

Equally I think there is a trade offs between internal oversight and external in terms of independence, information flow, insight etc.

I am not sure that one universal structure will solve the range of oversight needs that arise but I think this spec is essentially fine for relatively simple funding requests.

2 Likes
4

No, the spec is for an oversight committee to oversee a single community spend prop’s workstream.

The oversight committee will not:

  • act as a body overseeing any other ratified workstreams. Other community pool funded efforts are out of scope, and may have their own committees or other accountability structures.

The type of expertise needed to understand different workstreams could be very different, so I wouldn’t want to nominate a small set of people to be responsible for making sense of all funded work. That would be condensing ‘the community’ into a small body of people expected to perform the same role.

BendyOne: I am not sure that one universal structure will solve the range of oversight needs that arise but I think this spec is essentially fine for relatively simple funding requests.

What kind of funding request would this work for / not work for? I don’t think it should be universal, but I’d love to hone in on how others see it applying. What does it mean for a request to be ‘simple’?

1 Like
5

Cautiously optimistic on this one. The addition of the customer role is interesting.

1 Like
6

Thanks for clarifying. I am not 100% on a different oversight committee every time because I think you don’t necessarily the sharing of best practice and experience. My experience over the last few months is that the fragmentation of development makes for less efficient systems than would be ideal.
I think also finding new people on a regular basis is an operational challenge and putting together spend props is already tricky.

Looking at recent approved spend proposals I would say 95 is complex (broad remit, large budget, and funding others), 104 is probably medium (broad remit with outputs that are hard to predict but only one team), 814 is probably simple (clear outputs that are either achieved or not, single team).

Not necessarily saying I have a definite answer and I am conscious that I probably have some COI as I am in receipt of community funding myself.

1 Like
7

Hey all!

I am in full support of the “Optimistic Governance” approach. As part of the AADAO grant, RMIT, Binary, and Blockworks Research are coming to similar conclusions around how governance should work. Ultimately, the community needs to feel empowered and have “power over the purse strings” if, at any point, they feel they are not being served appropriately via Veto Power and the ability to remove a service provider and/or Oversight committee members.

RMIT is currently drafting a forum post about their high-level findings for not only spend proposals, but the potential need to have oversight committee members for the relationships between the various consumer chains and the Hub (either 1 committee per Consumer - Hub relationship, or a wider “AEZ Affairs” oversight committee). As we start to think about the future of Hub governance as it relates to Protocol-Owned-Liquidity and overall closer alignment of the AEZ, we must ensure both the consumer chains and the Hub feel adequately served by each other and their service providers.

With that being said, Im not entirely sure how I feel about spend proposals including an already-chosen oversight committee. I see both sides of the original discussion between @Elijah and @jtremback. What if the Hub community elected oversight committees that had a mandate over specific types of spend proposals over the course of 6mo - 1yr period, with renewals being subject to an onchain vote?

Instead of each spend proposal having its own committee (which can fragment lessons learned/best practices, lead to a breakdown in overall communication, and may lead to unnecessary bureaucracy) and instead of having one “source of truth” that has a wide mandate over all spending, I think we can create domain-specific oversight committees:

  1. Security/Audit Community Spend Oversight Committee
  2. Grants/BD Oversight Committee
  3. AEZ Affairs Oversight Committee (either one for each consumer-Hub relationship or 1 comittee for the AEZ)

I think its also important for the Hub community to think critically about yearly budgets for specific categories of spend. We can take lessons learned from corporate governance structures…not everything should be ad-hoc spend proposals (some can be, but most shouldn’t be).

Overall my two cents. Thanks for posting @lexa! This is a critically important conversation as we all figure out what the future of onchain institutions look like :slight_smile:

3 Likes
8

I’m very hesitant to enshrine any group of people in a position of power on the Hub. The beauty ot the per-proposal committee we propose here is that if the spend isn’t working out, and the committee isn’t holding it accountable, the whole thing can be scrapped.

A broader global committee will amass power on its own and will build a little fiefdom, even if it is constrained to a certain subject matter area. A per proposal committee will live and die by the effectiveness of the underlying spend.

Your categorized committees will also have a lot of ambiguity and overlap. A lot of mental energy will be spent by teams deciding which committee to appeal to and whose jurisdiction they are under. A per-proposal committee has no such problem.

That being said, I am not opposed to having the committee chosen separately from the proposal approval, so that the proposal authors don’t choose it. We just don’t have a sophisticated enough governance system (and maybe culture) to run an election for a whole council at once in one proposal. In the absence of that, I think that proposing the committee with the proposal is a decent stand-in that doesn’t lose much. After all, if the community does not approve of the committee, they can turn down the proposal, or end the funding if it is already live.

2 Likes
9

This is an example of the high barrier to entry of governance. Asking a team to not only have a valuable piece of work but to also know (but not so well as to throw up conflicts of interest) respected individuals to provide an oversight function is a big ask for some less well connected teams. Equally the oversight team being ‘appointed’ by the team doing the work means the dynamics start off on a peculiar footing.

I also do think that oversight is a specific skill and as mentioned above oversight of more complex spend props really does require so coordination and sharing of learning etc.

Having said this I think you are right about the danger of one group of people becoming a fiefdom. Trying to find a balance here is very challenging because the both pre selecting and retro fitting an oversight team to a prop have trade offs.

2 Likes
10

IMO the concerns of a fiefdom can be easily fixed with 3-6mo terms and a max on how many terms a given individual can do over a specific period of time (maybe you can only be on any oversight committee for 12mo over a 24-36mo period).

OR

Every oversight committee is a team of X individuals (let’s say 4-5) and teams making a spend prop get to seat 2-3 positions and the Hub gets its own 2-3 seats that works specifically on behalf of the Hub (again, with term limits)

I’m not a fan of every spend prop having its own committee fully chosen by the team that makes the spend prop without other rules in place

2 Likes
11

spend proposals including an already-chosen oversight committee

Purely from utilitarian pov here, I just don’t feel confident about enacting an election process for a proposal with our current tooling. I like the idea, but I think it would be very hard to do without a tech change to enable on-chain elections or something like that.

I’m not a fan of every spend prop having its own committee fully chosen by the team that makes the spend prop without other rules in place

The additional rules are the ones already enshrined by governance: that the proposal doesn’t pass if the community doesn’t want it to, and the entire workstream is suspended if the community sees that the committee isn’t serving its purpose.

I feel the same concern about a committee being fully chosen by the community without other rules in place. The community has governance-enshrined power over the process no matter what, but the funding recipients have none. Part of my optimism perspective is that the funding recipients know their work best, and are most equipped to choose appropriate stakeholders to report on their progress. The community’s job is to approve of their choice or reject it.

And while this is my belief, I can see what @BendyOne is saying about a high bar to entry. I’m not at all opposed to a proposal maker showing up and saying “Hey I have this great piece of work and have no idea who is equipped to provide oversight — I need the community to help me”. In this case, the proposal maker is forfeiting their side of the “nominate/approve” structure and I think that’s fine.

The same election issue crops up for me with a domain-specific committee, but there’s a bigger concern imo, in addition to the fiefdom issue that Jehan points out.

Being on a committee providing oversight involves work. It means staying close enough to the work that you understand it and can communicate about it to the broader community. The bigger the workstream, the more work it is to provide effective oversight.

Who amongst us is both qualified to provide oversight for a broad domain and has the time to do it properly? Even for a short term (3-6 months), it’s a lot of work. And a short term creates more churn and reduces the longterm effectiveness of oversight work because people rotate and lose context.

12

Im sorry, i just don’t seem to be getting it. Could you please explain how " the community is the ultimate decision maker and at the same time we still need a multisig. I mean how do those 2 things turn out to be the same?

13

Depends which multisig…

The first multisig where the CP has to send money into a quick interim account kinda sucks. Like I said in the footnotes, the tooling isn’t set up for it but the transfer should be quick and highly visible. I think sdk 47 will fix that awkward interim transfer, and 47 is an existing, planned tooling update. It’s definitely a weakness, but I think it’s a very different situation to trust a third party for a single, immediate transfer vs continuing to release funds over like, 6-12 months of a funding period.

The vesting multisig being in the hands of the funding recipients vs a small group of other people is a huge change imo.

  • Third party multisig: Third part (not community, not funding recipients) decide whether funding recipients actually get the promised tokens once released from community pool. Third party (not community) has the direct, non-governance-approved ability to send money anywhere, including back to the community pool. This means that the community is trusting the third party to behave responsibly for the entire funding period, and to be the arbiters of whether the funding recipients continue to receive funding.

  • Vesting multisig: Community decides that funding recipients get the promised tokens according to vesting schedule and it happens automatically. Everyone in the community has equal power to create a governance proposal to send still-vesting tokens back to community pool. Community does not need to give their power to a third party to decide whether the funding recipients get paid (bc it vests automatically)

In both cases, I think it would be an extreme move to claw back tokens directly from the funding recipient’s personal wallets. So what’s interesting/relevant to me is the interim stage in long funding periods between the release from the community pool and the tokens reaching the recipient’s personal wallet.

Does that make sense?

1 Like
14

These terms could set a decent foundation for later use when we inevitably switch to use to the groups module capabilities to manage community funds. In the meantime the oversight committee is the best we can work with I guess ! But I can’t say how much I am enthusiast toward this future. Many Cosmonauts agree on the fact that the groups module is severely underrated !

1 Like