Celo to Join Chainlink SCALE Program To Accelerate Ecosystem Growth

Governance
21

I had thought that Chainlink was very necessary for the Celo ecosystem and had voiced my desire for it to be implemented as soon as possible on various platforms. However, if this is how it’s going to happen, then I will vote against it. This proposal seems to have been made with the knowledge that we need them badly and is exploiting this need. As other members have also pointed out, the actual costs do not match up at all. Even if we put aside the fact that the cost does not match up at all, I do not think it is right to demand all three years of cost at once. Most of the amount requested in this proposal seems to be a fee for deploying Chainlink to Celo. I really wanted Chainlink to come to Celo, but if it’s going to be like this, then it’s better not to have it at all.

Also it is said that the unused fund will return to the Celo community, but no one from Celo is included in the multisig management. Why?

8 Likes
22

Are there any pre-commitments from Aave or GMX to join Celo after Chainlink enters the space? Correlation is not causation and it’s a rather expensive experiment to verify this hypothesis.

Celo was always a very unique chain with its set of values. I’m not sure if trying to be another DeFi chain throwing away multi-million grants is the way to go.

4 Likes
23

Although not yet at the desired size, Celo has a significant economic hinterland and community. Even in a bear market, we reached nearly 140,000 active addresses. This is a record. GoodDollar created 6,000 new users in just its first week. Despite being very new, 100,000 Celo Domains were minted via Masa.

However, I believe that Chainlink did not show us the respect we deserve with this offer. This is not just about our gain. Chainlink will also have the chance to enter a very important ecosystem and expand its market dominance through the Celo ecosystem. They will benefit from this too. But as far as I can see, Chainlink does not value Celo this way. I see this as somewhat dismissive. There is only one thing I ask of community members. Please remember that we are a Network that should not be overlooked in this way. We really have a strong network and community. We don’t have to accept the harsh terms imposed on us by Chainlink’s condescending attitude. Having Chainlink would have been nice, yes. But this is not the end of the world. Let’s not mortgage the future of Celo for Chainlink. We can consider other alternatives. Deep alignment with the Ethereum is an important item in Celo’s new roadmap. Maybe new opportunities for oracle solutions will emerge from there.

4 Likes
24

I was hearing AAVE deployment was being held because of the Chainlink integration issues

1 Like
25

Today I learned I need to be running a Chainlink node on Ethereum. :wink:

Regarding this proposal, I think everyone wants Chainlink deployed on Celo, but are balking a little at the upfront commitment.

Other than repeating a community discussion and rallying on-chain votes, what is the downside to reducing the CELO request and commitment to 1 year and then re-evaluating the economics? 3 years is a decade in the crypto-world.

4 Likes
26

Hi all, we appreciate the discussion and feedback that the Celo community has provided regarding the proposal. This comment should hopefully provide some additional clarity and insight into questions posted within the thread, particularly in regards to the amount of CELO to be allocated into the Rewards and Fee Pool.

Rewards and Fee Pool Structure

The CELO allocated as a part of this proposal will only be paid to Chainlink node operators (independent third parties) for the purposes of covering their operating costs of running oracle nodes on the Celo network. None of the CELO funds from this community proposal will be allocated to Chainlink Labs.

The allocated CELO that is the subject of this proposal will be deposited into the Rewards and Fee Pool contract, which will be jointly governed initially by Chainlink Labs, the Celo Foundation, and a Celo Community Fund representative. Quarterly reviews will also be conducted between Chainlink Labs and the Celo Foundation to provide an additional layer of ongoing governance and ensure continual alignment on services provided to the Celo ecosystem, including usage of current feeds, demand for new feeds, and management of the tokens in the Rewards and Fee Pool. If Chainlink Labs is not using the funds as prescribed to compensate node operators, the Celo Community representatives and Celo Foundation will be able to withdraw CELO from the Rewards and Fee Pool on their own and return them to the Celo Community Fund.

