Recently, API3 secured $4 million in strategic funding, led by DWF Labs and followed by several well-known VCs. Historically, the oracle market has been dominated by third-party oracles like Chainlink. Shisi was surprised by this news~ Why was API3 able to secure funding? Could it be the disruptor of traditional oracles? What makes it unique? As a decentralized API (dAPI) project, API3 defines itself as a “first-party” oracle. By leveraging the innovative OEV Network (based on ZK-Rollup), it addresses common issues associated with third-party oracles such as intermediary trust, low data transparency, and control over Oracle Extractable Value (OEV).

1. Can Oracles Really Predict the Future?

The term “oracle” carries a mythical connotation, which can easily mislead the public. In reality, it refers to a tool that provides real-world data to on-chain smart contracts. But what constitutes real data? How can the integrity of the oracle itself be ensured? Can oracles act maliciously? Could multiple oracles collude? How should we understand OVM (Oracle Extractable Value)?

In Q1 2024, following the recent surge in BTC, the total value of tokens locked in DeFi projects reached a new high of $175 billion, marking a nearly 70% increase from $103 billion in Q4 2023. Oracles have long been considered the lifeblood of DeFi. In the DeFi sector, decentralized exchanges (DEXs), lending platforms, and derivatives trading platforms all rely on accurate price data to function. In early 2023, the decentralized lending protocol BONQ on the Polygon chain was exploited due to manipulation of the TellorFlex oracle contract. The attacker modified the oracle prices at a low cost to conduct collateralized lending, resulting in massive profits and causing approximately $88 million in losses for the project. Such attacks stemming from Oracle price issues have become commonplace, highlighting the critical need for transparent and reliable off-chain data to support dApp operations.

2. How Do Oracles Connect Off-Chain and On-Chain?

Oracles generally operate in three modes: scheduled uploads, event-driven, and request-response. Using the request-response model as an example, the process 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 service contract triggers an on-chain event.
• STEP 2: Off-chain, oracle nodes listen for the event to obtain information and then gather accurate off-chain data through their respective systems.
• STEP 3: Off-chain and on-chain, the oracle provides the data to the oracle service contract in the form of a transaction.
• STEP 4: On-chain, the oracle service contract returns the data to the calling dApp. This can be done either through active push or by the dApp querying again.

Here’s an expanded explanation of this process:

Firstly, on-chain requests are public. Since events are a common mechanism in EVM-based blockchains, the entire network is aware that the dApp needs certain information.

Secondly, off-chain data push is non-atomic. While on-chain transactions are completed in real-time, off-chain data inherently has some latency.

Finally, if the on-chain request is customized, the oracle can act as a third-party arbiter and push the data to the dApp. However, for common data like real-time BTC prices, the dApp would typically retrieve the data from the contract itself. Additionally, oracles often have a scheduled reporting mechanism. The basic principles remain consistent across these different scenarios.

3. Luna’s Decoupling, the Dynamic Oracle Race

However, blockchain is not limited to DeFi alone. Through oracles, dApps can securely and efficiently access off-chain data, greatly expanding their business scope and application scenarios. This enables their business directions to extend into finance, insurance, supply chain management, IoT, and many other fields.

In today’s market, according to platform data from DeFiLlama, Chainlink still holds a dominant position, with TVL (Total Value Locked, denominated in USD, secured by critical infrastructure such as oracles) accounting for 45% of the entire market.

A careful reader will notice that the curve on the right side of the chart experienced severe volatility in May 2022. The catalyst was the infamous Luna crash event during May 7th to May 13th, 2022, where the leading algorithmic stablecoin UST suffered two decoupling incidents, ultimately spiraling into a downfall along with Luna. Simultaneously, many projects using internal oracles faced serious issues due to delayed responses to price fluctuations.

The following chart clearly shows a sharp decline in market share for internal oracles (shown in pink) in May 2022. Chronicle oracles (shown in red) effectively captured this traffic surge, essentially securing the market share lost by internal oracles.

4. The Predicament of Third-Party Oracles

Aside from industry-shaking events, it seems the development of oracles has stalled. Indeed, due to its clear industry positioning as a tool for bridging on-chain and off-chain data, oracle products tend to have relatively straightforward functionalities. One of the most criticized aspects is their profit model, which currently revolves around data subscription fees and the appreciation of tokens issued by project teams. Clearly, revenue generated from a singular data subscription model is limited. For example, taking Chainlink’s fee-generating feature for Verifiable Random Function (VRF) as an example, according to blockchain explorer Etherscan, I calculated that the total locked tokens for VRF V1 and V2 versions amounted to approximately 370,000 (7 + 30), translating to around $6 million in revenue based on the current LINK rate ($16). Since the launch of VRF V2 in late February 2022, it has generated approximately $4.8 million in revenue, averaging about $170,000 per month (11,000 LINK). Compared to Chainlink’s vast scale, these profits are indeed meager. As for token appreciation, opinions vary.

