Proposal for Extension of Score Management Committee and Additional Funding

Governance Governance Proposals
1
  • Receiver Entity: The Score Management Committee Multisig
  • Status: DRAFT
  • Title: Extend the Score Management Committee and Request Additional Funding
  • Author(s): @swiftstaking
  • Type of Request: The Score Management Committee Improvements
  • Funding Request: 24,000 cUSD

This proposal seeks to formalize the expansion of the Score Management Committee by adding two new members (@swiftstaking, @kamikazechaser) and securing additional funding for their compensation. The committee began operating in its extended form following the hard fork, and this proposal is designed to retroactively align governance and funding with the committee’s current structure and operations.

Overview

The Score Management Committee was established as part of the original Great Celo Halvening Parameters proposal to manage score tracing of validators community RPCs. The initial formation and funding details were completed prior to the hard fork. The work has already commenced with the extended committee, and this proposal aims to formalize these changes and ensure adequate funding for all members.

Proposal Description

The Score Management Committee has been operating in an expanded capacity since the hard fork, with two additional members contributing to its responsibilities. This proposal seeks to:

  • Retroactively formalize the inclusion of these two new members in the committee
  • Update records to reflect the current composition
  • Allocate additional funding to compensate the new members fairly for their contributions

This proposal will allocate additional funds to the existing multisig wallet to retroactively compensate the new committee members, maintaining parity with current member compensation.

Proposed Changes

Transaction 1: Funding The Score Management Committee for New Committee Members

  • Description: Transfer additional funds (24K cUSD) to the existing Score Management Committee multisig wallet to fund for retroactive compensation of new committee members
  • Destination: 0x765DE816845861e75A25fCA122bb6898B8B1282a (cUSD contract)
  • Data: approve(address spender = 0x68ce71d4CECA3003701ca6844D9a345925407455, uint256 value = 24000000000000000000000 (24K cUSD))
  • Value: 0

Transaction 2: Update Safe Multisig Wallet (Action for current The Score Management Committee)

  • Description: Extend the safe multisig wallet to include new committee members’ addresses.
  • Destination: Existing multisig wallet for Score Management Committee 0x68ce71d4CECA3003701ca6844D9a345925407455.
  • Data: Add the following addresses to the multisig wallet:
  • Value: 0 CELO (no direct value transfer for this action).

Rationale

The initial formation of the committee occurred prior to the hard fork, resulting in a structure that did not account for expanded post-fork responsibilities. The extended committee began working immediately after the hard fork, ensuring continuity in ecosystem management. This proposal ensures governance alignment with operational realities while compensating all contributors fairly.

Verification

Voters can verify this proposal by:

  1. Reviewing the original Great Celo Halvening Parameters proposal where the Score Management Committee was established: Set The Great Celo Halvening Parameters
  2. Confirming that work has already commenced with an extended committee structure
  3. Verifying that proposed compensation aligns with existing member rates

Risks

  • Governance Misalignment: Retroactive formalization addresses any discrepancies between governance records and current operations.
  • Budget Impact: Additional funding is proportional to established compensation rates and ensures fiscal responsibility.

Useful Links

3 Likes
2

Here to confirm that this is my address: 0x0330F6bE6aCE2D975b4aC7Be109C46015C508BB1

1 Like
3

I want to start off by stating that running of community RPC nodes by the former validators are a necessary step toward true decentralization. They enhance Celo’s censorship resistance and reflect the values this ecosystem strives to uphold. The idea in general deserves strong backing, and I support the creation of a committee to progress this effort.

However, I have some concerning issues about how this initiative has been introduced and managed.

First and foremost, the way this committee was proposed is concerning from a governance perspective. The introduction of the committee was buried within an unrelated tokenomics proposal. It took me some time to find the relevant changes here: Martinvol/l2tokenomicsfixes2 by martinvol · Pull Request #589 · celo-org/governance · GitHub. A structural governance change like this must be transparent and clearly communicated; not hidden under the guise of unrelated tokenomics changes. Even more concerning is that the discussion around the committee only began long after the initial draft was posted, well after community attention had faded. Most participants had no reason to believe that such a significant addition had been made.

This reflects a serious lapse in the governance process. Guardians should have insisted on a new standalone proposal for the committee. Credit to @0xGoldo for raising the issue — but it should not fall on one person to enforce governance discipline. While I do not believe the proposer @martinvol acted with bad intent, inserting a committee into an unrelated proposal (See PR above) was inappropriate and has damaged the legitimacy of the process.

Also, there is no transparency around how the 3 original multisig signers were chosen (2 of the latest signers seem to have volunteered in the original draft proposal).
There’s no record of when or how these individuals were selected, and no forum attestations from them confirming that they even hold the multisig keys. Now we are in a situation where the multisig has 1 confirmed on-chain governance action and $36k sitting in it without any provable identity of the signers. Guardians should have pinged the multisig signers. The proposer should have tagged their forum identity.

