In-depth analysis of API3, unlocking the Oracle Machine track of OVM

Recently, API 3 has recently secured a strategic financing of 4 million US dollars, led by DWF Labs and followed by several well-known VCs. The oracle track has always been dominated by the tripartite oracle represented by Chainlink. When I saw this news, I was also surprised~ Why can API 3 win financing? Will it break the circle of traditional oracles? What makes it unique? API 3, as a decentralized API (dAPI) project, is defined as the "first-party" oracle, and it solves the common problems of trust in the intermediary of the "third-party" oracle, low data transparency, and the control of OEV (oracle extractable value) through the innovative OEV Network (based on ZK-Rollup).

1. Can the Oracle Machine really predict the future?

The term Oracle Machine may carry some mythical color, which is easy to mislead the public. But in fact, it refers to a tool for providing off-chain real data for on-chain smart contracts, but what is real? How to ensure the integrity of the Oracle Machine itself? Will the Oracle Machine do evil? Will multiple Oracle Machines conspire? How to understand OVM (Oracle Machine Value Extraction)? In Q1 2024, the total value of locked tokens in DeFi projects reached a new high of $175 billion after the recent surge in BTC, a nearly 70% increase compared to $103 billion in Q4 2023. Oracles have always been regarded as the lifeblood of DeFi. In the DeFi space, decentralized exchanges (DEXs), lending platforms, and derivatives trading platforms rely on accurate price data to operate. In early 2023, the TellorFlex oracle contract used by the BONQ** decentralized lending protocol on the Polygon chain was manipulated, allowing attackers to modify oracle quotes at a lower cost and make huge profits through collateralized borrowing. As a result, the project suffered a loss of approximately $88 million. Attacks resulting from oracle quote manipulation have become increasingly common, highlighting the importance of transparent and reliable off-chain data as a fundamental guarantee for dApp operations.

2. How does the Oracle Machine connect off-chain and on-chain?

The working mode of the Oracle Machine generally includes three modes: timed uploading, event-driven, and request-response. Taking the general process of request-response as an example, it can be roughly divided into the following four steps:

• STEP 1: On-chain, the calling dApp initiates a request (essentially a transaction), and the Oracle Machine server contract triggers an on-chain event.
• STEP 2: off-chain, Oracle Machine nodes listen to events to obtain information and obtain accurate off-chain information through their respective systems
• STEP 3: Off-chain && On-chain, Oracle Machine provides data to the Oracle Machine service contract in the form of a transaction.
• STEP 4: On-chain, the Oracle Machine server contract returns the data to the caller (dApp). There are two options here: active push and secondary query by dApp.

For this process, let me further expand and explain:

First of all, on-chain requirements are public, because events are the universal mechanism of EVM-based blockchains, which means that the entire network can know that the Dapp now needs xx information.

Secondly, off-chain push is non-atomic, while on-chain transactions are completed in real-time. Off-chain data will inevitably have a certain degree of latency.

Finally, if there is a customized on-chain requirement, the oracle machine can be transformed into a third-party impartial role, and then pushed to the Dapp. However, for most general market data, such as the real-time price of BTC, the Dapp will obtain it from the contract again. Of course, the oracle machine itself also has a regular reporting mechanism, and the above few are basically the same.

3. Luna depeg, the surging Oracle Machine track

But blockchain is not only about Defi. Through the Oracle Machine, dApp can securely and efficiently obtain off-chain data, greatly expanding its business scope and application scenarios, allowing its business direction to extend to finance, insurance, supply chain management, internet of things, and more.

The current market, as shown by the defillama platform data, still sees Chainlink leading the way, with TVL (the total value of assets denominated in USD deposited in the market guaranteed by key infrastructure such as oracles) reaching 45% of the entire market.

Astute readers will notice that the curve on the right side of the chart experienced severe fluctuation in May 2022, triggered by the famous LUNA crash event. From May 7, 2022 to May 13, 2022, the leading algorithmic stablecoin UST experienced two depegging events, ultimately leading to a death spiral, resulting in the simultaneous collapse of LUNA and UST. Meanwhile, many projects using internal oracle machines experienced serious issues due to the delayed response to price fluctuations.