However, due to their nature as third-party entities, oracles inherently occupy a relatively neutral position and are beginning to serve as critical infrastructure in application layer security. To break free from the traditional middleware impression and enhance profitability, oracles need differentiated and systematic functional expansions. For example, LayerZero, as a typical cross-chain bridge, relies on the security carried by oracles with ultra-light node requests. In summary, the predicament of oracles in the market lies in their inherent operational limitations, single functionality, modest profitability, and yet-to-be-expanded scalability. Nonetheless, understanding the execution model of so-called third-party oracles reveals that their issues stem from their “third-party” nature. API3, positioning itself as a newcomer in the oracle sector, focuses on being a “first-party” oracle, aiming to overcome these challenges.

4.1 Comparing Third-Party and First-Party Oracles

API3 has chosen to leverage its comprehensive operational capabilities in activating API service nodes, using a more web3-native (lightweight + modular) approach to build a bridge between oracle consumers and providers. API operators can swiftly set up their own oracle nodes using API3’s Airnode solution.

As a first-party Oracle project, compared to the traditional flow where API providers connect with oracles and then to dApp operations (API providers → oracle → dApp), API3’s approach (API providers + oracle) → dApp empowers API providers to take a more central role. They no longer merely act as third-party oracle workers but gain more influence and autonomy in the ecosystem.

As depicted above, with the elimination of third-party intervention, the data chain is streamlined. When API providers and oracles merge roles, there is no longer a question of where the data originates from, as the reputation of API providers is linked directly to the data on-chain.

Due to the tightly coupled reputation of API providers with the data they supply, tracing is simplified, and technically, malicious behavior is not allowed to go unnoticed, backed by a collateral mechanism. Even if an API provider maliciously provides false data for personal gain, affected users can appeal and claim compensation. Complex disputes, such as cases of malicious user complaints for insurance fraud, would be adjudicated through an on-chain judicial system. Leveraging the fully decentralized insurance mechanism provided by API3 DAO, API3 can efficiently penalize API providers and compensate affected users to the fullest extent possible.

5. A Deep Dive into API3 DAO’s Tokenomics

API3 DAO’s tokenomics operates on a stable basis through its staking mechanism, leveraging positive and negative feedback loops.

5.1 Staking Governance Mechanism

The staking mechanism is a standard practice in DAO governance, involving profit from staking and staking governance, serving as the starting point for a circular economy. API3 has further optimized this process:

• What happens if stakers withdraw after receiving staking rewards? The inflationary rewards generated from staking (newly minted tokens) are delayed before being distributed and default to flowing back into the staking pool.
• What else can tokens in the staking pool be used for? They can be used to compensate users for losses.
• How does API3 stabilize the token price in the staking pool? API3 controls inflation through Burn and Token Locking mechanisms: Users need to burn or lock their tokens to obtain dAPI services.

5.2 Positive and Negative Feedback Loop Given this positive and negative feedback loop, what trend will the token quantity in the staking pool exhibit? Will uncontrolled expansion or insufficient funds to cover compensation lead to collapse? Let’s analyze:

• When dAPI users increase, the system’s risk escalates (operating costs rise with user numbers), leading to more compensation events. Consequently, tokens in the staking pool decrease (used for compensating affected users), causing stakers (and managers) to suffer losses due to poor management. However, reducing tokens in the staking pool also means increasing tokens flowing into the market. Given that tokens held by users are affected by inflation, a significant portion still returns to the staking pool due to users’ self-interest considerations.
• When dAPI users decrease, system risk diminishes, causing tokens in the staking pool to gradually increase, making tokens in the market scarcer. Nonetheless, this does not imply a perpetual increase in the staking pool’s token count; API3 DAO dynamically adjusts staking rewards (and inflation rates) to align them with a targeted healthy value.

The two scenarios described above form a positive and negative feedback loop, depicted well in the diagram on the left (a). When either scenario reaches a threshold, the system self-adjusts. dAPI users tend to stabilize, as shown in diagram left (b), ultimately leading the system toward a healthy operational state.

In fact, DAO-style governance tokens like these have long been popular in various DeFi protocols. For example, in the detailed implementation of decentralized stablecoins, MakerDAO’s DAI stands as a benchmark with MKR as its pioneering governance token.

Particularly elegant is its four-auction mechanism. For further reading, refer to “A Comprehensive Explanation: AAVE, the DeFi Leader, and the Latest Stablecoin Proposal GHO,” specifically the section “Undercollateralized, Four Auctions.” Therefore, DAO governance is the mainstream operational mode for economic stability, yet API3’s innovations are also noteworthy.

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

6.1 The Birth of OEV

OEV (Oracle Extractable Value) operates similarly to MEV (Miner Extractable Value). It refers to the oracle’s ability to capture value that would otherwise flow to third parties. While MEV captures value through transaction ordering, OEV exploits price discrepancies between on-chain and off-chain data, particularly in critical market data or significant on-chain events like liquidations.

