Deploy Compound v3 on Polygon zkEVM using API3 Oracles

Proposals
1

[RFC] Deploy Compound v3 on Polygon zkEVM using API3 Oracles

Background

API3 is an oracle project that is governed by a decentralized autonomous organization (DAO) and creates on-chain products using first-party oracles. API3 was established in 2020 and currently offers Crypto + FOREX price data on 11 chains, as well as Random Number Generation services on 20 different chains. API3 operates the API3 marketplace, market.api3.org, which allows for fully permissionless access to data feeds across 11 mainnets and testnets, with documentation on how to use the market here.

API3 acts as a native push oracle, similar to Chainlink, and can be integrated into any smart contract designed around using Chainlink feeds with minimal code changes. API3 is already used as an oracle by Tropykus on zkEVM, which is a Compound fork, as well as several perpetual projects and a stablecoin DEX. The future availability of Oracle Extractable Value (OEV) data feeds will both give API3’s feeds similar infinite granularity to a pull based oracle, and act as a way of preserving protocol liquidity.

Data Feeds

API3 data feeds are known as dAPIs, which are data feeds managed by the API3 DAO and powered by first-party oracles. First-party oracles are where data providers directly operate oracle infrastructure without involving any additional third parties between the data producer and consumer. This approach ensures full transparency of data sourcing and increases efficiency and security. Reputable data providers such as Finage, DXfeed, Twelvedata, NewChangeFx, and Tradermade are among those that run the first-party oracles that power dAPIs.

There are two types of data feeds: Self-Funded dAPIs and Managed dAPIs. Self-Funded dAPIs allow API3 to offer a wide variety of basic oracle data feeds. They are off chain aggregated, but maintained on chain by a single oracle, and can be funded by anyone through an associated wallet. The data feed operates using gas from this wallet until the gas runs out. It can be topped up at any time by anyone, and there is a tutorial to automate this process with Gelato available. These feeds can be accessed without permission and once data is on-chain it can be read by anyone. Self-funded dAPIs are currently available for 11 mainnets and testnets on the API3 Market. To activate them, simply send some funds for gas and updates will begin within 15 minutes.

With Managed dAPIs, multiple first-party oracles aggregate data directly on-chain, and the gas management overhead is handled by API3 and the data providers. Self-funded data feeds can easily be upgraded to Managed data feeds through the API3 Market by using the native currency of the respective chain. The cost is based on the operational costs of the respective dAPI. Managed dAPIs will be released by the end of this month, and should this proposal pass, API3 will ensure costs to upgrade data feeds used by Compound on zkEVM are covered for at least the first 6 months.

An existing Chainlink integration can be switched to API3 with changes to a single line of code. No additional technical work is required for an upgrade to Managed feeds, and no extra work is required to enable OEV recapture.

Optimized oracle infrastructure for Compound

API3 is, like Chainlink, a push based oracle - where data is expected to always be available on chain, maintained by the oracle provider and network of data providers. Dapps like Compound and AAVE have handled billions of dollars of TVL using push based oracles reliably for years, without exploits. Changing this battle-tested code to work with a pull-based oracle, where updates have to be manually triggered before each interaction with the protocol, could introduce exploit vectors.

To serve dapps that are reluctant to alter their code, pull oracles generally resort to something called a “price pusher”. A price pusher mimics a true push oracle, by triggering pull updates based on time or deviation criteria. However, it places a substantial responsibility on the protocol to not only operate the price pusher, but to also monitor the underlying pusher infrastructure. This includes its hosting location, the RPCs it uses, and more. This is a significant commitment for simply consuming prices. It can also quite frequently be seen that dapps rely on a single price pusher, which introduces a single point of failure to data feeds.

During network disruptions or airdrop events, dapps using pull-based oracles with a price pusher may struggle to update prices via RPCs, potentially leading to significant financial implications. Additionally, these dapps are potentially expected to bear the gas costs associated with this task, adding to the burden.

API3’s dedicated infrastructure ensures consistent on-chain availability. This reliability is a key feature of our push-based oracle service, particularly during high network congestion or black swan events. Highlighting this advantage of push based oracles is important, because the increased reliance of pull-based oracles in the broader ecosystem, while having its own merits for certain use cases, introduces risks that need to be taken into account.

OEV-Share

API3 is building towards data feeds that redirect MEV away from block producers, and deliver it back to dApps instead. This value is called Oracle Extractable value (OEV), and we are able to do this with our proprietary relay - OEV-Share.

As standard, API3’s data feeds have a conventional % deviation trigger for updates, and a time-based heartbeat design. OEV-Share enables searchers to trigger extra updates on top of these. The base feed still operates continually as expected, with OEV-share only allowing additional updates, not replacing conventional ones.

