API3 Data Feeds for the Celo Ecosystem

Governance
1

Abstract

This proposal seeks to bring API3 data feeds, called dAPIs, to Celo that will give developers access to a wide variety of data, hence opening the door for immense ecosystem growth for the network. API3 data feeds would be rolled out in two phases. With Phase 1, API3 would be introducing self-funded data feeds to the Celo network, which is oracle infrastructure that can be accessed permissionlessly by anyone. These data feeds simply need funding to be sent to a specific wallet and they will begin operating automatically. Self-funded data feeds are single source, which is why managed data feeds are introduced with Phase 2, which will bring with it aggregations and gas management by API3 and its partners.

This proposal was drafted by the dAPI team of the API3 DAO.

Background

Celo prides itself with building things that matter in the real world while having accessibility for everyone, sustainability for the world and scalability in mind. Many of the use cases that allow for the development of DeFi and ReFi primitives rely heavily on data to the real world, which means that this data somehow has to find its way onto Celo. This is where oracles come into play. They fetch data from the ‘real world’ and bring it onto the blockchain so that dApps can utilise them to build, innovate and create.

About API3 – First-Party oracles for the masses

When it comes to oracles, many of you probably only heard about Chainlink, and for obvious reasons it is also one of the proposals that this one is standing up against in this forum. As a matter of fact, we at API3 began as Chainlink node operators ourselves, before we realised we can accomplish things more efficiently and more transparently by making data sources run oracles themselves directly instead of relying on a middlemen layer to operate them.

With this mission in mind we developed and built out an oracle solution that is optimised for data sources instead of middlemen and we’ve specialised in and coined the term ‘first-party oracles’. Mainly third-party oracle networks, like Chainlink, already must trust in these same data sources, but additionally involve several third-party node operators in fetching and bringing required data on-chain. Not only does this approach involve more people in the process, and hence requires more trust, but it also drastically increases costs of operating an oracle network because of efforts made to secure this middle layer, through e.g. staking mechanisms, as well as paying these third parties alongside the data sources.

In addition, third-party networks most often do not reveal which and how many data sources are used within their products, which practically goes against everything web3 and the blockchain industry stands for – transparency and verifiability. All that you can see is black boxes spitting out numbers, which are then aggregated without any ability to verify how they came up with them. This opaqueness creates a huge transparency and trust issue because how can data consumers confirm what we are actually consuming without trusting a centralised entity and their word? How can the risk profile of a feed be assessed if the makeup cannot be determined by everyone independently of a single entity? How do you know that this entire oracle network isn’t depending on a singular data source? It all boils down to trust - the thing blockchains were supposed to minimise or even remove entirely.

940×449 61.3 KB

First-party oracles change this. When the data source runs the oracle and you aggregate between these sources you:

  1. Remove trust that was introduced with the addition of middlemen that simply relay data

  2. Remove costs that were introduced with the addition of middlemen

  3. Remove opaqueness and create fully verifiable end-to-end transparency between data producers and data consumers

Most of the API providers that power Chainlink nodes by giving them their data are actually running API3 oracles themselves directly. Among these are Finage, NewchangeFX, TwelveData, dxFeed and many more. This means that by choosing API3 data feeds, you’re receiving data directly from them, instead of receiving the same data relayed through a third-party network.

API3 differentiates its data feeds between self-funded data feeds and managed data feeds. Self-funded data feeds can be seen as an introduction and basic oracle infrastructure. They are single source and have an associated wallet. A self-funded data feed will begin operations whenever funds are made available to it and can be accessed entirely permissionlessly, and will stop operating whenever these funds run out. We have recently released the first phase of our data feeds, self-funded data feeds, and they can be accessed on over 10 networks and 11 testnets. You can find and play around with them on the API3 Market. They are a great introduction and can also be used as “plug-and-play” oracles.

Managed data feeds can be seen as the ‘pro’ version of API3 data feeds. Here, data feeds are aggregated between multiple first party oracles with API3 and the data sources picking up the gas management overhead. Self-funded data feeds will be upgradable to managed data feeds over the API3 Market by paying for them. Managed data feeds are expected to be available within Q2 of this year.

