TL;DR
Clear, accurate information generates trust in the consensus, facilitates onboarding, better informs funding allocation and votes.
Less barriers to entry and inclusive design induce greater community participation and minimizes error.
Without a proper assessment of the dependence on whales, technical adjustments and better docs will probably fall short.
Adjusting the quorum, increasing voting power distribution, as well as a transparent, accountable delegated system mandated by the community with clear guidelines could be convincing solutions.
Thank you @Thylacine for creating this thread and taking the responsibility to ask the right questions and come up with a first set of suggestions.
I am a complete newcomer to the Celo ecosystem and my input is mostly based on my participation as a team member in CGP 122 and 128, as well as my previous experiences with other blockchain networks implementations of decentralized governance (I have been working in the blockchain ecosystem since 2017 and as a decentralized governance researcher since 2020).
It was important for me to let the dust settle after the rejection of the proposals, while I could also lurk more on the forum and explore the technical documentation to get a better sense of the current state of Celo’s governance.
My opinion is necessarily less informed than the ones of all the previous contributors to this conversation. I am very inspired by the posts of @tim, @LuukDAO, @Xochitl, @0xGoldo, and @0xZakk.
Please forgive me if I am being inaccurate and do correct me if any of the points I try to make here does not make sense.
Regarding @Thylacine suggestions :
-
I agree with this, but I would add the technical complexity of the process and the lack of clear, unambiguous, qualitative and authoritative documentation as one of the root causes of the faulty submissions. I come back to this in the last section of this post.
-
Increasing the bond for an application could be a good idea, with the possibility for established Celo stakeholders such as the Foundation or validators to sponsor a proposal by lending the necessary amount if small project leaders with insufficient funds come up with qualitative proposals on the forum. Gathering 1000 Celo (roughly 400 USD at this time) can prove very difficult for teams with little resources (e.g. Global South) whose ideas might completely align with Celo’s values and missions. It would be unfortunate to make it even harder for them to participate
Using a small fraction of the bond to compensate the governance support team is reasonable. But making the bond fully non-refundable poses a clear risk to limit proposals to only very consensual suggestions or submissions by wealthy stakeholders. In general, a governance system that can punish active, well-intentioned community members for not winning their vote does not sound fair, equitable nor particularly efficient if your goal is to build a functional decentralized decision-making mechanism.
-
Yes. An alternative would be to extend the voting or validation periods, to add a signaling check as suggested by @Thylacine himself and many others since. Another upside would be that proposers who failed to win their vote would be more likely to accept the referendum outcome and would not instantly try to resubmit.
I agree with 4 and 5.
A brief feedback on CGP122 & 128 successive votes
For context:
- CGP 122 did not reach the quorum, in part because “an issue with the dates” might have prevented some key voters to submit their votes and help reach the quorum.
- CGP 128, an updated version of CGP 122 reached the quorum but was rejected, in spite of having more “yes” votes than “no”, because it failed to reach its “constitution threshold” aka the minimal proportion of supporting votes over the total number of votes.
Once again, I am very new to the Celo ecosystem, but I think this highlights several issues that can be generalized beyond our rocky adventure (I leave the clock issue out of this since it is just a bug, although a concerning one).
- The first one is that there is a clear problem of transparency and access to qualitative, governance-related documentation and information.
- While the quorum is an essential metric to the vote, it is very difficult to find and can only be queried through celo CLI. In my opinion, it should be integrated in the explorer and/or celo.stake and clearly visible for every vote and to everyone, at all times.
- The hidden threshold -in constitutional law a “qualified majority”- that led to the failure of the second vote is hardly mentioned in official Celo documentation: it is absent of the Github doc, Celo Academy and Celo Doc are unclear, only this page in the Celo Docs refers to the “constitutionThreshold” which, once again, can only be queried through celo CLI. Apart this last source, this threshold is never eexplicitely defined as being different from a relative majority.
- As previously mentioned by many others here, simple tools to efficiently explore data on allocation and performance of past grants would greatly enhance trust in the community governance while giving examples of best practices to proposers and giving voters useful information to help pilot the Fund.
- The second one is that the current system presents considerable technical barriers to entry.
Those barriers do not deter the submission of bad proposals but can certainly scare insufficiently tech-savvy members to even think of applying. This might be very detrimental to the inclusiveness and accessibility of the governance system, especially when it comes to promoting participation of underrepresented groups.
The main thing these technical barriers actually achieve is to repeatedly cause the submission of faulty proposals, wasting everybody’s time, both proposers, approvers, voters and governance volunteers. Creating a user-friendly streamlined process with clear guidelines at every step is the best way to ensure community growth and the submission of qualitative proposals that are relevant to Celo Community Fund.
Not having such an inclusive and accessible submission process for everyone would make any adjustments of others conditions to participation, arguably, even more unfair (e.g. increasing the bond or making it non-refundable).
- In my opinion, they seem to be linked to a third, much greater underlying issue: how decentralized is Celo’s decentralized governance system?
Quick note I want to add here: the difficulty of building a functional decentralized governance system is extremely underestimated. This post is by no mean a way to diminish the merit of what has been achieved so far by the community, cLabs, the Celo Foundation or anyone who dedicated time and effort to get this ecosystem where it is today. I find this community admirable, welcoming and very much aligned with my personal values. I want it to succeed and I deeply believe that this conversation is a healthy one to have.
Overall, it seems like the votes, at least the non-technical, very consensual ones, are always struggling to meet the quorum until whales come in, as @0xGoldo pointed out. A small subset of address seems to systematically be:
- Necessary for most votes to reach the quorum
- In a position in which they can easily sway the majority (although they seem to adopt a willingly conservative approach of voting with the majority or abstaining, which is commendable but fragile).
At some point, we need to question the level of effective decentralization achieved by this governance model. This is the key to make the right decisions about the vote parameters (quorum and constitution threshold) and the right amount of delegation.
Some metrics exist to help us measure this. You can check out, for a simple yet already efficient methodology, this comparative analysis by Feichtinger, Fritsch, Vonlanthen & Wattenhofer.
-
What is Celo’s governance Nakamoto coefficient?
What is the minimum number of whales that need to collude before they achieved a guaranteed control over the decentralized governance mechanism?
And in Celo’s specific case, what is the distribution of locked Celo? What is the impact of the possibility to vote with stCelo on this coefficient? Do validators actually use that feature?
-
On the flipside, what does the quorum generally translates to?
Can the community realistically pass a vote without the direct intervention of one of the whales? How many of the top voters can refrain from voting before it becomes strictly impossible to reach the quorum?
E.g. if none of the 50 top holders of locked Celo participate in the vote, is it still mathematically possible to reach the quorum, even if all the smaller holders commit a vote? What about 100? 1000?..
This second metric has, to my knowledge, no defined name. It is indirectly correlated to the Gini coefficient but it is derived from the quorum ratio. Since it works as a reverse Nakamato coefficient (i.e. what is the nth holder, in descending order, after which the sum of all the locked Celo is inferior to the quorum) let’s call it the Nakamoto threshold -if someone knows it under another name, please let me know.
There are obviously no predefined levels that could be agreed as universally acceptable.
And of course, those metrics would not be perfect. It is virtually free to create addresses and split the locked Celo between them, or at the contrary combine the holdings of many addresses into one (only the voting fees would change). This is also the reason why any implementation of Quadratic Funding without any form of identity or reputation verification could lead to fraud.
Nonetheless, finding out through actionable metrics how “whales-dependent” the decentralized governance of the Community Fund is might be extremely useful to the current conversation.
If there is a way to explore the distribution of the locked Celo and if you find this to be pertinent, I would gladly help doing that work.
It might just be the case that, considering Celo’s history, its initial token distribution, tokenomics and various market dynamics, the quorum would need to be amended or the voting power would need to be redistributed-which is, to my understanding, part of the objective of the Delegated Voting Program- to ensure effective decentralization, but perhaps at the cost of stability and foreseeability.
Another option would be a truly transparent, auditable, and accountable delegated system mandated by the community, with clear goals, guidelines and a decentralized control/remediation mechanisms in case of conflict. This would be more effective and acceptable, although more explicitly centralized. It is in line with the suggestion of having Prezenti managing the allocation of small grants. It could as a trusted-third party complying with objectives discussed -and if possible set- by the community.
These measures are non-exclusive and complementary.
Ideally, they should be discussed and ultimately taken by the community as part of long-term progressive decentralization roadmap with clear actions and milestones that will ensure that Celo keeps steadily progressing towards more decentralization and better governance.
A brief feedback on CFP122 & 128 successive votes ← Sorry I lied. This is definitely not brief.
), I’m just thinking about what are some very small and concrete changes we can make asap. Curious what people think.