The creation of the Rewards and Fee Pool structure allows CELO to be drawn down over time (specifically a three-year period) in order to pay Chainlink node operators on Celo for their operating costs. This means that the CELO allocated as a part of the proposal will not be paid lump-sum to Chainlink node operators immediately, but effectively streamed over time. At the end of the program’s existence, post renewals, any unused CELO in the Rewards and Fee Pool will be returned to the Celo Community Fund.

Budgeted CELO

We acknowledge that the proposed allocation of 5,980,314 CELO is not an insignificant sum for the Celo community. However, this amount represents the upper bound of anticipated operating costs for Chainlink node operators on the Celo network over the next three years. This factors in numerous unpredictable variables that impact cost (described below), including factoring in the potential for significant growth of the Celo ecosystem over the next three years and a resulting increase in demand for oracle services.

Therefore, the amount of CELO to be allocated as a part of this proposal can be seen as the creation of a budget for the explicit purpose of covering operating costs of Chainlink node operators over a three year period.The pre-allocation of CELO to this budget is intended to allow for efficiently responding to market demand and meet the evolving data needs of dApps in the Celo ecosystem over the next three years, while also streamlining the payment process to Chainlink nodes as the Celo ecosystem expands. Furthermore, any CELO that is not used from that budget by the end of the program (e.g., costs were less than the upper bound) will be returned to the Community Fund.

When determining the upper bound of anticipated operating costs for this proposal, the following were some of the unpredictable factors taken into consideration:

Number of Data Feeds

The number of Chainlink Data Feeds to be deployed natively on Celo over the next three years will depend on user demand, but we anticipate by the end of the third year, there will be at least 100 data feeds, with potential for there to be much more. The exact number, however, will depend on how demand for such data evolves over the coming years. At launch, we plan to launch six data feeds around BTC/USD, ETH/USD, LINK/USD, USDC/USD, USDT/USD, and CELO/USD. We are happy to work with dApps on Celo to consider the data they require.

Additional Chainlink Services

While Price Feeds are the first offering to be launched by Chainlink on Celo under this proposal, the broader strategy also considers the launch of a wider range of Chainlink services in the future. This includes Chainlink VRF to support gaming/NFTs on Celo with verifiable randomness, Chainlink Automation to automate the execution of any Celo smart contract, Chainlink Functions to bring support for any Web API to Celo, as well as sustainability-focused Data Feeds to support the creation of meaningful climate and ReFi focused use-cases. We see Price Feeds as being the tip of the iceberg of oracle services, with other services arriving based on demand.

Gas Costs

Oracle networks like Chainlink Data Feeds publish data on-chain which incurs a gas fee for every transaction. The exact amount of fees paid for gas depends upon the supply and demand of blockspace provided by a blockchain. While historical data about a blockchain’s gas costs can be extrapolated to guess what the future costs might be, the actual gas costs may significantly differ as adoption of the chain increases. Particularly, once Chainlink oracles are made available on a chain, developers are able to build more applications, which attracts more users, which leads to greater transaction volumes.

Update Frequency

Chainlink Data Feeds update based on trigger parameters (heartbeat + deviation threshold), which impact how many on-chain transactions need to be made during a given period of time. The exact configuration of trigger parameters for a given feed depends on user demand and user requirements (e.g. derivatives vs. insurance), as well as the average volatility of the assets being tracked by the feed. Increased market volatility leads to more on-chain updates.

Market Volatility

The operating costs for Chainlink node operators, in addition to gas, are in fiat (e.g., cloud infra, data provider subscriptions, labor, etc). The gas markets for blockchains are also commonly priced in fiat, while being paid for in native gas coins. Given the volatility of market valuations for crypto assets (particularly over the past year), the amount of USD-denominated operating costs that a specific amount of CELO can cover can change significantly over time. We cannot fully predict what crypto asset valuations will be in the future, and therefore this proposal budgets in such unpredictability.

Celo :handshake: Chainlink

We believe this proposal represents mutual alignment between the Celo and Chainlink communities. By joining the SCALE program, the Celo community can accelerate the growth of their ecosystem by providing developers increased access to external resources provided by the industry-leading web3 services platform operating natively on their network. As the Celo ecosystem continues to grow and mature, the operating costs of oracle networks can increasingly transition to be fully covered by dApp user fees.