While the feed is operating, searchers compete in a series of auctions for the right to update data feeds earlier than normal. The winning searcher gets a pre-signed transaction that triggers a data feed update. This means instead of having liquidation priority determined by the block producer, searchers are able to bundle the data feed update transaction with their liquidation transaction to trigger liquidations.

The bid from the winning searcher is then returned to the dApp trustlessly, allowing dApps to retain on average approximately 40% of the value currently paid out to incentivize liquidations (as that is the approximate % currently taken by block producers that can be recaptured).

It would be entirely up to Compound to determine what to do with this OEV revenue, with examples being using it to reward liquidity providers, or to return it to the liquidated borrowers. Furthermore, the additional updates triggered by searchers result in a more granular feed for users. The improved granularity also helps preserve liquidity by allowing more accurate liquidations and helping prevent users losing any more than is needed. This creates a user experience similar to pull-based oracle designs, with the familiarity and ease of integration of a push-based approach.

The technical details of OEV Share are somewhat beyond the scope of a single forum post, and links to resources for further reading can best be found here:

zkEVM Ecosystem

API3 works with a wide array of dAPPs on zkEVM that utilize our real-time data feeds including:

  • Quickswap
  • ShrikePerps
  • Tropykus
  • Mantiswap

and many more soon to be announced. Compound’s deployment on zkEVM would bolster the rest of the zkEVM ecosystem leading to increased liquidity among all, and consequently higher utilization on Compound markets.

Conclusion

API3 provides an oracle choice that has the advantages of battle-tested push architecture, as well as the optional addition of Oracle Extractable Value data feeds later this year. Integration will require minimal changes to Compound’s code, and is already shown to be functional in a Compound fork on zkEVM. API3 will assist with integration wherever necessary, with API3’s developers planning to submit a PR of what an integration would look like for your review.

Integrating API3 would allow Compound to immediately deploy on zkEVM, and could also serve as a demonstration of how much value could be recaptured if Managed/OEV feeds were adopted on a wider scale, adding both security and revenue to the Compound Ecosystem. API3 is happy to answer any questions about this, and look forward to hearing feedback from the Compound DAO.

2 Likes
2

This means that this system has never been used in production anywhere i assume? On the links you’ve provided i was only able to find “Self-Funded dAPIs”, which are just single source oracles? I presume there are no users on the aggregated version? Are you suggesting compound as the first integration? Is there any risk assessment? Performance reports? Just generally curious because it seems like you’re trying to sell a product that is used by no other protocol and we have no history to judge the potential performance of it.

Also, what happens after the first 6 months? What are the costs? Who bears these costs? Are we expected to pay for them? If so, what are prices? A lot of open questions here.

What are these dApps using? The single oracle feeds? The aggregated ones? Not very clear here. I’m just going to assume it’s the first one, since you said the aggregated version is not out yet.

Since your aggregated version is neither out nor tested/risk assessed, is the suggestion that compound uses single source oracles?

1 Like
3

I would say it might be too early to actually deploy there. Liquidity is quite shallow on Polygon ZkEVM for now. There are so many l2 at this point that it’s quite reasonable to expect that most of them would actually “fail”. Not in technical terms, but just due to adoption going other way. There is just not enough liquidity for every chain to blossom.

In principle, the idea to have Compound there at some point might be fine. But i would say it sounds prematurely at this point.

1 Like
4

Hello dear Compound community!

sorry for the very late answer in this thread from our side. Paris was a bit of a hassle and i just couldn’t find the time to answer or comment on the things raised in this thread. I’m Ugur and i’m a product lead at API3, mainly responsible for the rollout of our data feeds as well as upcoming OEV-share feature. There is a little bit to unpack here so let me go line by line.

First of all, it is correct that the aggregated version, which we call managed dAPIs, is not in production anywhere, but we’ve obviously been running feeds for quite some time. We’re going to make the managed version available relatively soon which will allow any dApps that currently utilize our self-funded feeds to switch over seemlessly. As i’ve seen with other chain integration threads in this forum, the process to deploy compound takes quite some time, which is one of the major reasons we’ve already wanted to get the discussion started on here. We have a lot of users on Polygon’s zkEVM already and they will be utilizing managed dAPIs way before any potential Compound deployment.

The underlying update mechanism for our oracles is now battletested for roughly 1.5 years. In early 2022 we’ve launched a pilot with Amberdata to test our update mechanism and performance. In March of this year we’ve launched self-funded dAPIs, which is simply the extension of our pilot with added UX elements. Since March, we have users using these feeds in production without any issues. What i am getting at with this is that the mechanism of putting data on-chain has beeen tested for quite some time now.

