Celo Infrastructure for Chain Lifecycle Operational Support (CICLOPS 🧿)

Governance Governance Proposals
1

Proposal Key Aspects

  • Receiver Entity: Celo Governance
  • Status: [DRAFT]
  • Title: Celo Infrastructure for Chain Lifecycle Operational Support (CICLOPS :nazar_amulet:)
  • Author(s): Eric (@ericnakagawa), Silas Boyd-Wickizer (@silas) & Martin Volpe (@martinvol)
  • Type of Request: Funding
  • Funding Request: We are requesting from the Community Fund, split approximately 50/50 in cUSD and $CELO i.e. $3M cUSD and [to be updated] CELO tokens at the 90d average of [to be updated] at time of on-chain submission.

Summary

This proposal outlines the need to fund technical infrastructure and primitives required to operate the Celo network and a pathway to decentralize this function to the community for increased long term resilience. It requests funds for the operation from Q4 2024 to Q4 2025.

We propose the creation of the Celo Infrastructure for Chain Lifecycle Operational Support or CICLOPS :nazar_amulet: for short. CICLOPS will be responsible for reviewing and funding key infrastructure required to run and scale the Celo network.

The time period for supporting infrastructure costs shall be from the end of 2024 to 2025. At the conclusion of this period, the community can reevaluate the next path forward: Celo will be an established L2, costs may be different, and new and improved methods for funding infrastructure may be available.

Motivation

As Celo transitions to an L2, it is important to ensure that key technical primitives and infrastructure necessary to operate the network have a sustainable source of funding and support. The list of infrastructure needs for any high-performance chain includes RPC providers, Indexers, Dev Tooling, Custody providers, Bridges, and Oracles (to name a few). Historically, the Celo Foundation has maintained private contract agreements and payments directly with partners through grants of varying sizes and over varying periods of time, usually in the 6 to 12 month range. However, as Celo continues its path to further decentralization, we believe that infrastructure benefiting the entire community must transition to being supported long-term by the community treasury.

This proposal aims to direct community funds towards network operations. It is inspired by examples seen in the MakerDAO ecosystem. MakerDAO’s MIP28, for example, proposed the creation of the Operational Support Domain to facilitate the protocol’s transition towards decentralization. This domain was tasked with providing essential services such as administrative support, coordination with stakeholders, and ensuring the continuity of operations.

Maker’s Operational Support Domain acted as a bridge between the foundation and the community, which included overseeing governance decisions, maintaining communication channels, and supporting the development of decentralized teams. This team helped set standards for operations as the DAO matured. This is a helpful mental model to understand how the infrastructure costs and operations can transition to the Celo Community.

Additionally, the Celo community funded the core L2 infrastructure development through a public goods framework with the Funding for cLabs Blockchain Public Goods Work proposal. This successful proposal shows the community’s commitment to supporting essential services that are critical to the long-term success of the ecosystem.

Metrics and KPIs

Success for this proposal means funding key infrastructure primitives so the Celo chain stays a competitive chain as it progresses to an L2.

Specification

CICLOPS :nazar_amulet: Overview

This effort will be led by Eric Nakagawa from the Celo Foundation and supported by cLabs and Valora, two long-time Celo Ecosystem teams.

The group will take no compensation from the budget requested. All funds from this proposal shall go towards fulfilling contractual agreements with service providers. Any revenue generated by onboarding infrastructure partners shall be directed back to the Celo Community Fund wallet for future use by the community.

To provide confidentiality to service providers, the Celo Foundation will issue payments on behalf of CICLOPS for as long as is needed, with a goal towards providing more transparency that we think benefits the entire web3 industry broadly. The Foundation will also counter sign agreements where a party is needed on behalf of the Celo Community. In many cases of infrastructure funding, a counterparty is needed to provide confidentiality of the agreed fees, and to guarantee future payments for ongoing services. The Celo Foundation offers to perform this service, although any business entity within the Celo Ecosystem in future may also perform this service on the behalf of the Celo Community.

The Celo Foundation reserves the right to subsidize fees paid to providers on a case by case basis.

As stated above, the Celo Foundation and members shall request no fees for performing the services above.

Infrastructure Recommendations

