Editor | Wu Talks about Blockchain
The following is a summary of Wu's English podcast
Please listen to the full version:
https://www.youtube.com/watch?v=6HskTaYR4vU
Can you briefly give us the background story of API3 and how the OEV Network was launched?
API3 is an oracle project that was born out of the founders’ previous experience operating ChainLink nodes and their quest to design a more efficient, straightforward and verifiable system. This led to the creation of API3. Oracles have a wide range of applications, with the most notable use case being price feeds, a key need in the decentralized finance (DeFi) space. Currently, providing price feeds does not generate a lot of revenue, as this operation is mostly subsidized by selling their own tokens to support the oracle projects that provide them or by the network investing millions of dollars into these services. This is why API3 places a lot of emphasis on identifying self-sufficient market segments that allow an oracle project to be financially viable. This approach paved the way for the launch of the OEV Network, focusing on creating a model where providing oracle services can be profitable in itself.
What is OEV (Oracle Extractable Value)? Why is it important?
Oracle Extractable Value (OEV) is a specific type of Miner Extractable Value (MEV) that focuses on the impact of Oracle updates, or lack thereof, in blockchain systems. Similar to MEV, where miners can prioritize transactions for personal gain, OEV involves strategically prioritizing Oracle transactions to extract value, particularly in scenarios where Oracles provide critical market data or trigger significant on-chain events such as liquidations.
What is the purpose of building a Zk-rollup?
Initially, the concept of moving to a rollup-based system, especially in the context of the MEV (Miner Extractable Value) slowdown and oracle updates, seemed unconventional. However, recognizing the centralized nature of existing MEV solutions like Flashbots, MEV Share, or MEV Blocker, it is clear that a shift is needed. These solutions run on central servers and require users to place a great deal of trust in their operation, which contradicts the decentralized spirit of blockchain technology.
Our early method of selling oracle updates similarly relied on centralized servers, creating a system where users not only had to trust us to perform updates, but also had to trust us to handle large amounts of funds due to the collateral requirements required to participate. This setup made considerable trust assumptions, particularly around the legitimacy of the oracle update auction process, which lacked transparency and verifiability.
Adopting rollups allows for more trustless interactions, enabling users to transfer their collateral onto the platform without giving us full control of their funds. Additionally, it provides an on-chain record of auction participation, winners, and update executions, greatly reducing trust assumptions. With rollups, the entire process becomes transparent and verifiable, reducing the need for users to overly trust the API3 or the integrity of the auction process. This approach is more aligned with the decentralized principles of blockchain, ensuring that users can participate in the system with greater confidence and security.
Why Polygon?
We chose Polygon because we have a strong partnership with them and are confident in the future development of zero-knowledge proof (ZK) technology. We made this decision based on our deep understanding of Polygon's zero-knowledge proof Ethereum virtual machine (ZK EVM) and the strong demand for oracle services in its ecosystem. Polygon's readiness to bring its ZK solution to market gives it a clear advantage over other platforms and is the main reason for us to cooperate with them.
What role will API3 tokens play in the OEV network?
In the OEV network, the winning bidder is required to pay an additional 10% fee on top of their bid, which goes directly to API3. This model is slightly different from the typical MEV scenario, where 90% of the extracted value is returned to the user and 10% goes to the MEV service provider. In the API3 case, the entire bid amount benefits the application, and the additional 10% fee is split in half, with half going to API3 as the auction host and the other half allocated to the oracle provider.
API3 uses its share of fees to perform token buybacks and burns, a strategy detailed in the whitepaper. This approach is designed to reinvest revenue directly into the API3 token ecosystem. For example, a contract has been developed that uses collected fees to buy API3 tokens, provide liquidity on Uniswap, and ultimately converts everything back to API3 for burn after one year. This approach is designed to increase the liquidity and value of the API3 token, aligning the interests of network participants with the long-term health and success of the ecosystem.
The API3 OEV network uses a first-party data source model. Why is this the case?
Both third-party and first-party oracle models involve data aggregation, but the key difference lies in the source of the data and the trust assumptions required. In a third-party oracle model, like the one primarily used by Chainlink (and some first-party oracles as well), data is obtained indirectly. For example, if I operate a node and claim to get my prices from CoinGecko, any data consumer must not only trust CoinGecko, but also me as an intermediary. This setup introduces an additional layer of trust and potential costs, as every participant in the data provision chain needs to be compensated.
In contrast, first-party oracles involve data originating directly in the oracle process. Data sources such as CoinGecko run the oracle themselves, rather than through an intermediary, allowing for a verifiable and direct supply of data. This approach significantly reduces the number of entities that consumers need to trust and reduces overall costs by removing intermediary fees. It results in a system that is more efficient, cost-effective, and quickly deployable on a variety of networks.
This efficiency is critical, especially considering that running a basic data feed, without engaging in activities like MEV extraction, is generally not profitable. Oracle projects often operate at a loss, subsidizing data feeds in the hope of future token appreciation, or seeking external subsidies to cover operating costs. By minimizing the number of parties involved, and therefore reducing operating expenses, first-party oracles offer a more attractive solution to potential partners, combining efficiency with reduced trust requirements and lower costs.
What is the game theory relationship in the Order Flow Auction (OFA)?
Essentially, when you trade through a platform like MEV Share, your trades have the potential to create value. This concept is used in order flow auctions where people can bid on the value generated by your trades. MEV Seekers can then compensate you with a large portion of the value extracted from packaging and selling your trade flow. For example, a large sell order may trigger a profitable liquidation, making your trades very valuable to bidders who are able to take advantage of these opportunities, resulting in a significant cashback for you.
In the context of the OEV Network, the focus shifts to oracle updates rather than typical transactions. We participate in order flow auctions specifically for these updates. Bidders can compete for the opportunity to initiate an oracle update, with the proceeds supporting the application or protocol involved. For example, a minor price change triggering a significant liquidation could represent a significant profit opportunity, prompting competitive bids for the right to execute that oracle update.
This system mirrors the dynamics seen in traditional order flow auctions on Ethereum mainnet, where liquidations and oracle updates can generate significant value. However, our approach is designed to ensure that the benefits are more evenly distributed. By allowing the market to determine the value of oracle updates, we create an environment where applications can recapture a larger portion of the incentives that would normally be used to pay for liquidations, thereby significantly reducing costs.
In summary, oracle updates can unlock significant value, making it critical to let the market determine their value. Currently, oracle updates occur without this market-driven approach, often resulting in missed opportunities to recapture value. Our system aims to change this, potentially allowing DApps to retain a larger share of the incentives they provide.
What if the rewards for misconduct are greater than the service fees and fines?
We focus on first-party oracles because they are backed by real business activity, making them accountable for their data. If these oracles misbehave, their actions are recorded on the blockchain, allowing for direct recourse. API3 manages and monitors these data providers to ensure quality standards are met. Providers that fail to meet these standards are replaced, ensuring the integrity of the data provided. This approach relies on trust in these providers, but aims to minimize it through transparency and accountability. The goal is to move to a system that relies less on trust in the future.
How does API3 compete with Chainlink and Pyth? What is the ultimate goal?
We don’t focus primarily on Total Value Locked (TVS) as our core metric because TVS does not directly contribute to profitability. The reason is that operational data provision, regardless of the size of the TVS, is not currently a profitable venture — there is no direct mechanism to inject the value recovered from operational data provision into tokens. Whether you are protecting $5 billion or $500 million, the financial result remains the same: there is no profit from the activity itself. This realization has led us to focus on the OEV Network, which provides a way to bring funds back to the project and actually generate revenue.
The OEV Network transforms TVS into meaningful numbers by tying security work directly to potential revenue through clearing and other mechanisms, moving away from models built on “hopes and dreams.” Currently, the OEV Network operates in conjunction with API3’s data feed, enabling additional updates and revenue streams. We are exploring expanding the OEV Network to other oracles, potentially allowing us to move away from the unprofitable aspects of operating a data feed and focus on profitable OEV operations.
On many second-layer platforms, the underlying foundation subsidizes the provision, meaning the actual costs are often borne by Chainlink Labs or the governing body of the second layer rather than the projects using the provision. For the most part, important and commonly used data provision does not directly generate profit for oracle projects. The shift to the OEV Network represents an innovative approach to value creation in the oracle space, focusing on profitable interactions rather than just securing large amounts of TVS without direct financial reward.
It’s not entirely accurate to say that oracle services like Chainlink don’t make money. They potentially generate revenue by passing costs onto the networks they operate, such as Arbitrum, where the Arbitrum Foundation covers these costs. The relationship between the amount of oracle usage provided by a project and the revenue generated is not direct; typically, these services are designed to cover operating costs rather than make a large profit.
Expanding into new areas like CCIP suggests a strategy to create value beyond a pure price offering, which might be seen as a brand-building tool or a break-even operation rather than a profit center. Governance discussions within these projects often reveal the financial challenges of operating oracle services, highlighting the move toward potentially more profitable solutions.
How is API3 different from Oval? What are its advantages over UMA?
Oval is built on an infrastructure of oracles and Flashbots, demonstrating a way to capture value from oracle updates by pre-selling update rights. However, it relies on centralized components and due to the limitations of Flashbots, its scope of operation is limited to the Ethereum mainnet, showing a system with significant dependencies.
API3 proposes a more flexible model that provides a comprehensive solution beyond what Oval has achieved. It provides options for using API3's own data feed to obtain fine-grained updates or to enhance other oracles with additional granularity through the OEV network. This approach reduces reliance on a single network or solution and aims to achieve broader applicability across blockchains without the limitations imposed by service dependencies like Flashbots.
Essentially, API3’s strategy involves building on existing oracle frameworks, providing enhanced granularity, and expanding the potential for value capture across multiple blockchains. This multifaceted approach aims to address the complexity of oracle services and solve the limitations of current models while exploring avenues for greater efficiency and broader network applicability.
Compared with UMA, API3's advantage lies in its emphasis on building decentralized first-party data provision and reducing dependence on centralized and third-party services. API3's OEV network and data provision strategy provide a more decentralized, transparent and verifiable data flow, which is essential to ensure the fairness and security of blockchain applications. In addition, API3 aims to provide a cross-chain compatible solution that allows for wider applicability and flexibility, while UMA focuses on providing building blocks for decentralized financial contracts, which may differ in scope of applicability and technical implementation.
