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.
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.
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.
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:
API3 works with a wide array of dAPPs on zkEVM that utilize our real-time data feeds including:
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.
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.