Introduction: The (Oracle) problem

$403.2 million US ‘dollarinos’… that, surely, is a ridiculous amount of money. Would you like to guess why that specific number is relevant to today's article? Well, my good friends, this was the estimated amount of funds exploited across DeFi through Oracle manipulation in 2022.

What are oracle manipulations, and how do they work? Let’s start with something familiar:

Do you remember this guy?

“What are you gonna do, arrest me?”

Avi and his “highly profitable trading strategy” that drained Mango Markets of over $110m in October of 2022 was probably the most famous oracle manipulation attack in recent times, particularly in crypto.

In a nutshell, Mango Markets allowed (rightly or wrongly) their native token, MNGO, to be borrowed and used as collateral. The problem, however, was that MNGO was highly illiquid and, therefore, prone to such an attack.

Sequential representation of  AVI’s heist

A Quick TLDR: Avi used a load of USDC to drive up the perp price of MNGO (artificially). He also purchased a lot of spot MNGO, further increasing the price. This led the spot price of MNGO on a few centralized exchanges to increase 5-10x.

Switchboard and Pyth (two oracle providers for Mango Markets) then reported these artificial prices to the Mango’s borrow and lend marketplace. While the spot oracle price was reporting that MNGO was now drastically increased (in USD terms), he could borrow assets like USDC and SOL against his artificially inflated MNGO position and never repay the loan.

There are a few more moving parts, but you get the idea…

If I have jumped too far here and you are wondering… “Bro, what tf is an oracle?” Let me explain in ape-speak.

An oracle is what connects the off-chain world to the on-chain world.

Think asset/token prices, weather data, sports results… basically, any data in the real world.  An oracle makes it compatible with the blockchain in a decentralized and trust-minimized way.

Reframed: Real-world data on the blockchain.

Why is that needed? Well, blockchains like Ethereum can’t access any data sets from our humanoid existence. It is a distributed ledger and doesn’t have any way of collecting the latest Chelsea FC result (it could probably assume they got beat, as usual).

This is where an oracle or a set of oracles comes in.

They will provide data (information) about a specific event. Usually, you will collect this information from multiple sources (aggregated) to ensure an average and/or to ensure there is no funky business, i.e., manipulation going on.

Sounds great, doesn’t it? Well, it is. It enables our beloved DeFi to operate as it does today. Most on-chain DeFi protocols rely on off-chain CEXs to feed their price data to their app to enable it to function as intended. As seen with the example of young Avi above, some bad actors can sometimes financially benefit from shortcomings in a DeFi protocols infrastructure regarding Oracle manipulation. Now, this is just the start of it.

The problem with third-party oracles

Besides our nefarious buddy, Avi, oracles face other notably serious challenges that won’t just disappear — at least not by a magic wand. And given that they’re responsible for the functionality of many decentralized applications (dApps), the issues are as serious as it gets.

In the first place, most oracles as we know them are a patch solution to the problem of connecting the real world with the on-chain one through a third-party approach. They exist for the sake of failure to find a better solution to this connectivity problem and, as such, come with a truckload of setbacks.

Some of the basic problems are:

• Their centralized nature creates a single point of failure while also exposing the protocols to systemic risks

• They can be exposed to vulnerabilities such as data breaches or hacks wherein attackers can exploit data provided by triggering a malicious smart contract transaction (study Sybil attacks). You can refer to the BonqDAO hack — a case in point.

• There is a risk of malicious collusion attacks wherein other oracles are bribed to manipulate data.

• They cannot be regarded as a reliable source; they inherently lack transparency as a result of obscuring data sources

• Other problems associated with third-party oracles exist, such as they can be quite expensive to integrate.

In addition, there are few third-party oracles out there, giving room to monopolistic tendencies and pricy costs. The result is that this pushes protocols to offset oracle costs by pushing the cost over to the user through increased fees.

One more thing! We’ve also noticed that there are certain “third-party oracles" that utilize cross-chain infrastructures to parse data on-chain. The risk here is pretty obvious — they are susceptible to a contagion (false data) in situations of bridge exploits.

