In-depth analysis of API3, the oracle track disruptor of OVM

Recently, API 3 recently received $4 million in strategic financing, led by DWF Labs and followed by several well-known VCs. For a long time, the oracle track has basically been dominated by third-party oracles represented by Chainlink. I was also surprised when I saw this news~ Why did API 3 get financing? Will it be a disruptor of traditional oracles? What is its uniqueness? As a decentralized API (dAPI) project, API 3 is defined as a first-party oracle. Through the groundbreaking and innovative OEV Network (based on ZK-Rollup), it solves the common problems of third-party oracle middlemen trust, low data transparency, and OEV (oracle extractable value) being controlled.

1. Can the oracle really predict the future?

The term oracle is somewhat mythical and can easily mislead the public. But in fact, it refers to a tool that provides real data off-chain to smart contracts on the chain, but what is real? How to ensure the integrity of the oracle itself? Can the oracle do evil? Can multiple oracles collude? How to understand OVM (Oracle Extractable Value)?
In Q1 2024, after the recent surge in BTC, the total value of locked tokens in DeFi projects also broke a new high, reaching $175 billion, which is nearly 70% higher than the $103 billion in Q4 2023. Oracles have always been called the core of DeFi. In the field of DeFi, decentralized exchanges (DEX), lending platforms, and derivatives trading platforms all rely on accurate price data to operate. In early 2023, the TellorFlex oracle contract used by BONQ, a decentralized lending protocol on the polygon chain, was manipulated . The attacker used a lower cost to modify the oracle quotation and then made huge profits for mortgage lending, resulting in a loss of about $88 million for the project party. Because attacks caused by oracle quotation problems are already common, it can be seen that transparent and reliable off-chain data is the basic guarantee for supporting the operation of dApp.

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

The working modes of the oracle are generally scheduled upload, event-driven, and request-response. Taking the general process of request-response as an example, it is roughly divided into the following 4 steps:

• STEP 1: On the chain, the caller dApp initiates a request (essentially a transaction), and the oracle server contract triggers an on-chain event

• STEP 2: Off-chain, oracle nodes listen to events to obtain information and obtain accurate off-chain information through their respective systems

• STEP 3: Off-chain on-chain, the oracle provides data to the oracle server contract in the form of a transaction

• STEP 4: On the chain, the oracle server contract returns the data to the caller (dApp). There are two solutions: active push and Dapp secondary query.

I will give an extended interpretation of this process:

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

Secondly, off-chain push is non-atomic, on-chain transactions are completed in real time, and off-chain data must have a certain lag

Finally, if there is a customized demand on the chain, the oracle can be turned into a third-party impartial role, and then pushed to the Dapp. However, most of the general market data, such as the real-time price of BTC, will be obtained by the Dapp itself by calling the contract again. Of course, the oracle itself also has a regular reporting mechanism, and the above types are basically the same.

3. Luna decoupling, the turbulent oracle track

However, blockchain is not just about Defi. Through oracles, dApps can securely and efficiently obtain off-chain data, thereby greatly expanding their business scope and application scenarios, allowing their business direction to extend to finance, insurance, supply chain management, the Internet of Things and more fields.

Todays market allows us to use the data from the platform defillama to show that Chainlink is still firmly in the leading position, with TVS (the total value of assets denominated in US dollars deposited in the market secured by key infrastructure such as oracles) reaching 45% of the entire market.

Careful readers will find that the curve on the right side of the above figure experienced a violent shock in May 2022. The trigger was the famous LUNA crash in 2022. From May 7 to May 13, 2022, the leading algorithmic stablecoin UST experienced two decouplings and eventually fell into a death spiral. Both LUNA and UST collapsed. At the same time, many projects using internal oracles encountered serious problems due to their untimely response to price fluctuations.

It can be clearly seen from the figure below that in May 2022, the market share of internal oracles (pink in the figure below) fell sharply. The Chronicle oracle (red in the figure below) took over this wave of traffic very well and basically took over the market lost by the internal oracle.

4. The Dilemma of Third-Party Oracles

Apart from the events that shocked the industry, it seems that the development of oracles has been stuck. Indeed, due to its clear industry positioning, it is a tool to connect data on and off the chain, resulting in relatively simple product functions.

The most criticized is its profit model . At present, its profit points are concentrated on two major directions: data subscription charges and the appreciation of tokens issued by the project party. Obviously, the single data subscription profit model generates limited revenue. Taking the VRF (verifiable random sequence) charging function provided by Chainlink as an example, referring to the blockchain browser Etherscan, the author counted the number of tokens locked in the contracts of VRF V1 and V2 versions, which is about 370,000 (7+30). Calculated at the current LINK exchange rate ($16), the total revenue is about 6 million US dollars. Since the launch of VRF V2 at the end of February 2022, the total revenue of 4.8 million US dollars has averaged about 170,000 US dollars (1.1 W LINK) per month. Compared with the large size of Chainlink, these profits are indeed a drop in the bucket. As for the expectation of token appreciation, it depends on personal opinion.