The only change that we’re introducing with the managed version of our data feeds is that we’ll make aggregation available on them. All of our oracle nodes are hosted by API providers directly. You have no middlemen querying APIs and bringing them on-chain in an opague fashion. As such, the API performance is really what you’re asking for here. We’re obviously in constant communication with our API providers and in addition to all of these businesses having quality control departments themselves, we as API3 also monitor and communicate potential issues with them. Below you can find some grahpical material from an API performance report we’ve created at the beginning of the month.

image
image1122Ă—443 66.1 KB

image
image1083Ă—428 62.4 KB

That is a very good question! We’re in close collaboration with chains for potential grants and most of them are very willing to bear the costs for these data feeds. The good thing about our data feeds is that they have no access control. We’re merely trying to cover our overhead, but once the data is on-chain, anyone can read it for free. This makes is very appealing for chains to fund, since they can offer everyone building on their chain oracle services for free.

With that being said, we obviously cannot guarantee that the chains themselves will always pick up the tab. Our API3 Market will allow anyone to buy managed services for specific data feeds creating an order and paying in the native currency of the chain the service is bought on. Prices are calculated on the basis of asset volatility and chain volatility on a month by month basis. On rollups we will allow for subscriptions 3 months into the future. Current cost estimations, or rather first test calculations done at the beginning of the month, put an ETH/USD feed at 0.5% deviation to 1.16ETH / 3 months, which roughly translates to 0.39 ETH / month on Polygon’s zkEVM.

To also emphasize, neither API3 nor the API providers make any money on this. The amounts asked for here are used to merely cover gas overheads. The gas management is fully outsourced to API3, and if our calculations fall short, we obviously continue operations out of our own pocket until the end of the service. The neat part about our market is that you don’t need to talk to us in any capacity. No BD call or anything of that nature. You simply go to the interface, create an order, pay, and we’ll bring anything online that you need in a fully transparent and verifiable way. Below you can find some screenshots from the API3 Market in it’s managed form that will be released soon.

Yes, these dApps are currently utilizing single-source feeds. They will be upgraded to the managed version seemlessly soon though like i’ve stated above.

No, we’re fully aware that this is not an option for Compound. Chain deployments typically take time from being created in a forum, to discussions with the community around it, followed by technical discussions and potentially even testnet integrations. We think this process will take quite some time and our managed service will be running for a while until the process is potentially completed end-to-end by Compound.

I fully understand this! I can’t even keep up with the L2s that are launching every other week. Obviously i am very biased since we have an excellent relationship with the Polygon team, but they’ve been able to ship and gradually increase TVL and subsequently liquidity conditions relatively naturally. There are no token promises or anything, which obviously dwarfs chain activity on L2s like Optimism or Arbitrum where activity was heavily correlated with people expecting an airdrop. I’ve seen Polygon’s zkEVM slowly creep up from single millions to now fast approaching 100M and think this is merely the beginning for them.

I hope i’ve covered everything. Obviously, if there are any other questions, i’m happy to answer them, and do so quicker than the last time. Sorry for that again!
cheers

3 Likes
5

First time poster, so i was rate limited in terms of pictures. I’ll attach them here.

image
image1114Ă—428 49 KB

image
image1085Ă—393 54.7 KB

6

image
image1635Ă—862 135 KB

image
image1671Ă—752 87.3 KB

2 Likes
7

I’ll join @Sirokko in saying that this seems hasty. There are multiple aspects that are being clumped together in this proposal.

  1. the required service isn’t live yet and also has no track record of performance to justify Compound usage.
  2. Compound hasn’t tested a potential integration, so deploying on an entirely new chain with a new oracle seems risky.

Potential paths forward with this would be a deeper dive into the technology. Judging form the Linea<>Pyth proposal, it is detremental to understand how the proposed solution even functions. Simply claiming data will be on-chain is not sufficient. The community would also need to show interest in a new oracle solution as well as deploying on zkevm. This should be followed up with a proof of concept which could be a testnet integration, before anything else.

8

Hey @sleezy thanks for taking the time to read our proposal and your previous comments.

To your first point I’d like to formally announce that we have launched managed dAPIs on zkEVM and is available for compound to use at no extra cost. You can read more about managed dAPIs in this article where we stress our ethos of “don’t trust,verify”. We understand the risks that are associated with using a new oracle solution as well as deploying to a new chain and we want to alleviate some of those risks by being as transparent as possible in how we source and push our data. We want to elevate the oracle space into adopting better practices that will help dApps like compound expand to other blockchains seamlessly without relying on a singular oracle provider or a price pusher. We will be pushing out more technical-focused articles for critics such as yourself to help give us suggestions and improve. In the meantime, you can check out the following dAPIs that have been upgraded to managed and are currently being aggregated from 7 different sources (all transparent :slight_smile: ).

BTC/USD
ETH/USD
MATIC/USD
USDC/USD
USDT/USD
DAI/USD

If compound has any other data feed requirements, we would be happy to accommodate them for zkEVM