Based on the above sticky situations associated with third-party oracles or existing oracle solutions, a new contender exists to approach data provision through a different pov.

Doing it the API3 way

The paragraphs above highlight some of the risks and nuances associated with third-party. Nonetheless, we are not ungrateful folks! We thank them for playing their part — but how about we return to how things should have been from the jump?

In this regard, we are poised to look at a serious contender on the block – API3. API3 is a collaborative project to deliver traditional API services to smart contract platforms in a decentralized and trust-minimized way, straight from the source.

The goal of API3 is to provide developers with an easy way to access off-chain data for use within smart contracts while worrying less about the security and trust implications.

But before we get into the mechanics of how API3 intends to achieve the above, let’s break down what APIs are for ya.

Application Programming Interface (API)

At a very high level, an API can be described as an intermediary between systems and applications, facilitating an exchange of data, functionality, and other resources.

In ape speak, they can be likened to a town crier, a digital royal spokesperson conveying information and data from one system to another. APIs serve as the connection between website data sharing. They (APIs) are referred to as the digital glue — in reference to how web2 applications and systems depend on their services to function.  

For perspective, if you are a footie lover who loves to keep track of the scorelines across the board on a matchday weekend, you will likely be aware of websites that can help you keep track of live scores as they happen. These live score aggregator websites depend on APIs to aggregate the scores in real-time.

In an ideal world, blockchain applications should depend on these APIs to access direct and verifiable data, including real-time data. However, they cannot do this for several reasons:

• Most API terms of service prohibit the resale or unauthorized distribution of the API data.
• They function off-chain and require an oracle to provide data access to on-chain dAPPs, to which our third-party oracle friends have done quite a job, but not without many downsides.
• Most API providers lack the technical know-how to operate on-chain (Most don’t even care).

These few reasons and more are a stumbling block to achieving a direct data flow from off-chain to on-chain. This is where API3 comes in. The API3 solution to this challenge of API connectivity and on-chain data sharing is intricate, involving numerous dynamic components, including:

• Air Nodes (First-party oracles)
• Decentralized APIs (dAPIs)
• API3 DAO
• QRNG
• API3 Market

Don’t worry, fren; we will dissect each of them in the paragraphs below:

First-Party Oracles (Air Nodes)

When we think about the challenges that on-chain applications face in directly connecting with APIs, such as the ones mentioned above,  it's clear there's a need for something better. That's where API3 steps in with something pretty cool called Airnode. The way it works is that it lets API providers easily set up their own oracle nodes such that they become first-party oracle providers. Airnodes are responsible for allowing providers to publish data feeds to on-chain dAPPs. They (airnodes) are designed to foster communication with smart contract platforms.

Here’s the logic for this:

• If an intermediary (ie, not the owner of the API) runs or hosts an oracle node to provide data to on-chain applications, sourcing this data from APIs off-chain, they’re invariably a middleman — and as such, can be classified as a “Third-party oracle provider.”

• However, they become first-party oracle providers if API providers run or host their own oracle node (Airnode) to provide data directly to the on-chain apps.

See? Not hard at all!

Airnodes allow API providers to share their sourced data directly onto the blockchain; no middlemen needed. They are also quite easy to operate, requiring no specific know-how, in a “set and forget” manner. Airnodes are also easy to deploy; they’re cost-efficient and do not require the operator to handle any sort of crypto as a form of authentication.

With the absence of middlemen comes cost efficiency as there is no middleman tax to be paid, unlike the third-party oracles, where large fees are often a thing. Moreover, another advantage of API providers running their oracle node is that they are more secure since the data source is direct and not through a connector. We can also trust the data from a first-party oracle provider as there is a reputation to protect in the real world.

Decentralized APIs (dAPI)

Indeed, integrating first-party oracles (Airnode) within the infrastructure of the API provider is logical to eliminate reliance on third parties. However, achieving true optimization would entail the implementation of decentralized first-party oracles.