In both cases, self-funded and managed alike, data is accessible for free by anyone once it is on-chain. This means that if Celo decides to allocate funds to self-funded data feeds or pay for upgrades to managed data feeds, everybody on the Celo network will be able to benefit from them for free.

Proposal

To bring API3 data feeds to Celo, we’re asking for 50,000 USDC as a one time integration payment with an additional 40,000 CELO per month payment over a year, totalling 480,000 CELO, for the following things:

  1. 25,000 USDC upon integrating self-funded data feeds to both Celo Mainnet and Testnet and making cryptocurrency and forex data available on Celo and accessible over the API3 Market, which can be accomplished within 1-2 weeks after approving the proposal.

  2. An additional 25,000 USDC payment upon making managed data feeds available on Celo Mainnet, expected to be ready within Q2 of 2023. Managed data feeds will also make equities and commodities data available alongside the other offerings.

  3. 40,000 CELO per month when managed data feeds are ready to upgrade and make access to managed feed available for free to anyone building on Celo

In addition, API3 will, in collaboration with all available data providers strive to fulfil any data wishes that the Celo ecosystem might have. Our providers are willing to provide traditional financial instruments, cryptocurrencies and can also build out specialised solutions where there is demand for it.

The 40,000 CELO per month will be used to cover gas costs for operating managed data feeds. API3 will make a public dashboard available that will list our consumption in detail. In addition to the gas costs we’ll be charging 20% of the consumption as our revenue. This revenue will cover infrastructure costs of API3 and the data sources operating oracles. Any unspent CELO after gas costs and our revenue margin will be sent back to the Celo community fund after a year or kept and counted towards the balance for another year if a follow up engagement between API3 and the Celo Community materialises.

An example calculation could look like this:

  • API3 receives 40,000 CELO each month for a year totalling 480,000 CELO.

  • Gas costs come in at 20,000 CELO per month for the entire year, totalling 240,000 CELO.

  • API3 charges 48,000 CELO as revenue margin to cover infrastructure costs

  • 192,000 CELO are left at the end of the year, which is returned to the Celo community fund

We do not expect managed data feeds to cost 40,000 CELO per month, but to account for gas spikes, increased demand in new data feeds and other unforeseen events, API3 wants to maintain a reasonable balance to accommodate for any wishes or issues. Additionally API3 also maintains its own gas management balances that will be used if any shortcomings arise due to any unforeseen events.

Management of funds and transparency for the Celo Ecosystem

The data feed management team of API3 operates multisignature wallets on each chain that our data feeds are available on. These wallets are used to spread out required funds as well as manage data feeds in accordance with our security considerations. Requested CELO would be made available to this multisignature wallet and returned from here as well. API3 also collects all data feed related blockchain data and makes available statistics, which will allow us to build dashboards that can display data feed performance and consumption in real time, akin to our QRNG dashboard, allowing the Celo Community to track everything seamlessly thus holding API3 accountable at all times.

Conclusion

The Celo ecosystem has massive potential and the introduction of easily accessible data feeds will help immensely to bring it to fruition. API3 is uniquely positioned to help the Celo ecosystem in this endeavour by delivering data in a fully transparent, scalable and efficient way, which will help the Celo ecosystem grow within its aspired areas of DeFi and ReFi.

Final words

I am aware that there is already a conflicting oracle proposal present, which is why I am making myself available for any questions, community calls or other things that the Celo community might need in order to process this proposal. I thought it was important to offer an alternative to what I think is an unreasonable amount of money that is being asked for by an industry leader. Obviously the Celo community is still free to go with the other proposal; we merely wanted to have presented an alternative in your governance discussions.

You can read more about API3 on our website and in our data feed docs.

5 Likes
2

I’ve voiced support for API3 oracles in the past, and continue to believe that DAO-native oracle projects have an important place in any decentralised ecosystem. As Celo moves deeper into RWA and ReFi, the diversity and availability of oracles will become more and more important.

4 Likes
3

I guess the assumption is Chainlink price feeds will be a gateway to other things like VRF, Functions, DECO, Automation, CCIP, which I’m not sure API3 currently provides?

4

Hey Alesh!

