In-depth interpretation of API3, unleashing the oracle trailblazer of OVM

Author: Shijiu Jun

Recently, API3 has secured $4 million in strategic financing, led by DWF Labs, with several well-known VCs participating.

For a long time, the oracle space has been dominated by Chainlink, representing a one-sided situation for third-party oracles. When Shijiu saw this news, he was also surprised~ Why was API3 able to secure financing? Could it be a disruptor of traditional oracles? What makes it unique?

As a decentralized API (dAPI) project, API3 is defined as a "first-party" oracle, solving the common issues of trust in intermediaries, low data transparency, and the control of OEV (oracle extractable value) through the innovative OEV Network (based on ZK-Rollup).

1. Can Oracles Really Predict the Future?

The term "oracle" carries a certain mythical connotation, which can easily mislead the public. In reality, it refers to tools that provide off-chain real data for on-chain smart contracts, but what constitutes "real"?

How can we ensure the integrity of the oracle itself? Can oracles act maliciously? Can multiple oracles collude? How should we understand OVM (oracle extractable value)?

In Q1 2024, after a recent surge in BTC, the total value of locked tokens in DeFi projects also reached a new high of $175 billion, a nearly 70% increase compared to $103 billion in Q4 2023, and oracles have always been referred to as the core lifeblood of DeFi.

In the DeFi space, decentralized exchanges (DEXs), lending platforms, and derivatives trading platforms all rely on accurate price data to operate. In early 2023, the TellorFlex oracle contract used by the decentralized lending protocol BONQ on the Polygon chain was manipulated, allowing attackers to modify oracle quotes at a low cost and obtain huge profits through collateralized lending, resulting in approximately $88 million in losses for the project. Attacks arising from oracle quote issues have become commonplace, highlighting that transparent and reliable off-chain data is a fundamental guarantee for the operation of dApps.

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

Oracles generally operate in three modes: scheduled uploads, event-driven, and request-response. Taking the request-response process 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), triggering an on-chain event from the oracle server contract.

• STEP 2: Off-chain, the oracle nodes listen for the event to obtain information and acquire accurate off-chain data 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-chain, the oracle server contract returns the data to the caller (dApp), with options for active push or secondary queries by the dApp.

To further elaborate on this process:

First, the on-chain demand is public, as events are a universal mechanism of EVM-based blockchains, meaning the entire network can see that the dApp currently needs certain information.

Second, off-chain pushes are non-atomic; on-chain transactions are completed in real-time, while off-chain data inevitably has some latency.

Finally, if the on-chain demand is customized, it can allow the oracle to become a neutral third party, pushing data to the dApp. However, for most general market data, such as the real-time price of BTC, the dApp will retrieve the contract again. Of course, the oracle itself also has a scheduled reporting mechanism, and these basic methods are quite similar.

3. Luna Decoupling: The Turbulent Oracle Space

However, blockchain is not limited to DeFi. Through oracles, dApps can safely and efficiently access off-chain data, significantly expanding their business scope and application scenarios, extending their business directions into finance, insurance, supply chain management, the Internet of Things, and more.

Current market data from platforms like Defillama shows that Chainlink still holds a leading position, with TVS (the total value of assets deposited in the market secured by key infrastructure like oracles) reaching 45% of the entire market.

Careful readers will notice that the curve on the right side of the chart experienced severe fluctuations in May 2022, triggered by the infamous LUNA crash. From May 7 to May 13, 2022, the algorithmic stablecoin leader UST experienced two decouplings, ultimately falling into a death spiral, leading to the collapse of both LUNA and UST. Meanwhile, many projects using internal oracles faced severe issues due to delayed responses to price fluctuations.

The chart below clearly shows that the market share of internal oracles (the pink line) experienced a cliff-like drop in May 2022, while the Chronicle oracle (the red line) effectively captured this wave of traffic, essentially taking over the market lost by internal oracles.

4. The Predicament of Third-Party Oracles

Aside from industry-shaking events, it seems that the development of oracles has hit a snag. Indeed, due to the clear industry positioning as a tool for bridging on-chain and off-chain data, the product functionality remains relatively singular.

The most criticized aspect is its profit model, which currently focuses on data subscription fees and hopes for token appreciation from project issuers. Clearly, the revenue generated from a single data subscription model is limited. For example, taking Chainlink's VRF (Verifiable Random Function) charging feature, according to the blockchain explorer Etherscan, I have counted approximately 370,000 locked tokens (7+30) for both VRF V1 and V2 contracts. Based on the current LINK exchange rate ($16), this totals about $6 million in revenue. Since its launch at the end of February 2022, the VRF V2 version has generated a total of $4.8 million in revenue, averaging about $170,000 ($11,000 LINK) per month. Compared to Chainlink's large scale, these profits are indeed a drop in the bucket, and the expectation of token appreciation is subjective.