In addition, Chainlink is highly aligned with Celo’s focus on sustainability and regenerative finance (ReFi), such as by providing the climate ecosystem access to greenhouse gas emissions and other data to support automated carbon credit programs, reforestation through direct air capture, sustainable financing rates, parametric insurance, and more. By working together with the Celo community and supporting their ongoing climate-focused initiatives, we hope to build a more sustainable world powered by Web3.

Additionally, if you’re interested in learning more about this proposal, Roger Brogan, Van Vaziri, and Niki Ariyasinghe from Chainlink Labs recently joined the latest Celo Governance call where questions from the community were answered (recording, notes).

10 Likes
27

Thanks for sharing this proposal @CLL_Michael. I would be particularly interested to hear answers to the points raised earlier in this thread about the actual costs involved in delivering data feeds, which don’t seem to have been provided in your recent post. For a comparison, API3 have provided a fully costed proposal that is significantly cheaper, and promises better granularity and liquidity preservation for dapps through oracle extractable value.

2 Likes
28

It would also be interesting to hear if Chainlink plan to deploy VRF as a result of this proposal, which seems to be assumed (even thought it is only supported on a small subset of chains that data feeds are currently provided to), and which additional finished Chainlink products (not planned like DECO, CCIP, and Mixicles) will be deployed to Celo as a result of this proposal passing

29

Just an aside to devs here interested in smart contract randomness that Celo has a built-in pseudo-randomness source that accumulates pseudo-randomness from validators. You can use it for a small amount of gas. I’m not making any representations as to whether it’s better or worse in any way than other services, except to say that it is used in Celo’s proof of stake implementation to determine a randomized order of validators to propose blocks within an epoch, and in other places in the Celo Core Contracts.

5 Likes
30

Thanks Michael for this clarification.

I feel more comfortable knowing the CELO will not be going into a black box essentially to be sold for fiat up front and used for incentives/expenses. What do you make of the queries from this thread questioning why a shorter runway can’t be approved now up front? For example 1-year’s upper bound instead of 3?

If everything is going well, the community would be thrilled to green-light a second tranche of funding for the initiative. Plus having this flexibility allows variable CELO amounts to be requested in the 2nd, 3rd years based on the market (since some of the expenses are denominated in fiat terms).

Ultimately the magnitude of the request might not be an issue if the CELO in the reserve (120M) ends up in the Community Fund (as has been discussed of late), but until that’s a given I think it’s fair for the community to kick the tyres on this proposal.

4 Likes
31

If it’s streamed (similar to something like Llamapay) then you’ll have to set the conditions and the amount to be released each time the condition is met. Could you shine a little more light on that? Do node operators get paid with each update they perform? If so, what’s the amount and how did you come up with that number? That number is actually going to determine how fast the funds are going to be used and not the total amount that you’re asking for here. That’s also ultimately going to determine what makes its way back to the community fund.

Since there will be quarterly reviews will those streams be adjustable? Who makes the decision on that and on the basis of what. Since we’re not aware of node operator costs this seems to be a major issue?

How many node operators will this be delivered by? Are you going to be publishing those prices with each block (i assume not since you said you work on heartbeat & deviation)? When will you add more? Isn’t the actual operating cost for putting those 6 on-chain magnitutes lower than what you’re asking for here despite FIAT denominated costs? I think it would in general help to understand for what, when and how much node operators get compensated for. This somewhat ties to the above paragraph. It would help to know when node operators get compensated from the fee contract.

I’ve been developing on Fantom for the better part of 2 years. Back then in early 2021 it was announced that VRF and automation are finally making it’s way to Fantom after price feeds have being available for quite some time. It took another 1.5 years (june/july 2022) for these services to finally be available. What turnaround do we expect here? VRF seems to only be availabe on six chains and the same can be said about automation. There are some big chains that have price feeds yet none of these services? Will we be given priority treatment or can i expect a similar experience as on fantom here?

