Timeline for Upcoming Governance Proposal (cUSD Rewards and Parameter Changes)

Governance
1

cLabs and the community are planning to propose 5 governance proposals simultaneously this coming week. By maximizing the overlap of the voting period, we hope to reduce voter fatigue. The first proposal will reduce the quorum required for passing all subsequent proposals. Due to a dequeue limit of 3 proposal/day, the next 4 proposals are spread over the following two days.

The tentative proposal timeline is as follows:

Proposal Dates

Batch 1: Tuesday, Jan 5

  1. CGP [0016]: Update baselineQuorumFactor

Batch 2: Wednesday, Jan 6

  1. CGP [0014]: cUSD Rewards
  2. CGP [0015]: Extend Attestation Expiration Duration

Batch 3: Thursday, Jan 7

  1. CGP [0017]: Activation of Celo Community Fund
  2. CGP [0018]: Update referendumStageDuration

Timeline

Propose:

  • Batch 1: Tuesday, Jan 5
  • Batch 2: Wednesday, Jan 6
  • Batch 3: Thursday, Jan 7

Approval:

  • Batch 1: Wednesday, Jan 6
  • Batch 2: Thursday, Jan 7
  • Batch 3: Friday, Jan 8

Referendum (Voting):

  • Batch 1: Thursday - Tuesday (Jan 7-12)
  • Batch 2: Friday - Wednesday (Jan 8-13)
  • Batch 3: Saturday - Thursday (Jan 9-14)

Execution:

  • Batch 1: Tuesday, Jan 12
  • Batch 2: Wednesday, Jan 13
  • Batch 3: Thursday, Jan 14

Impact of Governance Voting Vulnerability

A recently discovered vulnerability in the governance voting process allows voters to vote twice on a proposal. The condition can occur only if there are simultaneous proposals in the referendum (voting) stage which have their referendum stages end at times differing greater than 3 days (the amount of time to unlock and lock gold in another account). In other words, proposals that are proposed between 3-5 days apart introduce this risk.

A fix has been made and will be deployed in the contracts release 2 updates (end of January). For these proposals, proposers will submit them less than 3 days apart so that this vulnerability can not be exploited. Approvers have been notified to be aware of proposals entering on this cadence.

CGP # + Onchain ID Alignment

It has continued to be difficult to maintain alignment of the CGP document number and the onchain ID which is based on the order of the proposal. While having them match leads to less confusion for proposal reviewers, changing the CGP to match the onchain ID breaks URL links that have been referenced in existing documents and posts. For the proposals here, the CGP number and onchain IDs will not all match.

2

I have a confusion that I felt important to raise, since I think it’s a tension that might seem subtle but has important, systemic implications. This mainly has to do with CGP [0014] and future similar CGPs, within the context of CGP [0017] as an ‘Activation of the Celo Community Fund’.

The concrete example at-hand for this right now is CGP [0014] for cUSD Rewards.

If CGP [0017] were comprehensively activating the Celo community fund, then logically speaking CGP [0014] for cUSD/CELO rewards would theoretically be passed as a Proposal to the stewarding group. These would be the stewards being proposed in CGP [0017].

Obviously this isn’t the case, and it’s also not quite clear in fact whether it should be at all or not.

Meanwhile, as process currently stands with regard to governance, the mechanism by which a Proposal for Community Fund spend would be approved is simply a CGP itself.

This is confusing from multiple standpoints, notably that of community participants whether by way of voting, proposing, building, advocating, etc.

What also seems to be important would be to correctly refer to CGP [0017] simply and solely as a complementary grants program, perhaps amongst various efforts, and these would be with specific elements and goals as elaborated by the steward team. Analogously I can think of Uniswap here as an example.

Right now, the feeling I get is that at least 2 main problems are:

  1. CGP [0017] can lead the community to believe that the mechanism for any of their Proposals to receive funding from the community fund is via this initiative (seemingly false, per current governance), and

  2. CGP [0014] can lead the community to believe that cLabs can utilize its own levers of power and influence – whether hard or soft, and despite all pure and rational intentions – to siphon community funds into company priorities (in this case namely Valora).