Projects for consideration include providing infrastructure support for RPC providers, Indexers, Bridges, Oracles, Dev Tooling, Custody providers, and other related services. Each project under consideration must be important to ongoing blockchain operations, provide improved developer experience, offer novel and interesting functionality as a protocol primitive, or demonstrate meaningful value in other ecosystems. The goal of this initiative is to fund important infrastructure primitives that enable Celo to attract and retain the best dapp developers.

Infrastructure project funding requests shall be reviewed and approved by the members of the CICLOPS group (Celo Foundation, cLabs, Valora) on an occurring basis and prioritized by the need of the chain.

Funding Request

We are requesting from the Community Fund $5.85M, split ~50/50 in cUSD and CELO, specifically $3M cUSD and the remainder in CELO totalling 3,838,900 tokens at the 90d (9/20/24 to 12/18/24) at an average of $0.7424.

The requested funds shall cover some or all projected operational costs, necessary infrastructure updates, and any development enhancements across all selected projects.

To ensure flexibility and account for new infrastructure requests and any unexpected overhead, an additional buffer of $100,000 is included in the request.

A CICLOPS multisig wallet shall be created for the administration of funds. The multisig wallet address shall be appended to this forum post, and signers shall reply with their public keys.

Current Status

This is a new initiative.

Timeline and Milestones

Timeline for this proposal inclusive of Q4 2024 to Q4 2025. Proposals will be reviewed and paid on an as-needed basis.

Payment Terms

Due to the sensitive nature of agreements with partners. This group aims to provide confidentiality of payments by withdrawing funds in quarterly chunks and distributed as needed. To account for upcoming costs and some previously covered by the CF, the first withdrawal will be for 50% of funds. To decrease the impact to the Celo token price, the group will consider using more cUSD as part of the withdrawal. Future Celo token withdrawals will be converted using Celo Foundation’s process for minimizing the impact to the token price while still acquiring the needed funds or tokens USDC/USDT for payment to partners.

Team

The team will consist of one person from the Celo Foundation and representatives from long-standing teams in the Celo Community. The teams identified will remain the same throughout, but the specific person responsible may change. The proposed team includes:

  • Celo Foundation - Eric Nakagawa - Executive Director at the Celo Foundation
  • cLabs - Martin Volpe - Lead Engineer at cLabs (a Core contributor to the Celo Blockchain) and active Community Member
  • Valora - Silas Boyd-Wickizer - CTO at Valora (building MobileStack) and a long time contributor to the Celo Community

Multisig

Address for the 2 of 3 Multisig: 0xd71efa410B6EaAB0bAc3b515B393C886BE70F09E

Signers

  • Eric Nakagawa - 0x9AD631ff4518d4a2a7276D2dF0803F37EfA52080
  • Martin Volpe - 0x1a96E07fa5A4801b4881C2DC7B953D7356e26495
  • Silas Boyd-Wickizer - 0x738D3e9A97D2E2aE6F404D381570E1fb112176BA

Additional Support/Resources

n/a

10 Likes
2

Hi Eric, this is a followup from my comment about user experience in today’s governance call.

I believe in the aim of increasing the user base, good UX (especially for troubleshooting and safety) should be a plan for projects to have.

Recently I went through an issue of getting unstaked celo disbursed. After reaching out on Discord, github and then this forum, I was able to get help after about a week. During this time I had to ignore more than a dozen phishing attempts because I posted on public forums.

So in this case, there were two issues in my user experience: reaching out to someone about getting access to my money and safety against scammers. I’m pretty resourceful and trained against phishing attempts, but not everyone has my background.

I’m not sure how UX guidance will work because I know that good design isn’t a generic checklist :smile:. But I think projects should show that they have UX in mind for both sophisticated power users and the newbies who don’t know how to use Github.

2 Likes
3

Hi @fortunasoleil, I like the idea of providing better tools to our community for improved User Experience. For this to work, it could make sense to find a partner that provides this through a library or service.

Do you think instead that this would be design or developer educational materials? Or perhaps setting a bounty to the community to pull in best practices from our industry into a single resource?

2 Likes
4

I think all of the above are great ideas! There are already a lot of issues on discord and other public forums available to analyze and prioritize, so that could be a fun (?) collaborative effort by the community.

