We Need To Talk About Governance

@Thylacine thanks for starting the thread! I’ve been meaning to put some thoughts down on this…

Proposals and Use of Funds

My first concern has been: there is a drip-drip of proposals, and how do I weigh one of these again the other? How much money is left? I want to be comparing a bunch of proposals against each other, and funding them according to their merits.

My second concern has been: many of the recent proposals have not been deeply rigorous, and have had gaps in terms of things like – asking for cUSD but the proposal being in CELO (approximately), asking for a buffer, asking for it all up-front without milestones, not making it clear who’s accountable to ensure the funds are well deployed, no means of recourse if the funds are not actually spent.

Luckily, I think we have a solution to this for the many small grants – I would say for all requests below a certain amount, let’s divert those requests to Prezenti. If Prezenti needs more funds to fulfill those grants, let’s have Prezenti request them. Or, if Prezenti stewards decide that this class of requests falls outside what they believe they should be funding, let’s set up another delegated Prezenti-like fund.

Most of these proposals are made by well-intentioned community members doing solid work and their projects and proposals would benefit from the guidance and mentoring of Prezenti and other community members.

I really think we need to get on top of this before (or at the same time as) the Mento reserve funds become available in the Community Fund.

I think we should also look at the quorum and participation parameters, and ensure that the right level of voter participation is required to ensure that only solid proposals get accepted.

Approvers

I’m writing this section in my capacity as one of the Governance Approvers, but I don’t speak on the behalf of the others…

It’s our miss that the Approver process hasn’t been better documented or more accountable, so let’s start improving it now.

Every Governance proposal has to be approved by a 3-of-N multisig established before mainnet launch and comprising a range of individuals from the community. (That approval used to have to happen before the voting started; now it happens in parallel, and just has to be done before a proposal is executed).

The Approver role is technical – more like an auditor – and is mainly about ensuring the safety of the network and preventing attacks on governance. We set out some of the details previously but to summarize:

On the non-technical side, the role of the “approver” on the running protocol is intended to be:

  • Make sure the proposal does what it says: Does the CGP match the code to be executed? Are there any unintended side-effects or ambiguities that are not covered in the CGP? Does the CGP and the code match the discussion on the forum? For proposals that refer to the M-of-N multisig, is it really a multisig, is M right, N right, are the members’ addresses stated publicly on the forum, and any reason to believe they may not be who they say they are?
  • Make sure the proposal does no harm: It is all too easy to do something that irreversibly and totally borks the network. Are we certain the proposal is not going to break any dapp or part of the core contracts, or cause funds to get stranded, or put the security of the network at risk?
  • Make sure voters can verify the proposal: does the released version of celocli allow a user to look at the proposal and CGP and come to their own conclusions about the above?

What the approvers’ believe their role is NOT:

  • Policy: e.g making a decision on whether X should receive funds from the community fund – that’s for voters.
  • Quantitative parameter settings: Whether a parameter should be X or Y, so long as either don’t violate the bullets above, should be for voters, not approvers.

So you’ll see by this definition, Approvers are almost never going to not approve a proposal asking for funds, provided the proposal is well-formed, and consistent. In the current framing, that’s up to the voters to decide.

Approver Multisig Membership

I would love to use this as an opportunity to get community buy-in (by replying to this post, DMing me, or other Approvers) for the membership of the multisig.

In particular, we have a few new community members who’ve agreed to be an Approver, but they haven’t yet been added. In order to do that, technically, we only require approval from other Approvers, but I know the sentiment is that the current Approvers would love to get broader community input and buy-in on this.

So current (and proposed) multisig members are:

  • Marek Olszewski – Celo Founder and CTO at cLabs
  • Tim Moreton – Celo protocol engineer 2018-2022 and now CEO at cLabs
  • Asa Oines – Celo protocol engineer 2018-2022 and Founder, Hyperlane
  • Zaki Manian – Cofounder of Sommelier Protocol and early contributor to the Cosmos ecosystem
  • Rob Witoff – former Chief Architect at Coinbase, former CTO at Polychain Labs, and CEO, Unit 410
  • Eran Tromer – Professor of Computer Science at Boston University, and Founder, Sealance
  • Kobi Gurkan – cryptographer at cLabs, and head of research at Geometry
  • Plus two others who for personal reasons wish to be rotated out.

Proposed:

  • Eela Nagaraj – senior protocol engineer, cLabs
  • Bogdan Dumitru – CTO, Mento Labs
  • Martin Chrzanowski – Celo protocol engineer 2018-2023 and Advisor, cLabs
  • Zviad Metreveli – founder of WOTrust validator group and maintainer for Celo Terminal
  • Mariano Cortesi – Head of Engineering, cLabs
  • Martín Volpe – Lead Protocol Engineer, cLabs

Also, please take this as an invite to participate – if you are interested in this role, please reach out. We are looking to broaden diversity of all kinds in the makeup of this community function. There is currently no compensation other than a warm glow (though Governance could always decide differently!).

An ideal approver might have:

  • A technical background and security mindset
  • Understanding of the Celo Governance process
  • Understanding of the Celo and similar protocols, and the core contracts
  • Solid Solidity experience
  • A history of participation in the Celo community
  • Willingness to confirm your identity to other approvers
  • Generally responsive on Telegram!

Again, I (and I’m sure the others) welcome feedback and input on this membership and the role itself.

Happy to answer questions + take suggestions, as always :slight_smile:

UPDATE 9/26: adding new volunteers, Mariano and Volpe!

13 Likes