However, due to the third-party nature of oracles, they are in a relatively neutral position, beginning to apply cost-based security infrastructure trends. If they can break the traditional middleware impression and conduct differentiated, systematic functional expansions, they can enhance profit margins. For example, LayerZero, as a typical cross-chain bridge, relies on the ultra-light node request headers carried by oracles for security.

In summary, the predicament of oracles manifests in the market as a natural disadvantage formed by operational models, with singular functionality, meager profits, and undeveloped scalability.

However, when we expand on the execution model of so-called third-party oracles, we find that their issues stem from the "third-party" factor.

API3, as a new oracle player, is core positioned as a "first-party" oracle.

4.1 Comparing Third-Party and First-Party Oracles

API3 chooses to activate the comprehensive operational service capabilities of API service nodes as an entry point, building a bridge between demand and supply for oracles in a more web3 native (lightweight + modular) manner. API operators can quickly set up their own oracle nodes based on the Airnode solution provided by API3.

As a first-party oracle project, compared to the traditional third-party oracle business flow of API providers → oracle → dApp, the transformation to (API provider + oracle) → dApp allows API providers to take charge, no longer merely acting as third-party oracle workers, thus gaining more say.

As shown in the figure above, without the intervention of third parties, the data link is reduced. When the roles of API providers and oracles merge, there will be no question of where the data comes from, as the reputation of the API provider is brought onto the chain with the data.

Due to the strong binding strategy between the reputation of API providers and the data they provide, tracing is simple, and technically, they cannot act maliciously (without being discovered), while there is a margin mechanism as a safety net. Even if an API provider provides false data for personal gain, affected users can still appeal for compensation. For complicated cases (such as malicious user complaints), they will enter the on-chain court system for arbitration. With the insurance mechanism provided by the fully decentralized API3 DAO, API3 can maximize the punishment of API providers and provide compensation to affected users.

5. In-Depth Look at API3 DAO's Token Economic Model

API3 DAO stabilizes the token economic model of API3 through its staking mechanism, enabling it to operate through positive and negative feedback loops.

5.1 Staking Governance Mechanism

The staking mechanism is a routine operation in DAO governance, where staking yields profits and governance is the starting point of a circular economy. API3 has also optimized this:

• What if a staker runs away after earning staking rewards? The inflationary rewards (newly minted tokens) generated from user staking will be delayed in distribution and will default to flow into the staking pool.

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

• How to stabilize the token price in the staking pool? API3 controls inflation through a burn and token locking mechanism: the condition for obtaining dAPI services is that users need to burn or lock their tokens.

5.2 Positive and Negative Feedback Loops

So, what trend will the number of tokens in the staking pool exhibit? Will there be chaotic expansion or a collapse due to insufficient compensation? Let's analyze:

• When the number of dAPI users increases, system risk will rise (system operating costs increase with user numbers), leading to more events requiring compensation. At this time, the tokens in the staking pool will decrease (used to compensate affected users), and 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 interests, a significant portion of the tokens will still flow into the staking pool.

• When the number of dAPI users decreases, system risk diminishes, and the tokens in the staking pool will gradually increase, making the number of tokens flowing into the market scarce. But this does not mean that the number of tokens in the staking pool will keep increasing; API3 DAO will dynamically control staking rewards (and inflation rates) to fit a target healthy value.

The above two scenarios can effectively form the positive and negative loops shown in the left part of the diagram. When either scenario reaches a threshold, the system will self-regulate, and dAPI users will stabilize as shown in the left part of the diagram, ultimately leading the system to a healthy operational state.

In fact, such DAO-style governance tokens have already been popularized in various DeFi governance models. For example, the decentralized stablecoin benchmark MakerDAO's DAI has MKR as a precursor:

Notably, its four auction mechanisms: For further reading: 《A Comprehensive Explanation of AAVE's Latest Stablecoin GHO Proposal》

In the "Insolvency, Four Auctions" section.

Thus, DAO-style governance is the mainstream operational model for economic stability, but API3's innovation does not stop there.

6. Unique Advantage - The Innovative OEV Network (Based on ZK-Rollup)

6.1 The Birth of OEV

Similar to MEV (Miner Extractable Value), OEV (Oracle Extractable Value) refers to oracles leveraging their position to capture value that would otherwise flow to third parties. MEV captures value through transaction ordering, while OEV extracts value by utilizing price differences between on-chain and off-chain, such as in scenarios involving key market data or triggering significant on-chain events (like liquidations).

To understand how OEV is generated, one must first recognize the current issues with oracles: due to the costs of uploading data on-chain, most oracles currently adopt a scheduled data upload mechanism, with time intervals set within a relatively small range. Additionally, to avoid significant price fluctuations affecting the market in the short term, oracles typically set a threshold; when the price fluctuation range reaches this threshold within a short time, they will actively trigger an update.