As can be clearly seen from the following figure, the market share of internal oracles (pink in the figure) experienced a cliff-like decline in May 2022. Chronicle Oracle (red in the figure) successfully captured this wave of traffic and basically won the market lost by internal oracles.

4. The Dilemma of Third-party Oracle Machines

In addition to the industry-shaking events, it seems that the development of the Oracle Machine has been stuck. Indeed, due to its clear industry positioning, it is simply a tool for on-chain data access, which results in relatively limited product functionality.

The most criticized is its profit model, currently focusing on data subscription fees and hoping for the appreciation of tokens issued by the project side. Obviously, the single profit model of data subscription generates limited income. Taking the fee function of VRF (Verifiable Random Function) provided by Chainlink as an example, referring to the blockchain browser Etherscan, the author has calculated that the total number of tokens locked by the VRF V1 and V2 contracts is about 370,000 (7+30). Based on the current LINK exchange rate ($16), the total revenue is approximately $6 million. Since the launch of VRF V2 in late February 2022, the total revenue is $4.8 million, averaging about $170,000 (1.1 W LINK) per month. Compared with the large volume of Chainlink, these profits are indeed insignificant. As for the expectation of token appreciation, it's a matter of personal perspective.

However, due to the nature of third parties, the oracle machine itself is relatively neutral and is beginning to serve as the security infrastructure for the application layer. Only by breaking the traditional middleware impression and carrying out differentiated and systematic functional extensions, can the profit margin be improved. For example, LayerZero, as a typical cross-chain bridge, places its security on the ultra-light node request head carried by the oracle machine.

In short, the predicament of the Oracle Machine in the market layer is that it is inherently disadvantaged by the operating mode, with a single function, meager profits, and untapped expansibility.

However, if we examine the execution model of the so-called third-party Oracle Machine, we will find that its problem also stems from the factor of being a 'third party'. As a rising star in the Oracle Machine industry, API 3 is positioned as a 'first-party' Oracle Machine.

4.1 Compare third-party and first-party Oracle Machines

API 3 chooses to activate the comprehensive operation and maintenance service capabilities of API service nodes as the entry point, and builds a bridge between the demand and supply sides of the oracle in a more web3 Native (lightweight + modular) manner. API operators can quickly build their own oracle nodes based on the Airnode solution provided by API 3.

As the first Oracle Machine project, compared to the traditional API suppliers→Oracle Machine→Dapp business process of third-party Oracle Machine, the transformation of (API suppliers + Oracle Machine)→Dapp in API 3 makes API suppliers take the lead and no longer just play the role of a third-party Oracle Machine worker, giving them more say.

As shown in the figure, without the involvement of third parties, the data chain is reduced. When the role of the API supplier merges with the Oracle Machine, there will be no problem of where the data comes from, because the reputation of the API provider is brought on-chain together with the data.

Due to the reputation of API suppliers and the strong binding strategy of providing data, the traceability is simple, and technically it is not allowed to do evil (without being discovered), while there is a margin mechanism as a guarantee. Even if the API supplier provides false data for personal gain, the damaged user can still appeal for compensation. For unclear events (such as malicious user complaints and fraud), they will enter the on-chain judicial system for arbitration. With the insurance mechanism provided by the completely decentralized API 3 DAO, API 3 can maximize punishment for API suppliers and provide compensation to damaged users.

5. In-depth Token Economy Model of API3 DAO

API3 DAO is based on its stake mechanism, which stabilizes the token economy model of API3 through positive and negative feedback loops.

5.1 Stake Governance Mechanism

Staking mechanism is a regular operation of DAO governance, which includes staking for profit and staking for governance. It is also the starting point of circular economy. Moreover, API 3 has been optimized:

• What if the staker runs away after receiving staking rewards? The inflationary rewards (newly minted tokens) generated from user staking will be delayed in distribution and will flow into the staking pool by default.
• What else can tokens in the staking pool do? They can be used to compensate users for losses.
• How does the staking pool stabilize token price? API 3 controls inflation through Burn and Token locking mechanisms: The exchange condition for accessing dAPI services is that users need to burn or lock their own tokens.

