Hi @0xGoldo , appreciate the concern and I might have similar thoughts reviewing this from the other side.
Yes, this concept of the management committee was not fully formed while the original temperature check occurred. There were, however placeholders for these values. What we have appended to the existing governance proposal is:
- The address of the multisig that will be managing the scores
- An approval for the management committee for administration expenses and time
Some background, personally I had a bit of confusion around how this entire process was planned to operate. I had assumed the payments to validators (now RPC operators) was handled either by the protocol as normal, or by cLabs. That’s on me as I didn’t attend all the validator discussions recently due to other commitments.
After a discussion only very recently with @martinvol did I understand that no, the payments don’t happen automatically, and scores will need to be managed off-chain by a trusted committee (not ideal, but it’s a placeholder). I had already decided I wanted to visualize something related to the community RPCs on my company’s monitoring page Vido, so in the past I had put my hand up to help collect and manage scores.
@Dee and @clemens reached out to me in the same week, as they were also both working on some ideas related to the community RPCs, including a load balanced public endpoint and some other independent metrics collection.
With only a week to go until mainnet by this time, we quickly workshopped a solution and some starting metrics, and added the details to this forum post.
There’s nothing nefarious going on, simply time pressure to be prepared for mainnet. I would be very happy to extend the grace period to something like 1 month, if the community wants more time to collaborate on the metrics and slashing parameters. @marek mentioned to me that he desired the scoring and slashing to be fairly close to the current validator slashing parameters (12 hours or 8640 consecutive missed blocks), so what we’re proposed here is 100% a suggestion, and we would welcome discussion, or even a technically better or trust-less solution.
Regarding the payments, we did some rough calculations based on: developing, operating, patching and paying for infrastructure for the scores, meeting at least one a week, every week, to perform potentially dozens of multi-sig transactions to update scores for the validator set, and to slash non-performing nodes. Plus reporting and communication and all the unplanned work that goes along with it. Honestly we’ve probably under-shot the real-world impact on our other full-time jobs. I know you didn’t criticize the amount exactly, but I think it’s more than fair for the funds that it manages and the constant workload.
None of us are going to burn our reputations to try and grift a few thousand from the treasury, but we do value our time and experience. We’re all long-term contributions to the Celo ecosystem and just want to help with an interim solution while a better one is devised.
I understand operationally, this should have been proposed months ago for wider discussion, I agree. If the community doesn’t support it, I’m happy to hand it back to cLabs or another solution.
I think if the community needs more time, a good compromise could be to increase the grace period to something like 1 month or more, while the committee still collects scores, then we all can collaborate on a metrics/score/slashing setup. Happy to hear all suggestions or alternative proposals 
Remember 