Although this remedial measure can alleviate some issues, the problem of data upload latency cannot be fundamentally resolved. The DeFi market is usually highly volatile, and asset prices can change dramatically in a short time, making the uncertainty brought by the oracle's pricing function to the DeFi market non-negligible.

In such cases, third-party profit-seekers have a god-like perspective, capturing huge profits by exploiting the latency in data updates, thus creating OEV.

For dApps that rely on oracles, any update or absence of data feeds can create opportunities for OEV, such as front-running, arbitrage, and liquidation. The attribution of the exploitable value generated by data feed delays is difficult to assess; since data on-chain is inherently volatile, if there is a slight delay in data uploading, it cannot be pinpointed to the oracle's fault, meaning that the exploitable value generated by this delay cannot be deemed maliciously created by the oracle.

6.2 OEV Network - A Stage for Multi-Party Game Theory Auctions

Due to the existence of OEV, users and dApps, as the interacting parties, are being exploited by third parties, which is clearly an undesirable situation for both. API3 discovered that oracles have the right to prioritize rejecting the capture of all such leaked value (the pricing power of on-chain data), leading to the proposal of the OEV Network.

As a network based on Polygon zk rollup, it is a separate order flow (any participant's intent to change the blockchain state is an order) auction platform, auctioning the rights to update dAPI data.

API3 has developed its own auction platform, eliminating reliance on external services, allowing stakeholders to share OEV without needing to share profits with the auction platform, thus internalizing OEV across all integrated data feed blockchains.

Successful auction participants can obtain the rights to update dAPI data, and the profits from the auction will largely be returned to the dApp, with a small portion going to API3 to cover operational costs. Clearly, when auction participants (third parties) believe that the auction cost < the profit brought by updating the price, they will proceed with the auction, thus allowing third parties to profit as well. As for users of the dApp platform, they may seem not to participate in profit distribution, but in reality, they benefit from the high-quality data sources provided by dAPI, enabling better trading and risk management, leading to potential gains.

The auction lifecycle is illustrated in the diagram below. When seekers discover OEV, they will initiate bidding. After winning the bid, the seeker will gain the right to update the oracle node's dAPI data, and only after paying the bidding fee can they 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 the auction is naturally that third parties (seekers) will further raise the bidding price for potential profits. The higher the auction price, the smaller the gap between the actual OEV and the captured OEV.

As for how big this pie is, we can wait and see, and judge after the testnet runs stably for a while.

The results of the auction present a win-win situation for the four roles: dApp, API3 oracle node, third party, and dApp users. dApps accessing API3 data sources minimize the profits taken by third parties while capturing most of the OEV value, as the ultimate form of market competition will be between third parties, leading to a gradual compression of third-party profits, with dApps as the ultimate beneficiaries. For API3, a small portion of OEV value can be used to maintain the operation of the OEV commercial path. For third parties, they can also share in the profits. 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.

Thus, based on API3's OEV auction solution, the multi-party game theory of interest distribution issues is maximally resolved, returning the original "erroneous profits" of third parties to the relevant stakeholders. This solution is indeed elegant.

For further reading: 《UniswapX Research Report (Part 1): Summarizing the Development Path of V1-3, Interpreting the Principle Innovations and Challenges of the Next Generation DEX》 to learn about UniswapX's auction mechanism.

7. Conclusion

API3 has built a self-driven ecosystem based on its token economics, stabilizing system operations through positive and negative feedback adjustments.

At the same time, API3's proposed OEV Network cleverly addresses the flow issue of OEV by introducing an auction mechanism for dAPI pricing update rights, skillfully shifting the contradictions arising from OEV between oracles and dApps onto third parties.

With the proliferation 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 oracles seems to have emerged.

However, API3 also faces some challenges.

The economic model is not something that can be defined and designed at the outset for long-term stable operation; the subsequent continuous process often falls into excessive governance or governance neglect.

Moreover, the core of API auctions lies in the measurement of reputation and revenue, essentially an optimistic model rather than a pessimistic one (ZK). Although LayerZero, which adopts the same reputation structure, has not encountered any market issues since its continuous operation, even with the high-risk combination of oracles and cross-chain bridges, risks still exist. Continuous betting on reputation means that participants' market returns must be sufficiently high, which is closely related to API3's market development.

Finally, the oracle market is not easy to compete in, as various dApps prioritize not only the ability to provide data but also the positioning of the oracle as a third party. While API3 has broken through this point, dApps can also participate in auctions, inevitably raising concerns among users about potential collusion, although this also means betting on their own dApp's reputation. Furthermore, established players like Chainlink are not incapable of following suit; they can also release more OEV to maintain market control.