API3 recognizes that direct API provider involvement in supplying data feeds to smart contracts impedes decentralization and, as such, employs the concept of decentrally governed oracle networks to achieve API-level decentralization. What this basically entails is that API3 runs a governance system that decentralizes APIs.

In doing so, the concept of a decentralized API or decentralized APIs (dAPIs) is achieved.

dAPIs function as on-chain data feeds sourced from off-chain first-party oracles that are owned and operated by API providers themselves. These data feeds are what the on-chain applications (dAPPs) depend on for functionality. An example is a perpetual decentralized exchange (DEX) fetching external price feeds directly from the dAPI of Coingecko.

There are a few attributes that define a dAPI:

• They are not complex to interact with as they are completely abstracted from technical complexities
• They are permissionless
• They exist as "values" on smart contracts that can be updated by first-party oracles and simply read by dApps

Going by the above explanation of what dAPIs are, there is the question of how dApps can connect or find these dAPIs for integration.

Enter API3 market

The API3 market is a platform where dAPP developers can find dAPIs or data feeds specific to their development needs.

Beyond being the go-to marketplace to find dAPIs or data feeds, the API3 market will be used to subscribe and upgrade data feeds.

The new version of the API3 market will progressively make things even easier. How? Well, the norm for integrating third-party protocols heavily has various dependencies that result in a slow process. More often than not, it starts with a telegram account open for both the representatives of the Oracle provider and the protract to discuss and agree, after which it might take a while to eventually integrate the oracle with the product.

However, with the new iteration of the API3 market, there will be no need for this archaic conversation between BDMs and Devs. DApps will be able to go onto the market, pay for a data feed, and it will be live IMMEDIATELY —fully decentralized and on-demand ready to be consumed.

This is a first in the world of oracles. It's basically like buying a streaming subscription on Netflix. Projects don't even need to talk to any API3 representative as it is a self-service platform.

The API3 (Quantum randomization) QRNG

This one is a bit technical, but we will attempt to break it down for ya!

Well, if you have been in the web3 or blockchain space for quite some time, you’ll likely be familiar with the word “Randomizer '', especially when it concerns Chainlink’s VRF.

For a bit more perspective, randomizers are used to do a number of tasks on-chain, such as determining lottery results, randomizing NFT traits, selecting DAO proposals, and so much more. In more detail, we can describe randomization or quantum random number generation as a method of random number generation based on quantum phenomena.

Well, here’s the catch: random number generation is a service provided by oracles because smart contract algorithm platforms emulate a deterministic virtual machine that cannot infinitely generate random numbers. In situations where they try, there will be repeating patterns — a case that is described as pseudorandomness.

A popular solution to this issue is a decentralized PRNG such as the VRF. However, this solution is exposed to Sybil attacks. As such, API3 is offering a much better method — using first-party oracles to offer QRNG services.

The API3 is doing this under the auspices of a public utility (meaning free of charge) — providing randomization services on behalf of authorities that have invested time and resources into the quantum solution by running an airnode that’s made accessible to dApps. One such authority is the Australian National University’s airnode offering QRNG as a first-party service through the API3.

The OEV network

We did say there are many moving parts to API3, and the OEV network is one of them. If you are familiar with MEV bots and how liquidations work on lending protocols, then this should be simpler to understand. However, if you are not, don’t worry, we got you.

OEV stands for Oracle Extactable Value, and what this means is the potential value derived from oracle updates or their absence.

To break this down in ape speak, let’s look at a simplistic version of how oracles function in a lending protocol. Basically, lending protocols provide lending and borrowing services for users. For a user to borrow an asset,  they have to deposit a collateral (usually overcollateralized) asset following a specified loan-to-value (LTV) ratio. Now, if the borrower’s collateral touches the minimum collateral ratio, then they are likely to have their position liquidated.

How do oracles come in? Well, you see, oracles provide price data feeds to these lending protocols to create a tandem in price between the assets deposited in the protocol and their real-time price. Third-party protocols do this indirectly, just like we’ve mentioned above, and first-party Oracle solutions like API3 enable the direct provision of price data from the source.