It would also be great to know if the CELO from this proposal would be counted towards usage of VRF and Automation. The current flow on fantom requires me to create a subscription and make payments in link which will most likely also be the case here? That means that users would still have to pay node operators on top of what they get from the proposal.

Most people that have critizied the amount are aware how exactly this works and have additionally pointed out that the costs still do not match up, especially considering that there will only be six feeds available in total.

Could we also have some answers on this?

Or this?

In general i’ve been interested in answers to a lot of Patricks questions but most of them have been skipped over?

4 Likes
32

I see only unnecessary and baseless projections about the future here. Instead of putting so much effort into making a 3-year term meaningful, it would be more accurate to revise this proposal with 1-year plans, as other members also agree. You say that a high amount is requested due to the increased gas usage as the Celo market expands. However, in this case, the Celo price will also increase in parallel and balance will be maintained. You are ignoring this. As I said, let’s not resort to these future projections to make an excessive request meaningful. Let’s move forward with 1-year, more predictable terms and thus discuss something more realistic. The current imaginary situation is of no benefit to anyone.

3 Likes
34

I will also vote no. As Patrick stated, there are still many unanswered questions regarding this proposal, and most importantly, it is a huge disgrace to put it to a vote while the community is still discussing it. This goes completely against Celo’s always advocated democratic principles. A great disappointment.

2 Likes
36

I see a lot of requests for a more detailed breakdown of costs and no explanations except that its not really expected that all the funds will be used and that any remaining will be returned. (did i miss it?)

However 3 years is a long time for funds to be tied up. Opportunities will be missed.

I don’t feel right voting on this without at least some methodology of what the numbers come from.

37