It is of course in the interest of the entire Celo community for cLabs to garner support, buy-in, participation, and approval; it’s less clear if on-chain public funds are the correct source pool for doing so. Regardless, per the mechanism of governance for funding already mentioned above, this is theoretically open to all community participants and/or entities to do the same and follow suit.

It would be great to get better clarity on how more folks feel about these points.

@aslawson @jbsibille @emily @Patrick @deepak @Dee @nambrot @asa @tim @Yaz

3

CGP [0017] indeed has a confusing title as “activating community fund”, since it is not activating the whole fund, but, allocating part of it to be deployed by a set of stewards for quicker distribution. Actual description and discussion in the forum post for CGP17 describes it to be very much like the “Uniswap Grants Proposal” that you linked.
Not only that, CGP17 explicitly doesn’t block others to apply as a separate team of stewards, if they have a different plan and an approach for Grant distribution.

Since CGP17 is just one use of the community fund, it still makes sense that really large projects would apply to the community fund directly. Hence CGP14 applying to the community fund directly for its funding, because if things go according to the plan, it will most likely request fairly significant amount of funds for its purposes down the line.

3 Likes
4

My perspective on this:

CGP17 is just one possible instantiation of a grant-giving committee funded by the Community Fund. I agree its name could be improved. I suggested in an earlier comment that we should separate the framework from funding a specific set of stewards, and while I feel it’s a shame we didn’t make that separation more cleanly from the get-go, I would prefer us as a community to get going on supporting more projects.

Certainly, nothing prevents others making a governance proposal for a similar (or different) way of disbursing Community Fund funds.

I see CGP14 as a different and very valid form of use of the Community Fund. It’s not intended to be Valora-specific, as far as I understand.

Personally, I think we need to work on better signposting on celo.org for folks interested in all of the different ways they can receive funds for projects or contributions in the Celo ecosystem. I even wondered about a single place where projects can identify themselves, and funders reach out.

2 Likes
5

Hi Gabrielle, thanks for the feedback! What part of CGP 14 you think can “lead the community to believe that cLabs can utilize its own levers of power and influence – whether hard or soft, and despite all pure and rational intentions – to siphon community funds into company priorities (in this case namely Valora).” ?

1 Like
6

@jbsibille I know you already mentioned in the gov call today that the eligibility criteria are subject to confirmation and iteration – so just depending on those explicit criteria, it can lead to such, but the current proposal is broad enough that it’s still ambiguous. There is also the stated possibility of using Valora metrics to inform iteration – and this would likewise hold influence and sway over inferences if this were to be the sole source of wallet metrics, for instance.

7

I would +1 to this as well, @tim

8

I agree that CGP17 would be more accurate if it was titled something like ‘Community Fund Spend Proposal 1’. The ‘Activation’ title is a result of the initial post from @pranay suggesting we submit such a proposal. V1 of our proposal was very much a set of guidelines for spending Community Funds and would have been appropriately titled ‘Activation of the Community Fund’ but we iterated based on community feedback to where we are now. I’m happy to update the title for clarity.

1 Like
9

In the current setup (as the proposal will be voted on), only 1 of the 3 key holders of the 2-of-3 multi-sig will be within cLabs. So cLabs cannot unilaterally decide to favor its own products with the community funds (the proposal is designed so that the signers represent and act on behalf of the entire Celo community).
Also to re-iterate what I mentioned this morning, the hope is that long term we can move towards a fully programmatic disbursement mechanism (if we decided that it was a good use of community funds for the long term health of the CELO ecosystem). This initial grant is here to help us learn and iterate on the best rewards mechanisms.
The sentence around using Valora-specific data in the proposal is here so that we have this option if it allows us to learn faster within the scope of this initial grant, in a way that would benefit the entire community (e.g. if we wanted to quickly try an invite-based rewards mechanism). If it turned out that using Valora-specific data is the only way we can have an effective rewards program in the long term, I think that would lead a broader conversation on funding mechanism.