However, the bone of contention lies in the value being lost when a borrower’s position is due for liquidation as updated by the oracle (whether third-party or first-party) as a result of the parties involved in the process of executing a liquidation. The flow usually goes thus: The oracle updates price data and thus reveals the health factor of certain borrow positions. A group of MEV bots, often called “searchers,” proceed to battle or compete for block space in order to execute the liquidation and earn profit from the act.

The result, however, is wild! You see, during this auction process, the competition by these bots is fierce —so fierce that they often end up giving up 99.9% of the profits to validators to process their transactions. Yup! I know what you’re thinking; what a futile venture for searchers, right? Well, in truth, it is, but it is also a more unprofitable venture for the lending protocols that end up losing so much value. For example, Aave has paid over 100 million US “dollarinos” in liquidation bonuses that just end up in the hands of validators.

However, a closer examination of the visual representation above uncovers the entity with the authority to halt this cycle of liquidation bonus losses — namely, the oracle provider themselves. The logic is if the Oracle provider is the one that starts the whole process in the first place, then they can as well redirect the flow of this value simply by replacing where the auctions happen.

It is within this framework that the OEV network exists as a ZK-rollup designed to aggregate the Oracle Extracted Value (OEV) from all decentralized applications (dApps) utilizing API3 data feeds across multiple blockchain networks. It functions as a specialized order flow auction platform, where the rights to execute particular data feed updates for specific dApps are auctioned to the highest bidder.

In simple terms, unlike the flow in the pictorial representation above, the oracle provider shares price data feeds with a searcher that wins an auction. The value (money from the winning bid) captured from the bidding process in the auction is then returned to the protocol, while the searcher keeps a percentage of the liquidation bonus as profit. With this flow, the dAPPs or protocols can recapture the leaking MEV and choose to do with it as they please.

We do think that this is a genius chess play by API3. Dapps such as lending protocols will have no option but to go the API3 solution route. It comes with the added advantage of recapturing MEV as OEV, potentially saving them(dApps) millions of dollars and providing an additional edge to earn more market share.

The API3 DAO

To fully decentralize how the entire system works, API3 delegates governance to the vote of a DAO that functions on preset principles such as Least privilege and transparency. The API3 token powers the DAO.

The diagram above paints a vivid picture of how the DAO is central to the API3 ecosystem. To gain a share of voting power, participants must stake their API3 tokens in the DAO pool. In return, Stakers earn inflationary rewards that stem from the business model charging fees from dAPPs that integrate with dAPIs.

Another important aspect of how the API3 DAO functions is through a contributor structure compromised by a hierarchical team and subDAOs. Both teams in the structure can access grants based on specific requirements that voters will decide upon.

Tokenomics and Staking

The API3 ecosystem is governed by the $API3 tokens,  the native token of the API3 project. As we mentioned earlier, the token is inflationary following a target staked amount that matches rewards paid out to Stakers.

The staked tokens are used to provide collateral for the on-chain service coverage. As such, we can identify three use cases for the API3 token:

• Staking rewards and membership
• As a form of collateral to support valid coverage claims
• And voting as an act of governance with the sim of steering the DAO in the right direction.

API3 is also focused on monetizing the business of decentralized APIs (dAPIs) and, in so doing, places a recurring subscription fee for dAPPs. When a dAPP wants to receive service coverage, they are expected to pay a premium fee.

Concluding thoughts

We believe that dAPIs are a brilliant step to bringing APIs, as web2 devs know them, to the blockchain, bringing with them the much-needed transparency and security that will massively improve the web3 ecosystem. One less problem to worry about for us all when it comes to the incessant hacks that are now a daily occurrence.

Moreover, with over 160 data feeds already integrated across 17 chains and counting, We are pretty confident that in no time, we will say goodbye to third-party oracle providers and welcome a new age of data feed reception on-chain.

The most ecstatic aspect of all of this is in the reliability and growth that can come as a result of sector-wide aggregation of data feed directly from the source, especially when we consider the new decentralized primitives that were once deterred by the inefficiencies of third-party oracle data provision.