However, due to the characteristics of a third party, the oracle itself is in a relatively neutral position and has begun to cost the security infrastructure of the application layer. If we can break the traditional impression of middleware and carry out differentiated and systematic functional expansion, we can increase the profit margin. For example, LayerZero, as a typical cross-chain bridge, relies on the ultra-light node request head carried by the oracle for security.

In short, the dilemma of the oracle is manifested in the market level. It is limited by the natural disadvantages formed by the operating model, with single functions, meager profits, and undeveloped scalability.

However, if we expand the execution model of the so-called third-party oracle, we will find that its problem also comes from the third-party factor. As a new oracle, API 3 is positioned as a first-party oracle.

4.1 Comparing Third-Party and First-Party Oracles

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

As a first-party oracle project, compared with the traditional third-party oracle API supplier → oracle → Dapp business process, API 3s (API supplier + oracle) → Dapp transformation allows API suppliers to be in charge. They are no longer just third-party oracle workers and have more say.

As shown in the figure above, without the intervention of a third party, the data link is reduced. When the API provider and the role of the oracle are integrated, there will be no question of where the data comes from, because the reputation of the API provider is brought to the chain along with the data .

Due to the strong binding strategy between the reputation of API suppliers and the data they provide, tracing is simple, and they are not technically allowed to do evil (without being discovered). At the same time, there is a margin mechanism as a backup. Even if the API supplier provides false data for self-interest, the damaged users can still file a complaint for compensation. For entangled events (such as users maliciously complaining about insurance fraud), they will enter the on-chain court system for arbitration. With the insurance mechanism provided by the fully decentralized API 3 DAO, API 3 can punish API suppliers to the greatest extent and provide compensation to damaged users.

5. In-depth understanding of the token economic model of API3 DAO

API3 DAOs staking mechanism enables API3 s token economic model to operate stably through positive and negative feedback.

5.1 Pledge Governance Mechanism

The staking mechanism is a routine operation of DAO governance. Staking for profit and staking governance are also the starting point of the circular economy. In addition, API 3 has also been optimized:

• What if the pledger runs away after receiving the pledge income? The inflation income (newly minted tokens) generated by user pledge will be delayed and will flow to the pledge pool by default.

• What else can the tokens in the staking pool do? They can be used to compensate users for losses.

• How to stabilize the staking pool coin price? API 3 controls inflation through Burn and Token Locking Mechanism: In exchange for obtaining dAPI services, users need to burn their own tokens or lock their own tokens.

5.2 Positive and Negative Feedback Loops

In this case, what will be the trend of the number of tokens in the staking pool? Will there be disorderly expansion or collapse due to insufficient payment of compensation? Lets analyze it:

• As the number of dAPI users increases, the system risk will increase (the system operating costs will increase with the number of users), and the number of events that need to be compensated will increase. At this time, the tokens in the staking pool will decrease (to compensate the damaged users), and the interests of the pledgers (and managers) will be damaged due to poor management. But at the same time, the reduction in the number of tokens in the staking pool also means that the number of tokens flowing into the market will increase. Since the tokens held by users are affected by inflation, for their own interests, a large part of the tokens will still flow to the staking pool.

• When the number of dAPI users decreases, the system risk decreases, the tokens in the staking pool will gradually increase, and the number of tokens flowing into the market will become scarce. However, this does not mean that the number of tokens in the staking pool will continue to increase. API 3 DAO will dynamically control the staking income (and inflation rate) to fit it to a target healthy value.

• The above two situations can form a positive and negative cycle as shown in the left figure below (a). When any situation reaches the threshold, the system will self-regulate, and the dAPI user will tend to be stable as shown in the left figure below (b), eventually making the system run in a healthy state.

In fact, this type of Dao-style governance token has long been popular in various DeFi governance. For example, MakerDao’s DAI, a detailed implementation benchmark of decentralized stablecoins that I have analyzed before, has MKR as a pioneer:

What is particularly beautiful is its 4-way auction mechanism: For further reading: One article explains - DeFI King AAVEs latest stablecoin GHO proposal

Among them is the Insolvency, Four Auctions column.

Therefore, DAO-style governance is the mainstream operating mode for economic stability, but the innovations of API 3 are not inferior to it.

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 oracle using its position to extract value that would otherwise go to a third party. MEV captures value through transaction ordering, while OEV extracts value by taking advantage of price differences between on-chain and off-chain, such as key market data or triggering major on-chain events (such as liquidations).