that is correct. We currently primarely focus on data feeds.
In addition we provide a QRNG service in collaboration with Quintessence and the Australian National University. They’re making this service available for free. It is however a trusted setup that is merely enabled through our oracle node. There would be the potential of making this available on Celo as well.
There are also ideas and sentiment floating around to concentrate on a dQRNG service towards the end of the year, which would focus on making this service available in a fully decentralized fashion, but as i mentioned our primary focus atm is on data feeds and most importantly OEV.

QRNG is currently heavily used on Arbitrum, Arbitrum Nova and Moonbeam.

As for the other things, yes they are currently not a focus of API3.

5

Thank you very much for bringing this proposal. I believe that discussing and evaluating this proposal in detail would be beneficial for Celo.

We have learned firsthand how harmful monopolies can be in the industry. Therefore, supporting organizations that could be alternatives to Chainlink would be in the best interest of the entire crypto world. From my research, API3 appears to be a reputable network that delivers on its promises. Members who are more knowledgeable than I am about costs can address the details. What I really want to see is statistics on how stable API3’s data feeds are working on the networks where they are currently deployed. I would appreciate it if you could share more information on this.

1 Like
6

So the API3 team would have full custody of the CELO funds received from this proposal, and we would have to trust that the team will faithfully return any unused funds? You mention accountability, but it’s not clear what can be tangibly achieved when API3 would hold all the cards after funds are transferred over. Why should we have to trust you and your team here? What’s stopping you or your team from rugging the community?

In Chainlink’s proposal, the funds would be put into a pool jointly managed by the Chainlink team, Celo Foundation, and community representatives. So if any funny games happen with Chainlink, those representing Celo on the multisig can transfer funds back the community at any point in time. That seems like a large missing layer of protection here.

I’m not sure I really understand this argument. The two proposals are structured extremely similarly where CELO tokens would be put into a pool, the respective oracle teams can pull CELO from that pool to cover oracle costs over time, and at the end of the program, any unused tokens are returned to the community.

The primary difference with this proposal seems to be that API3 will have 100% control of token custody, Celo devs wouldn’t have access to the other oracle services that Chainlink plans to launch (VRF, Automation, Functions, CCIP, etc), and that API3 simply isn’t budgeting to put as much data on-chain as Chainlink?

If we assume that API3 would support the same data feeds and update frequencies as Chainlink data feeds, this API3 proposal would probably cost the community more, given that API3’s on-chain data aggregation with managed feeds is significantly more gas intensive / less scalable than Chainlink’s off-chain aggregation data feeds with OCR. The Chainlink proposal looks to have a budget that accounts for more unknown unknowns when it comes to cost and demand of oracles and adoption of Celo in general.

How did you determine that 40k CELO per month was the proper amount for this proposal? What were the calculations and assumptions made that concluded that was the proper amount to budget for? How was the 50k USDC determined for integration costs? What happens if you go over budget?

Are there any users on Celo currently lined up and waiting to use API3 oracles or have signaled their interest? There’s a proposal on the Aave forum to deploy Aave v3 on Celo, and I know that Aave only uses Chainlink oracles, but is there a similar level of demand for API3?

I’ve seen Chainlink feeds work pretty well over the past few years for apps like Aave, Compound, Synthetix on other chains, but not sure if we have the same evidence of reliability and usage for API3. Would we serving as the guinea pigs for API3 managed feeds? Who else uses managed feeds? How much relative value have managed feeds secured in total? Would you be able to guarantee the same level of performance as other oracles like Chainlink?

7

Hey CeleryShock,

we’ve outlined two options that the Celo Community is free to chose from. One is a monthly transfer and the other is a yearly upfront payment. How much risk the Celo community is willing to take is adjustable by the Celo community.
Alternatively we’re obviously open to the idea of managing the funds on a multisig that is shared between the Celo community and API3 with an equal amount of signers on both sides.
What we cannot do is use our existing multisig and add you as signers since that has contract level control of data feeds.

So the path forward here really depends on what the Celo community wants and we’re very open to accomodate those wishes. :wink:

We’re not asking for the funds to necessarily be put into custody with us more than what is needed for a months worth of operation and if the Celo community choses to go with monthly transfers from the Celo Community fund, that is totally accomodatable by us.

Again, if we would have 100% control of the tokens depends on what option exactly the Celo community choses. Additionally i want to mention that having 1 signer from the Celo Foundation in the other proposal doesn’t really constitute “control” if the remaining signers are all Chainlink affiliated, but i presume that’s something that the Celo community already considered.