Understanding how OEV arises requires awareness of current issues with oracles. Due to the cost of on-chain data submission, oracles typically use periodic data uploads set within relatively short intervals. To mitigate the impact of large price fluctuations, oracles often set thresholds triggering proactive updates when price movements exceed these limits. While these measures alleviate some issues, they don’t fundamentally solve the latency issue associated with data uploads.

DeFi markets are highly volatile, and asset prices can change significantly within short periods. The feed mechanism of oracles introduces uncertainty into DeFi markets. Exploiting this delay in data updates, profit-seeking entities can take advantage of OEV. For dApps reliant on oracles, any delay or update in data feed can potentially create opportunities for OEV, such as frontrunning, arbitrage, and liquidations.

Attributing the ownership of exploitable value arising from data feed delays can be challenging. Data uploads inherently have fluctuations, so delays cannot always be attributed to malicious intent on the part of the oracle. Therefore, the exploitable value generated from such delays may not necessarily be considered maliciously created by the oracle.

6.2 OEV Network - A Multi-party Auction Platform

Due to the existence of OEV, users, and dApps, as interacting parties, are having their value extracted by third parties, which is clearly undesirable for both. API3 identified the need to preemptively reject capturing the pricing power of all such leaks (pricing power of on-chain data), hence the OEV Network was proposed. As a Network based on Polygon zk rollup, it is an independent order flow (any participant’s intent to change blockchain state is an order) auction platform for the right to update dAPI data. API3 developed the auction platform itself, eliminating dependence on external services, allowing stakeholders to share OEV without sharing profits with the auction platform, and internalizing OEV across all integrated blockchain data feeds. The auction winner gains the right to update dAPI data, with most of the auction profits returned to the dApp and a small portion retained by API3 to cover operational costs. Clearly, when the auctioneer (third party) believes the auction cost < profit from updating prices, they will participate in the auction, making it profitable for third parties as well. While users of the dApp platform may not seem to participate in profit sharing, they benefit from the quality data source provided by dAPI for better trading and risk management, potentially benefiting from it. The auction lifecycle is illustrated in the diagram below. When a searcher discovers OEV, they initiate a bidding auction. The winning bidder gains the right to update the dAPI data of the oracle node, and after paying the bidding fee, they can exercise this right to update the oracle node’s dAPI data. The paid auction fee is the captured OEV flowing to the dApp.

The trend of auctions naturally involves third parties (searchers) increasing bidding prices in pursuit of potential profits. A higher auction price means a smaller difference between actual OEV and captured OEV. As for the size of this opportunity, we’ll have to wait and see after the test network stabilizes for some time before making judgments. The auction results create a win-win situation for dApps, API3 oracle nodes, third parties, and dApp users. dApps integrating API3 data sources minimize the wool pulled by third parties while capturing most of the OEV value. Ultimately, market competition among third parties ensures that profits are gradually compressed, benefiting dApps in the end. For API3, a small portion of OEV value supports the operational path of OEV. Third parties also get a share. For dApp users, incentivizing highly specialized third-party participants to determine optimal timing for updating on-chain data points improves granularity, benefiting dApp users in the long run. Thus, API3’s OEV auction scheme maximally addresses the distribution of interests in a multi-party game, redirecting “misplaced profits” of third parties back to relevant stakeholders. Such a solution is elegantly designed. For further reading, explore “UniswapX Research Report (Part I): Summarizing the Development Path of V1-3, Understanding the Principles of Innovation and Challenges in the Next Generation DEX.”

7. Conclusion

API3 has constructed a self-sustaining ecosystem based on its token economics, utilizing positive and negative feedback mechanisms to stabilize operations. Concurrently, the OEV Network introduced by API3 cleverly resolves the issue of OEV flow through an auction mechanism for dAPI pricing updates, deftly shifting conflicts arising from OEV between oracles and dApps onto third parties.

As decentralized applications proliferate and mature, the demand for reliable and secure oracle services is expected to grow, signaling the emergence of the next generation of oracles. However, API3 faces several challenges. Economic models, even well-designed initially, may struggle with long-term stability, often falling prey to either excessive governance or neglect. Furthermore, API auctions, which hinge on reputation and earnings, are inherently optimistic rather than pessimistic models (like ZK). Despite LayerZero’s use of a similar reputation structure and its continued operation without market issues, even in high-risk combinations like oracles plus cross-chain bridges, risks persist.

Continued reputation betting implies that participants’ market returns must be sufficiently high, and closely tied to API3’s market development. Ultimately, the oracle market’s difficulty lies in the fact that DApps prioritize not just data provision capabilities but also the positioning of the oracle itself as a third party. API3 has disrupted this paradigm, yet concerns remain when DApps themselves participate in auctions, raising questions about potential collusion despite staking their own reputation. Established players like Chainlink are also capable of releasing more OEV to maintain market dominance.

Disclaimer：

1. This article is reprinted from [十四君],. All copyrights belong to the original author [十四君]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.