Recently, API 3 has recently received 4 million US dollars in strategic financing, led by DWF Labs and followed by several well-known VCs. For a long time, the oracle (Oracle) track has basically been dominated by third-party oracles represented by Chainlink. I was also surprised when I saw this news~Why was API 3 able to obtain financing? Will it be a game-changer for 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's 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 for on-chain smart contracts, but what is real? How to ensure the integrity of the oracle itself? Will the oracle do evil? Will 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, compared to $103 billion in Q4 2023, an increase of nearly 70%, and the oracle has always been called the core blood 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 relatively low cost to modify the oracle quotes and then made huge profits by performing mortgage lending, causing the project to suffer a loss of approximately $88 million. Attacks caused by oracle quote problems are not uncommon, which shows that transparent and reliable off-chain data is the basic guarantee for supporting the operation of dApps.
2. How does the oracle connect the off-chain and on-chain?
The working modes of the oracle generally include 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: On-chain and off-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 the EVM blockchain, 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 common 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, dApp can obtain off-chain data securely and efficiently, thereby greatly expanding its business scope and application scenarios, allowing its business direction to extend to finance, insurance, supply chain management, the Internet of Things and more fields.
Today's market allows us to use the platform defillama data 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 has experienced violent fluctuations in May 2022. The trigger was the famous LUNA crash in 2022. From May 7, 2022 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 for connecting 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 in 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 income. 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, which is about 370,000 (7+30) in total. Calculated at the current LINK exchange rate ($16), the total income is about 6 million US dollars. Since the launch of VRF V2 at the end of February 2022, the total income of 4.8 million US dollars has been achieved, averaging about 170,000 US dollars (1.1W 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. API 3, as a new oracle, 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, the transformation of API 3 (API supplier + oracle) → Dapp allows API suppliers to be in charge. They are no longer just third-party oracle workers and have more say.
As shown above, without the intervention of a third party, the data link is reduced. When the role of API provider and oracle is 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, traceability is simple, and they are technically not 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 API3 DAO’s token economic model
API3 DAO’s staking mechanism enables API3’s token economic model to operate stably through positive and negative feedback.
5.1 Pledge Governance Mechanism
The pledge mechanism is a routine operation of DAO governance. Staking for profit and pledge 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 price of staking pool coins? 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? Let's analyze it:
When 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 AAVE's 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 innovation of API 3 is 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 use of an oracle’s position to extract value that would otherwise go to a third party. While MEV captures value through transaction ordering, OEV extracts value by exploiting 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 the huge price fluctuations in the short term affecting the market, the oracle generally sets a threshold, and 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 price feeding function of the oracle to the DeFi market cannot be underestimated.
In this case, third-party profit-seekers are like having a God's 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 generated 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 OEV 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 participant's 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 rights of dAPI and update the price data. Most of the auction profits will be returned to dApp, and a very small part will be returned to API 3 to cover operating costs. Obviously, when the auctioneer (third party) believes that the cost of the auction is
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 user. 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 "wrong profit" of the third party has been fed back to the relevant stakeholders. Such a solution is really elegant.
Further reading: "UniswapX Research Report (Part 1): Summarizing the V1-3 development chain, interpreting the principles, innovations and challenges of the next generation of DEX" to understand the auction mechanism of UniswapX.
7. Summary
API 3 has built a self-driven 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 solves the problem of OEV flow by introducing an auction mechanism for dAPI pricing update rights, and cleverly transfers the conflict between the oracle and dApp caused by OEV to a third party.
As decentralized applications become more popular and develop, 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, 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, which is essentially an optimistic model rather than a pessimistic model (ZK). Although LayerZero, which also adopts this reputation structure, has been operating continuously, even the high-risk combination of oracle + cross-chain bridge has never had any market problems, which can prove its security, but there is still the possibility of risk. 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 Dapp itself can also participate in the auction, 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.