Unsure where this assumption stems from as i’ve nowhere stated how data makes its way on-chain. We aggregate off-chain primarly, have on-chain fallbacks in addition to external parties also being able to update data feeds in a tamper proof way, through signed data, with OEV soon.

For self-funded feeds, as we see this as the basic entry level oracle service, we provide the same deviation across all chains:

  • 1% for crypto
  • 0.5% for stablecoins
  • 0.5% for forex

For managed feeds the granularity is adjustable and depends on what the Celo community wants. Our base assumption here is that important assets for the Celo ecosystem will be ran at very low deviations whereas other assets have more “wiggleroom” in terms of deviation requirements.
Additionally i want to mention that with our rollout of OEV, many more strategic parties will be involved in updating API3 data feeds, which will result in even finer granularity with no additional costs.

a lot of things i cannot reveal at current times because the managed feed rollout is in the future and agreements signed with dApps are not disclosed until the release. Happy to come back to this question after the rollout and affirm the Celo Community with other dApps making use though.

I guess the answer to this is a yes and no. No in the sense that, we’re currently running managed feeds and have dApps testing them on testnets. This upcoming quarter will be mostly spend on surrounding things for managed feeds, e.g. payments over the API3 Market, as the infrastructure side of things is already complete. Yes in the sense that if we made managed feeds available on Celo immediately after they’re available, you’d be among the first rollouts.

It’s a service that is not live yet, which also means that disclosure of dApps having integrated them isn’t something that we can make available beforehand. As such it is also hard to provide numbers for secured value (because it’s 0) or bring up a direct comparison with a live product.
Again something i’m happy to come back to later down the line :slight_smile:

Hope that answers all of it!

2 Likes
8

Hey Erayda,

with self-funded data feeds you are free to play around on over 10 mainnets and over 11 testnets over the API3 Market. As for managed feeds, since it is a service we provide in the future, it is hard to provide you with hard statistics as of this moment.

When it comes to costs of putting data on-chain this depends on various different parameters. How often and under which conditions is a feed updated? How many assets are supported in total? How volatile are these assets? What we calculated above stems from the assumption that high stakes crypto assets on CELO are ran at very low deviations (below 0.5%), that other crypto assets are ran at 0.5% deviation, forex at below 0.5% and equities also at below that amount.

Another thing worth mentioning is that API3 does not require the operation of data feeds to be profitable. What we want to achieve is to mainly cover all associated costs, which is achieved by the 20% we charge on-top of the gas consumption. Our primary revenue/profit driver is going to be OEV.

When it comes to the two proposals, you’re effectively looking at funding a third-party network with great profit margins that needs to be profitable on exactly this business (cover costs + make it worth it) against one operated by the same data sources that those third-parties use directly, with the slight difference that they’re fine to break even on data feed operations. While data sources are a cost item that needs to be budgeted for by Chainlink, they’re not here as the data sources don’t charge themselves for access to their data.

If the Celo community wants i can also go into how precisly this works and what this magical term “OEV” is.

OEV Litepaper
OEV Article

4 Likes
9

Are you expecting this protocol to be using 40k of CELO every month in gas fees? I think thats more than all of Celo network consumes currently.

1 Like
10

Absolutely not, as stated below.

We have a lot of known knowns and a lot of known unknowns.
Which data feeds does the celo community want?
At what granularity should those be delivered?
What if network activity drastically picks up and the gas costs increase, which is most likely to be expected through e.g. us bringing a lot of activity and potential dApps that deploy. Etc, etc.

The reason for asking for this is to have a reasonable buffer to accomodate for a high stakes service, because running out of funds to operate oracle infrastructure is the worst case scenario. However, as i’ve tried to express above, we’re trying to be as transparent as possible with where those funds go at any given time and give you guys the ability to track everything in real time.

We want the community to feel comfortable entrusting us with this and not create the impression that we’re just trying to extract value.

1 Like
11

Can we see some performance on these? Also when in q2 since q2 is next week.

Same questions as in the other thread. how did you come up with that number?

Similar thing to what @Patrick asked in the other thread. Isn’t this centralized since you control the oracles that go into the data feeds…