To understand how OEV is generated, we need to first know the current problems of oracles: due to the cost of uploading data to the chain, oracles currently basically adopt a mechanism of regularly uploading data, and the time interval is set within a relatively small range. At the same time, in order to avoid huge price fluctuations in the short term affecting the market, oracles generally set a threshold. When the price fluctuation range reaches the threshold in a short period of time, it will actively trigger an update.

Although this remedy can alleviate some of the problems, the latency problem of data upload cannot be fundamentally solved. The DeFi market is usually highly volatile, and asset prices may change drastically in a short period of time. The uncertainty brought by the oracles price feeding function to the DeFi market cannot be underestimated.

In this case, third-party profit-seekers are like having a Gods perspective. By taking advantage of the time delay in data updates, they can capture huge profits, and OEV is thus created.

For dApps that rely on oracles, any update or loss of data feeds may create opportunities for OEV, such as front-running, arbitrage, and liquidation. Because it is difficult to judge the ownership of the exploitable value caused by data feed delays, the data on the chain itself has a certain volatility, so if the data on the chain is delayed a little and the oracle problem cannot be located, then the exploitable value generated by this part of the delay cannot be said to be maliciously generated by the oracle.

6.2 O EV Network—A multi-party auction arena

Due to the existence of OEV, users and dApps, as the two parties in the interaction, are being ripped off by third parties, which is obviously a situation that neither party wants to see. API 3 found that the oracle has the priority right to refuse to capture all such leaked values (the pricing power of on-chain data), so OEV NetWork was proposed.

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

API 3 developed its own auction platform, eliminating reliance on external services, allowing OEV to be shared between stakeholders without having to share profits with the auction platform, and internalizing OEV across all blockchains that integrate data feeds.

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

The life cycle of an auction is shown in the figure below. When a searcher finds an OEV, they will initiate a bid. After the searcher wins the bid, they will obtain the right to update the oracle node dAPI data. After paying the auction fee, they can exercise this right to update the oracle node dAPI data. The auction fee paid is the captured OEV, which flows to the dApp.

The natural trend of the auction is that the third party (searcher) will 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 pie is, we might as well wait and see, and judge it after the test network has been running stably for a period of time. The result of the auction is almost a win-win situation for the four roles of dApp, API 3 oracle node, third party, and dAPP users. The dAPP that accesses the API 3 data source is minimized by the third party, while capturing most of the OEV value, because the final form of market competition must be the competition between third parties. In order to seek profit space, the profits of third parties will be gradually compressed, and the final beneficiary must be dApp. For API 3, a small part of the OEV value can be used to maintain the operation of the OEV business path. For third parties, they can also get a share of it. For dApp users, by incentivizing highly specialized third-party participants to provide more insightful methods to determine when to update on-chain data points, the granularity can be improved, which will eventually radiate to the benefits of dAPP users.

At this point, the OEV auction solution based on API 3 has solved the problem of profit distribution among multiple parties to the greatest extent, and the original false profits of the third party have been fed back to the relevant stakeholders. This solution is really elegant.

Further reading: UniswapX Research Report (Part 1): Summarizing the V1-3 development chain and interpreting the principles, innovations and challenges of the next generation of DEX to understand the auction mechanism of UniswapX.

7. Summary

API 3 builds a self-driving ecosystem based on its own token economics, making the system operation more stable through positive and negative feedback regulation.

At the same time, the OEV Network proposed by API 3 cleverly solved the problem of OEV flow by introducing an auction mechanism for dAPI pricing update rights, and cleverly transferred the conflict between the oracle and dApp caused by OEV to a third party.

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

However, API 3 also faces some challenges.

An economic model cannot operate stably in the long term just because it is defined and designed at the beginning. The subsequent process will often fall into the situation of over-governance or neglect of governance.

Moreover, the core of API auction is the measurement of reputation and benefits. It is essentially an optimistic model, not a pessimistic model (ZK). Although LayerZero, which also adopts this reputation structure, has not had any market problems since its continuous operation, even the high-risk combination of oracle + cross-chain bridge has proved its security, but there are still risks. Continuously gambling on reputation means that the market benefits of participants must be high enough, which is closely related to the market development of API 3.

Finally, the oracle market is not easy to compete for. The root cause is that what each Dapp values most is not just the ability to provide data, but the third-party positioning of the oracle itself. Now API 3 has broken this point, but Dapps themselves can also participate in auctions, which inevitably makes users worry about whether they will collude, although this also means gambling on their Dapp’s own reputation. In addition, old brands such as chainlink are not impossible to follow up, and they can also release more OEV to continue to control the market.