5.2 Positive and Negative Feedback Loop

In this way, what trend will the number of tokens in the staking pool show? Will there be uncontrolled expansion or a collapse due to insufficient payment for compensation? Let's analyze it.

• As the number of dAPI users increases, the system's risk will increase (the operating cost of the system will increase with the increase in the number of users), and the events that need to be compensated will increase. At this time, the tokens in the staking pool will decrease (used to compensate damaged users), and the stakers (and managers) will suffer losses due to mismanagement. However, the decrease in the number of tokens in the staking pool also means an increase in the number of tokens flowing into the market. Since the tokens held by users are affected by inflation, for their own benefit, a large part of the tokens still flow into the staking pool.
• When the number of dAPI users decreases, the system's risk decreases, and the number of tokens in the staking pool will gradually increase, making the number of tokens flowing into the market scarce. However, this does not mean that the number of tokens in the staking pool will continue to increase. The API 3 DAO will dynamically control the staking rewards (and inflation rate) to fit it to a target health value.
• The above two situations can form a positive and negative cycle as shown in the left side of the figure (a). When either situation reaches a threshold, the system will self-regulate, and dAPI users will tend to stabilize like the left side of the figure (b), ultimately leading the system to operate in a healthy state.

In fact, this type of Dao-style governance token has long been popular in various DeFi governance, such as the detailed implementation benchmark of decentralized stablecoin MakerDao's DAI, which I have analyzed before, has MKR as a pioneer:

Especially beautiful is its 4 auction mechanisms: Expandable reading: "One article explains the latest stablecoin GHO proposal of DeFI king AAVE"

The "insufficient assets to cover debts, four auctions" section.

So DAO-style governance is the mainstream operational mode of economic stability, but the innovation of API 3 is not inferior.

6. Unique Advantages - Pioneering OEV Network (based on ZK-Rollup)

6.1 The Birth of OEV

Similar to MEV (Miner Extractable Value), OEV (Oracle Extractable Value) refers to the value that the oracle can extract by leveraging its position that would have otherwise flowed to a third party. While MEV captures value through transaction ordering, OEV extracts value by taking advantage of the price difference between on-chain and off-chain, in scenarios such as critical market data or triggering significant on-chain events (such as liquidation).

To understand how OEV is generated, you need to know the current issues with the oracle machine: due to the cost of on-chain data, the oracle machine currently adopts a mechanism of uploading data at regular intervals, with the time interval set within a relatively small range. At the same time, in order to avoid large price fluctuations in the short term affecting the market, the oracle machine generally sets a threshold. When the price fluctuation range reaches the threshold within a short period of time, it will trigger an update proactively.

Although this remedy can alleviate some of the issues, the latency issue of data uploading cannot be fundamentally solved. And the DeFi market is usually highly fluctuating, and asset prices may change substantially in a short period of time. The uncertainty brought to the DeFi market by the feeding function of the Oracle Machine cannot be underestimated.

In this case, the third party profit-seeker is like opening a God's-eye view, and can capture huge profits by using the time delay of data updates, thus generating OEV.

For dApps relying on oracle machines, any updates or omissions in data feed may create opportunities for arbitrage, front running and liquidation for OEV. The problem of determining the ownership of exploitable value caused by data feed latency is difficult to assess. As data on the chain itself has certain volatility, if there is a delay in data on the chain and the problem cannot be attributed to the oracle machine, then the exploitable value generated by this delay cannot be considered as maliciously created by the oracle machine.

6.2 OEV Network—longer auction stage for multi-party games

Due to the existence of OEV, users and dApps, as the two parties interacting, are being exploited by third parties, which is clearly a situation that neither party wants to see. API 3 discovered that the Oracle Machine has the right to preemptively reject capturing all such value leaks (on-chain data pricing rights), hence the proposal of OEV Network.

As a Network based on Polygon zk rollup, he is a separate order flow (the intention of any participant to change the state of the blockchain is an order) auction platform, auctioning the right to update dAPI data.