Let me know if this context wasn’t clear with the current proposal or if there is specific language you’d like to propose to reflect this additional context, happy to make changes to the proposal :slightly_smiling_face:

10

@jbsibille Let me actually say explicitly that I personally really love this proposal. The idea, goals, and overall initial concept is something I fully support. My feedback mostly stems from the fact that the devil is of course in the details for how we’d hope to bring certain things like this to life (especially in our space). I believe that one detail is holding enough space for our assumptions - because they will matter to how things play out, independent of our best intentions. :slight_smile: I know we’ve been working on and discussing everything for a while, so I am ofc considering all of that too. I believe we could make certain ambiguities more concrete, and that would help with some of the language to better clarify all relevant details.

My recommendation would be to definitely include:

  • Names & affiliations of all key holders and anyone in back-up on the multi-sig committee

  • Commitments listed in terms of publishing the ongoing distribution strategy methods and results, as this will effectively be manual research until programmatic distribution might come into play

  • Purpose of including the Valora-specific data, which I think your wording here is perfect and super clarifying: Further iterations might leverage Valora-specific data. This is so that the multi-sig key holders have this as an option if it allows them to learn faster within the scope of this initial grant, in a way that would benefit the entire community (e.g. if they wanted to quickly try an invite-based rewards mechanism). Depending on uptake and community feedback, eligibility criteria may be reassessed.

  • Definitions (qualified/quantified) of uptake + success. The reason for this being that, hopefully, it could be considered a fair assumption that people like rewards, and they will want them, and they would like them. What more can we learn?

Happy to talk more as well to get the words otl together :smiley:

1 Like
11

Thanks for the support on this. Regarding your points:

  1. Working on getting this integrated within the final proposal.
  2. We will publish eligibility criteria and results via forum post or blog post. Feedback will be of course welcome!
  3. Thanks, I will change the wording in the governance proposal (Update 0014.md by jbsibille ¡ Pull Request #138 ¡ celo-org/celo-proposals ¡ GitHub)
  4. The initial metrics for success here are:
    • number of accounts with a balance > 20 cUSD (in our initial targeting, rewards start with average weekly balances > 20cUSD)
    • Avg & distribution of cUSD balances

We will look at these metrics before, during and after the rewards period ends. Given that we have no baseline comparison, it is hard to predict what success exactly will look like. Of course we won’t only look at these 2 metrics and we’ll conduct further analysis as needed to understand better certain behaviors that we may observe.

12

Thank you for bringing up this discussion @gabrielllemic and sharing the Uniswap example. It helps to have these multiples perspectives.

We’re in the first twelve months of the mainnet launch and Celo’s growth is on the critical path so, in this regard, CGP14 makes perfect sense and it’s a sound use of the Community Fund. Although this is a type of expense which can easily go out of control but @asa had already mention an upper limit of 700k Celo (~25% of the CCF at that time) in his initial forum post.

With CGP17, we hope it could become a template for other people to act as stewards but it is certainly not the only way to make use of the Community Fund. The Uniswap example is reassuring as we have many similarities with it in terms of timeframe, amount and course of action. We will definitely keep a close eye to it.

1 Like
13

To prevent the baseline from decreasing indefinitely in this way, we must be able to pass most proposals with participation levels that are well above the baseline. Because large Celo holders usually vote on proposals, this risk is small

To encourage governance voting from stakeholders, what if accounts were penalized for not participating? One idea is to exclude a non-voting account from future reward distribution for X number of blocks, where X is a constant number increased by the account’s token ownership % (holds those with more tokens/votes accountable, since their impact is greater).

14

You have been choose tl receive 1 free cela How can i send you 1 celo for my coinbase earn mission ?