Oversight Committee Spec for Optimistic Governance
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: • Performer , referring to the one…
Excerpt (1195 of 7104 characters). Read the whole post on the forum ↗
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…
Excerpt (1199 of 1762 characters). Read the whole post on the forum ↗
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.
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’?
Cautiously optimistic on this one. The addition of the customer role is interesting.
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.
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…
Excerpt (1198 of 2440 characters). Read the whole post on the forum ↗
effortcapital: I think we can create domain-specific oversight committees: 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…
Excerpt (1198 of 1390 characters). Read the whole post on the forum ↗
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.
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.
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
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…
Excerpt (1199 of 2314 characters). Read the whole post on the forum ↗
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?
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…
Excerpt (1190 of 1930 characters). Read the whole post on the forum ↗
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 !