API 3 has developed its own auction platform, eliminating the reliance on external services, allowing stakeholders to share OEV without having to share profits with the auction platform, internalizing OEV in all integrated data feed blockchains.

The successful bidder can obtain the right to update the price data of dAPI. Most of the profits from the auction will be returned to the dApp, and a small part will be used by API 3 to cover operating costs. Obviously, when the auctioneer (third party) thinks that the cost of the auction is less than the income brought by updating the price, the auction will be conducted, so the third party can also profit. As a user of the dApp platform, it seems that there is no actual benefit from participating in the distribution of benefits, but actually benefits from the high-quality data source provided by dAPI to dApp, which can better conduct transactions and risk management and obtain potential benefits.

The lifecycle of auction is shown in the figure below. When a searcher finds OEV, they initiate a bidding process. After winning the bid, the searcher will have the right to update the dAPI data of the oracle node, and only after paying the bidding fee can they exercise this right to update the dAPI data of the oracle node. The auction fee paid is the OEV captured and flowing to the dApp.

The trend of auctions is naturally for the third party (searcher) to further increase the bidding price for possible profits. The higher the auction price, the smaller the difference between the actual OEV and the captured OEV.

As for how big this cake is, let's wait and see. After the testnet runs stably for a period of time, we can make a judgment. The auction result is almost a win-win situation for the four roles: dApp, API 3 oracle machine nodes, third parties, and dApp users. The dApps that access API 3 data sources minimize the wool that can be harvested by third parties and can capture the majority of OEV value, because the ultimate form of market competition is competition among third parties. In order to seek profit space, the profits of third parties will gradually be compressed, and the ultimate beneficiaries will definitely be dApps. For API 3, a small part of the OEV value can be used to maintain the operation of the OEV's business path. For third parties, they can also get a share. For dApp users, by incentivizing highly specialized third-party participants to provide more insightful methods for determining when to update on-chain data points, granularity can be improved, ultimately benefiting dApp users.

So far, based on the OEV auction scheme of API 3, the issue of benefits distribution in the multi-party game has been maximally resolved, returning the 'erroneous profits' of the third party to the relevant stakeholders. Such a solution is truly elegant.

Expand reading: "UniswapX Research Report (Part I): Summarizing the Development Path of V1-3, Interpreting the Principle Innovation and Challenges of the Next Generation DEX" to understand the auction mechanism of UniswapX.

7. Summary

Based on its own tokenomics, API 3 has built a self-sustaining ecosystem, regulating the system's operation more stable through positive and negative feedback loops.

Meanwhile, the OEV Network proposed by API 3 cleverly solves the liquidity problem of OEV by introducing an auction mechanism for dAPI pricing update rights, and ingeniously transfers the contradiction between the oracle machine and dApps generated by OEV to third parties.

With the popularization and development of decentralized applications, the demand for reliable and secure oracle services will continue to rise, and the prototype of the next generation oracle seems to have emerged.

However, API 3 also faces some challenges.

The economic model is not something that can be defined and designed to operate stably in the long term from the beginning. The subsequent continuous process often falls into the situation of excessive governance or governance neglect.

And the core of API auctions lies in the measurement of reputation and income, which is essentially an optimistic model rather than a pessimistic model (ZK). Although LayerZero, which adopts the same reputation structure, has been operating continuously, even the high-risk combination of Oracle Machine + cross-chain bridges has not encountered any market problems, which can guarantee its security, but there is still a possibility of risks. And the continuous gambling on reputation means that the market returns for participants must be high enough, which is closely related to the market development of API 3.

Finally, the market for Oracle Machines is not easy to compete for, because the root cause is that what Dapps value most is not just the ability to provide data, but the positioning of the Oracle Machine itself as a third party. Now API 3 has broken this point, but Dapps themselves can also participate in auctions, inevitably making users worry about whether they will conspire on their own, although this also means risking the reputation of their Dapp. In addition, well-established chainlink and others can also follow suit, releasing more OEV to continue to control the market.