After doing some research around the web3 space, I see educational materials about user interface design, rather than more technical/robust user experience design. I’m pretty new to crypto, so if you have any insights on why this is, or perhaps if I’m missing something, I would love to get some guidance.

Using the example of my personal experience with unstaking I mentioned above, I was surprised that the stcelo team/app didn’t monitor unsuccessful transactions. I was surprised that they didn’t have something like a daily script to monitor transactions that didn’t work as expected. A service or template might be of use to developers looking to streamline the user experience and decrease the number of tickets that come in. If they can receive error summaries via slack or whatever, recurring issues can be resolved quickly.

It would be great to hear from the community more inventive ways to incorporate design along with technical infrastructure!

2 Likes
5

Hi @ericnakagawa , thanks for the proposal.

I’m all for progressive decentralization and protocol self-sufficiency, this feels partially like a step in the right direction.

I don’t want to be obstructionist in any way, if things need to get done and get paid, then that needs to happen. However, this proposal reads like a straight up funding top-up from the protocol treasury to the Foundation.

Who are the counterparties to these agreements? If one side of each agreement is the Celo Foundation in each case, isn’t this simply “we need to pay our previously contracted agreements, and we need the community treasury to pay for it”? Even worse, these agreements are not public, and we wont even know who is paid or why. Why can’t we transparently list who the providers are who make this operation tick? They should be proud to be supporting Celo, and the community should be pleased to be working with them and the services they provide.

Again, no one wants to scuttle a piece of core infrastructure funding (even more so since my own company could even be a beneficiary of some of this funding in the future), but this proposal doesn’t feel in the spirit of blockchain as an open movement. Is there a way we could get more insight into the existing liabilities and exactly what is planned for the future? Otherwise, the community is just writing another huge blank check to a proposal with trusted names attached to it.

I guess I missed the window to comment on this over the Christmas period and only getting to it now. I trust the signers here implicitly and don’t expect anything awry to happen, but it’s really hard for me to shake the optics of “trust me bro”. I hope in the future we can start to move away from closed-door B2B fee schedules and private contracts.

1 Like
6

We have some questions:

  • Why do service providers want confidentiality? It would be helpful to know which companies get funded and for what purpose.
  • In terms of infrastructure needed for the L2 transition, what is functioning and what areas need the most improvement? Would be good for the community to know.
7

Thylacine, always appreciate your feedback.

On confidentiality, infrastructure costs can vary widely from project to project and two projects may pay vastly different fees depending on that partner’s goals. Confidentiality around amounts and the names of partners helps shield the amounts and allows for reduced fees.

Another example around a need for confidentiality is for some infrastructure partners that have high costs for community proposals. One example partner has a sliding scale of yearly fees with 4 payment tiers: low 0.3x, mid 0.6x, high 1x, and highest 2x (when paid through a community proposal). By working with CICLOPS this particular infrastructure will reduce cost to the community by 50%.

One idea I have to help with sharing more information is to, publish the names of projects supported by CICLOPS a quarter or two following the funding but in a delayed fashion and with the infra partner’s cooperation. It still prevents real-time information and shields potentially confidential information while still informing the community but with a delay.

8

Hi FrankinDAO team, the need for confidentiality is usually around deal terms since costs can vary widely between projects a partner supports. For L2 infra needs, we want to ensure continuation of any existing active dependencies and working with cLabs and teams building on Celo to bring new partners online quickly.

In the reply above to Thylacine, I proposed publishing a community update (with a delay) on the projects supported by CICLOPS. One additional idea, is to include areas of focus for the following rounds.

9

0x9AD631ff4518d4a2a7276D2dF0803F37EfA52080 is my wallet for the CICLOPS multisig.

1 Like
10

Due to the size of the value of the proposal we’ve received feedback about expanding the number of signers on the multisig.

If the proposal passes successfully, then we will submit a new Governance Proposal that expands the multisig by 2 additional people.

If the proposal fails to reach quorum, then we will expand the multisig signers and resubmit the proposal with a larger set.

11

Looks like this passed but still needs approval by governance guardians.

1 Like
12

The Governance Guardians are not the one in charge of Approvals for Governance Proposals. Are the Approvers. You can find more info who the approvers are and what are their functions here

1 Like
13

0x738D3e9A97D2E2aE6F404D381570E1fb112176BA is my wallet for the CICLOPS multisig.

1 Like