I appreciate the active discussion around this proposal both here on the forum as well as on the governance call last week (https://twitter.com/CeloDevs/status/1639382500580499456).

I wanted to provide some additional perspective on why I am personally excited about this proposal.

From one of my first conversations with Sergey many years ago to more recent interactions with the Chainlink Labs team, I have always felt strong alignment around accelerating climate use cases and regenerative finance (ReFi) as it has become known now. Beyond the direct benefits of Chainlink data feeds becoming available on Celo etc under this proposal, I am excited about the collective braintrust of the Chainlink Labs team and community becoming partners in our efforts towards a better, regenerative financial system and new opportunities and solutions arising from that.

I am going to be voting yes. Note: as always, Celo Foundation does not participate in governance decisions.

5 Likes
38

After doing my own research and talking with multiple community members, I have become more comfortable with this proposal and plan to vote ‘Yes’.

Here is what I learned that persuaded me to change my position.

Who decides which nodes are selected to provide data feeds to the aggregator contract?

I’ve learned that potential oracle providers must first submit an application to Chainlink Labs (Contact | Chainlink). Once received, the applicant must undergo a security audit and KYC process. Among other requirements, oracle service providers must be able to prove rapid response coverage. If a prospective oracle service provider passes the security audit, KYC, and technical requirements, then they become eligible to join a decentralized oracle network (DON).

The decision as to which oracle service providers are chosen from the pool of pre-approved entities to participate in the DON, is arranged by Chainlink Labs. Some of the attributes that are considered when deciding the composition of oracles in the DON include historical reliability and operational costs.

I personally think there is room for improvement here as this sort of decision process may become biased towards incumbents which could stifle competition, might have conflicts of interest, and may not lead to merit based outcomes. I am speaking hypothetically here of potential future issues. So far, it appears that they have done a sufficiently good job of selecting DON providers as evidenced by the uptime and reliability of existing Chainlink data feeds. With that being said, I ask the Chainlink team to provide as much transparency as possible related to this part of the process because I believe it will strengthen both our communities.

What about the Chainlink multisig?

Another area of concern that I raised is related to the Chainlink multisig. What I learned is that it is a 4-of-9 multisig for most networks and the signers are not publicly disclosed. The multisig has the authority to add and remove oracle service providers from each DON, upgrade aggregator contracts, and respond quickly in the event of a security event.

As someone who recently experienced an economic exploit, it is hard for me to argue with the idea of having the option to respond quickly when needed. Since Chainlink Labs decides which nodes participate in the DON, then a multisig is probably the right tool to implement that decision.

With that being said, I believe there is an area of opportunity for Chainlink to evolve into a more decentralized architecture. For example, the multisig could maintain the power to pause/unpause any specific oracle data feed in the event of an emergency and Chainlink Labs could continue to vet potential oracle services providers. But once an oracle service provider is approved, the set of oracles that comprises a particular DON could be determined based on how much stake an oracle has. Any decision to upgrade or change the aggregator contract could then be made by the elected oracle set. This sort of architecture would ensure that the set of potential oracle service providers has been verified and there is a ‘break glass in case of emergency’ key, but the DON composition would be decided transparently.

Who decides how much oracle service providers get paid?

Approved oracle service providers commit to providing a high quality level of service with Chainlink Labs, covering key aspects of node operator performance such as uptime, accuracy, and response time. The level of service provided is monitored and reviewed on an ongoing basis between the oracle service provider and Chainlink Labs’ node operator team. It is expected that the oracle service provider will be reasonably compensated for costs incurred including gas fees paid, server operating expenses, and labor as well as provide a reasonable profit. The payment process is coordinated by Chainlink Labs.

(As a side note, it was pointed out to me that my anecdote example of cost to run an oracle did not include labor, so I probably underestimated the total cost of running a data feed.)

Crucially in my opinion, a representative from the Celo Foundation will be allowed to audit the service quality and node compensation on a quarterly basis. That is a very important detail in my opinion because it allows for financial oversight and I trust that the Foundation would act if they felt community funds were being misappropriated. My initial understanding was that a representative from the Celo community would only be a signer for distribution of CELO at an aggregate level but I learned that there will be oversight at a more granular level.

In conclusion, while I see room for improvement, I am more comfortable with this proposal than when I first read it. Mostly because I have a better understanding of how the selection and service quality assurance process works, what the multisig rights are, and how community funds will be safeguarded.

12 Likes
39

Hi all, we have seen some questions about how funds are planned to be drawn from the Rewards and Fee Pool, so wanted to provide some additional clarity.

The plan is to draw CELO from the Rewards and Fee Pool on a quarterly basis (similar to past Celo proposals) based on the expected operating costs of Chainlink node operators for that next quarter. This is because CELO will be made available to node operators to cover their operating costs on an on-going basis preemptively, as opposed to making payments to node operators retroactively (as this would require nodes to cover their operating costs from another source before a reimbursement). Any CELO that is drawn from the Rewards and Fee Pool for a particular quarter that is not used will be rolled into the next quarter’s usage.

For each subsequent quarter, the previous quarter’s actual usage of CELO will be reviewed to determine how much to draw to cover the expected operating costs of the next quarter (while also taking into account how much CELO has been rolled over from the previous quarter). A part of this process also includes the quarterly reviews conducted between Chainlink Labs and the Celo Foundation, which will look at usage of current feeds, demand for new feeds, and management of the tokens in the Rewards and Fee Pool.

There have also been some questions regarding the proposed length of this proposal. The three year schedule was proposed based on establishing a long-term commitment for the economic support and on-going operation of Chainlink Data Feeds on Celo. This would reduce friction for the Celo developer community by guaranteeing the operating costs of Chainlink Data Feeds will be covered over this period of time, and therefore provide predictable access to external data. Furthermore, this also helps provide time for dApps to generate a sufficient amount of revenue to sustainably support the operating costs of Chainlink Feeds over time without a subsidy requirement.

While we are highly optimistic on the future growth and adoption of the Celo and Web3 ecosystem as a whole, it’s difficult to predict when exactly dApp revenue will reach a level to sustainably support all Data Feed usage, particularly as new feeds are launched to meet demand. If economic sustainability for Data Feeds is achieved within the three year period laid out in this proposal, then there would be a greater amount of unused CELO to be returned to the Community Fund at the end of the program.

7 Likes