Additionally, The committee is requesting $2,000 cUSD per member per month — totaling $10,000 cUSD monthly. While I support compensating contributors fairly, there must be a detailed breakdown justifying this amount. What exactly are the deliverables? Who are the software developers? What software is being built? What are the credentials and responsibilities of each member? The reference here Set The Great Celo Halvening Parameters - #3 by Thylacine is very vague in my opinion.

Lastly, community feedback appears to be ignored. Despite several community members providing thoughtful responses in the “Great Halvening” forum thread, the original proposal draft (Set The Great Celo Halvening Parameters - #3 by Thylacine) does not seem to have been updated at all.

To move forward responsibly, I recommend:

  1. Merging the original draft (Which has already been passed) into this one to give the community clear visibility.
  2. Actively incorporating feedback from validators and other ecosystem participants.
  3. Providing a detailed explanation of what exact problem this committee is solving, beyond uptime reporting (which, quite frankly, is a solvable problem that doesn’t require a high level of technical complexity).
  4. Disclosing the role and responsibility of each member along with their credentials.
5 Likes
4

Hi,

Thank you for your valuable feedback!
I will respond to this with my personal opinion (not the opinion of the committee!) below:

Merging the original draft (Which has already been passed) into this one to give the community clear visibility.

Personally, I think this proposal should just focus on the expansion of the committee and not be bloated with duplicate and already existing content. We may summarize everything in a separate forum thread.

I think the committee is operating as transparent as possible and will communicate every operation (e.g. Score Management Committee - Results for week ending 13/04/2025)

The current RPC (uptime-)requirements have been communicated on various different channels: Forum, dedicated Discord validator channel (main validator communication channel), CELO docs, Validator and Governance Calls

Actively incorporating feedback from validators and other ecosystem participants.

I personally think as much feedback as possible has been sought and incorporated in the limited time available. The L2 migration was very time and resource consuming for all ecosystem participants. The Score Management Committee was a late addition and we did our best to come up with a workable and viable plan for the next 6 months.

Questions and concerns have also been clarified by Aaron and Martin in the initial forum thread.

It appears that you also unfortunately missed the Celo Governance Call #65. We explicitly requested to present this sub-proposal to the community in this Governance Call, as we wanted to reach and inform as many community members as possible and answer all remaining questions in this limited timeframe.

You can watch the presentation of the Score Management Committee by Aaron here:

Providing a detailed explanation of what exact problem this committee is solving, beyond uptime reporting (which, quite frankly, is a solvable problem that doesn’t require a high level of technical complexity).

  • Independently monitoring the Existence/Performance/Availability of the RPC Endpoint of each elected validator off-chain.
  • Every week, the Score Management Committee will collate their measurements, aggregate and average their scores for each validator, for the week prior.
  • Updating the validator scores on-chain (setValidatorScore / ScoreManager contract)
  • Slashing validators on-chain (GovernanceSlash contract)

Disclosing the role and responsibility of each member along with their credentials.

Responsibilities for each committee member:

  • Running and maintaining additional infrastructure including DB and indexer for uptime tracking. The stack utilized is open-sourced for anyone to verify (GitHub - celo-community/rpc-uptime-data: Simple RPC checking stack developed in Node/Typescript). An own implementation can also be utilized to ensure client diversity and avoid single point of failures, some committee members are already working on their own implementations (I personally aim to run each available implementation to achieve redundancy and diversity).
  • Dedicated time for performance evaluation, collaboration, multisig operations, and transparent communication

Current committee members:

I have included my proof in the initial forum thread, thank you for your reminder! (Set The Great Celo Halvening Parameters - #28 by clemens) also can be verified here: Ethereum Verified Signed Message

Aaron and Dee will also update the initial forum thread to include their signer verification.

Thanks again,
Clemens

5 Likes
5

Thank you @clemens for taking the time to clarify the role and scope of the committee. Things are much clearer now.

From a purely security-focused perspective, I support a 3/5 or 4/7 threshold compared to to 2/3 for any multisig approval. This specific proposal makes sense from that regard.

That said, I still maintain that the governance proposal surrounding the initial proposal could have been better handled.

4 Likes
6

I agree, it could/should have been better handled and better prepared. Some of that is on me not reading the documentation and missing a few of the validator weekly meetings, as I was somewhat unaware this committee was even required until couple weeks before L2 migration, and had to hustle to get something going.

@martinvol had raised the issue in governance a few weeks before that we might need to be a little flexible leading into the migration as there might be a few hasty or updated proposals as they were still confirming things on the fly, and ultimately this proposal ended up being in that category.

1 Like