Monetizing Data Feeds

To claim that the blockchain industry has evolved over the past several years is an understatement. The difference between what was being built five years ago compared to the complex solutions and ecosystems that are seemingly coming out of nowhere nowadays is mind-boggling. It’s without a doubt that the “rise of oracles” tremendously contributed to this innovation. One could even argue that without oracles none of this would have been possible. DeFi as we know it wouldn’t exist without price feeds. NFTs and GameFi make heavy use of randomness from oracle solutions. Other use cases like parametric insurance require oracles to get data for off-chain events like flight cancellations. Oracles are being used to build prediction markets around sports or political events.

Various kinds of oracles (e.g. subjective vs objective) can be used to make these things possible. The focus of this article is on objective oracles, which get the data they need to transmit from one unique source or multiple fungible sources programmatically. This is often achieved by calling an API — for example, of a crypto exchange to receive price information for a certain asset. However, getting the required data is only one part of the solution. The method of delivery to the customers also plays a crucial role.

Data is nothing more than a good that is being delivered by oracles to the chain in order to be consumed, which means that concepts that are used in the “real”/off-chain world can similarly be applied to these goods, i.e., we can deliver data Just-In-Time (JIT) or Just-In-Case (JIC). But what does that mean?

Naturally, JIT describes the delivery of data just when it is needed. A good example for this is API3 QRNG or Chainlink VRF, where a user actively requests data (in the form of randomness) and the request is written on-chain just in that moment. In essence, nearly all Request–Response use cases can be seen as JIT data delivery, as the goods (data) are only being delivered (brought on-chain) when they are needed for consumption.

Compared to JIT, JIC can be seen as the maintenance of an inventory ready for consumption. In the context of blockchains, this means that the required data is automatically and periodically refreshed on-chain. The moment it’s needed, it can be consumed without actively asking for delivery first. Price Feeds are a prime example of this, where asset prices are being maintained near-real-time on the chain based on parameters like deviation or heartbeat, ready to be used at any moment.

With ChainAPI, the API3 ecosystem already has a team actively working on making it possible to subscribe to Airnodes directly, monetize their usage and allow developers to make use of Request–Response or Pub–Sub protocols. Most, if not all, JIT data needs will be covered by them. Hence, this article will focus on JIC data needs, which are live data feeds most commonly used in the form of price feeds in DeFi and how API3’s dAPIs will cater to them.

Gatekeeping data does not work.

When it comes to making data available on-chain, one of the first steps oracle projects have to think about is how they and stakeholders will benefit from this. A common solution to this is to gate-keep data feeds through the use of access control, which practically means only allowing whitelisted accounts to access data. Potential customers are given such rights after paying for it or going into other arrangements with oracle projects.

However, there is a fundamental issue with such constructs on blockchains. While API3 could, in theory, also implement access control on deployed contracts (DapiServer), it remains practically impossible to enforce the same procedures on potential user contracts. For instance, many DeFi projects read data feeds through proxy contracts, which in turn can expose and redistribute data that API3 seeks to ensure is monetized on a true per-user basis. In addition to managing a potential whitelist on the DapiServer contract, API3 would need to police users to make sure that they do not expose said data. This approach is not scalable when considering the possibility of hundreds of dAPIs over dozens of chains. One “leaky” user contract is sufficient to destroy the entire value proposition access control is trying to establish. For this reason, all dAPIs will be free to use.

“How do you make money if it’s free?”

Instead of capturing value through forcing every potential dAPI user to pay for access, API3 will concentrate on monetizing dAPI decentralisation. Consequently, each dAPI will begin as a single-sourced data feed. These initial dAPIs will follow a Bring-Your-Own-Gas (BYOG) model that is quite similar to the approach taken for API3 QRNG. QRNG makes Randomness available on several chains for free to everyone, only requiring to pay for gas. With BYOG, there won’t be any upfront costs or management requirements to spin up dAPIs, which allows for the creation of hundreds of them across dozens of chains. This approach will provide users with oracle infrastructure that simply needs funding to operate, akin to a payphone. While funds are available, they will be updated and maintained according to their update parameters (e.g. 1% deviation & 24h heartbeat) for however long they remain funded. Each dAPI will come with its own sponsor wallet, which will allow users to specifically fund what they want (e.g. ETH/USD on Arbitrum).

The API3 Market is going to play a crucial role in this. It’s already the place that lists all available dAPIs, but for BYOG specifically, it is going to be extended to allow users to easily interact with these dAPIs. Visiting the specific view of a BYOG dAPI will allow users to see the latest on-chain value and update time, remaining funds in the respective sponsor wallet, as well as the update parameters like deviation and heartbeat. Additionally, users will be able to fund the sponsor wallet directly through the use of a web3 wallet like Metamask.

In cases where a single source is deemed insufficient or the overhead of keeping a wallet topped up for oracle services is undesirable, dAPIs can be upgraded. Such upgrades will be initiated through the API3 Market, where users select the amount of underlying sources they desire their dAPI to have, after which they pay for the service through a web3 wallet directly on the API3 Market. API3 will spin up the desired data feed and point the dAPI mapping towards it. Compared to single sourced (BYOG) dAPIs, API3 and the underlying API providers will also take over the gas management overhead from this point onward until the time that the service expires. Since dAPIs are free to read, paying for the upgrade of one means that every user is benefitting, which effectively turns the paying user into a sponsor. In addition to the security increase for which this sponsor is paying, they will receive additional security guarantees in the form of service coverage as well as having certainty about data feed decentralisation independently from other potential sponsors.

Quantifiable security — when ‘trust me’ doesn’t cut it.

Covering users of API3 products against certain malfunctions is one of the core principles that was introduced in the whitepaper, so it goes without saying that it’s an integral feature of dAPIs. Sponsors of dAPIs will not only get their desired amount of sources for their dAPI, but they will also benefit through being covered against certain malfunction of such dAPIs, including technical issues with the oracle infrastructure, governance mistakes (e.g. transmuting Silver to Gold) as well as issues on the API provider side (e.g. malicious actors or API malfunctions). DAPIs can also be sponsored by multiple users, which might happen if a user also wants to benefit from coverage or wants to independently make sure that a dAPI uses a certain number of data sources without relying on another sponsor.

Sponsors of dAPIs will receive service coverage policies for their respective sponsorship. These are tied to an address (preferably a multi-sig) that will have the rights to initiate potential claims in the event that damages occur due to dAPI malfunctions. An overview of active policies as well as the means to initiate claims will be available through the API3 DAO Dashboard.

Claims can only be initiated through a specific policy, which means that users without policies cannot create claims. In the event that damages occur, sponsors will need to create a claim on this dashboard in accordance with the terms and conditions of their policy. Through this process, the burden of proof lies with the claimant and evidence of damages occurred as a result of a dAPI malfunction need to be presented.

Initially, incoming claims are handled by an API3 Mediator Team that can either accept the claim in full, reject the claim entirely or make a counter offer. If a claim or counter offer is accepted it will be paid out in API3 tokens respective of the incurred damage in USD value. If a sponsor is unsatisfied with the decision that was taken by the API3 Mediators, they can escalate the claim to Kleros. Kleros will have the ability to cause API3 tokens to be transferred directly from the API3 Staking pool to satisfy claims if they adjudicate accordingly, which means claimants will have a way to receive satisfaction of their claim in the event that API3 Mediators act maliciously and they’re able to convince Kleros jurors of the validity of their claim.

Where it all comes together.

At the centre of the dAPI user experience will be the already mentioned API3 Market. It will be the primary tool to display available dAPIs, allow users to request new dAPIs, sponsor existing dAPIs as well as allow users to fund BYOG dAPIs directly.

The display of available dAPIs is a functionality that exists today and besides iterative enhancements, the feature is considered complete. Similarly, it is already possible to request new dAPIs, which leaves two points that the market needs to be able to handle in the future:

1. Allowing the sponsoring of specific dAPIs and paying for them through a web3 wallet, e.g., Metamask. Upon successful payment, the service coverage policy for the respective dAPI needs to be created and displayed. Payments will only be possible in USDC on Ethereum Mainnet.
2. Allowing the funding of a BYOG dAPI wallet. This is an extension which allows users to specify an amount of native network tokens and initiate a transfer on the respective network to the specific sponsor wallet.

“Ok, but how do you make sure to get users?”

Incentivization for using oracle services is another important topic that needs to be addressed. There are several ways of how this can be approached, but the most effective method that will benefit the oracle project, including the underlying API providers, is to incentivize the demand side. Incentivized dApps will lead to more usage, which automatically leads to more revenue for the oracle project and the underlying API providers.

There are numerous ways of how users can be incentivized and the most commonly adopted one throughout the blockchain space is to simply throw tokens at the problem. The main issue with this is that these funds come from somewhere (in this case the API3 Treasury) and are finite. As a lot of examples throughout the web3 space have shown, the majority of beneficiaries of incentives are not loyal beyond reason to the incentivizing entity. For instance, historically, liquidity moved where token incentives were and evaporated the moment they stopped. This means that this form of incentivization will most likely not create any meaningful stickiness for API3 and tokens used for such measures can be considered wasted. Such incentives additionally also create downward market pressure, since receiving parties sell their yields on the open market. The alternative?

Incentivizing usage through funds that come from elsewhere, and in the best case, are infinitely available. Sounds too good to be true? Who would logically pay dApps for using API3 services, if not API3? The answer to this might be perplexing, but it’s the dApps themselves.

Oracle Extractable Value

Some might be familiar with the term MEV (for Maximal Extractable Value), where the more strategic third parties (“MEV Searchers”) extract value from blockchain users through transaction ordering. In fact, most might have already experienced MEV in the form of sandwich attacks on decentralised exchanges, where orders are placed by searchers just before and after a transaction to extract value from users. Oracles are in a unique position to also extract value, as a subset of MEV is related to the way oracles are currently designed, and can hence be termed “Oracle Extractable Value” (OEV). For applications that rely on oracles, any update to a data feed, or the lack thereof, can create opportunities for OEV such as arbitrage or liquidations to occur (read the litepaper here).

API3 is going to enable third-parties (MEV searchers) to update dApp specific dAPIs in a tamper-proof way, which will allow them to directly benefit from the resulting state change (e.g. allowing for a liquidation). This process will be made possible through the OEV Relay, which will host auctions for the rights to such updates. The proceeds of these auctions will be paid directly to the opportunity creating entity, meaning the dApps. It is important to note that today, searchers are already able to extract all MEV for themselves, which is directly coming from users of dApps and is mostly toxic in nature. OEV auctions allow dApps with ‘leaky’ pockets to take ownership of their MEV opportunities and to redirect funds back to themselves. Fundamentally this means that dApps making use of API3 dAPIs will go from paying for oracle services to ‘getting paid’ for using them, creating another income stream for themselves in the process. What they do with these funds is up to their imagination.

An additional benefit of taking OEV auctions off-chain is that the MEV searchers will compete less with each other on-chain. Since a lot of their activity typically occurs during highly volatile times, gas costs on the respective chain should significantly decrease since these ‘bidding wars’ for MEV occur off-chain now. Chains should be highly incentivized to support these auctions as they will lead to increased UX for their users when it matters most.

Managing Funds

The operation of dAPIs brings gas token and other management responsibilities with it. For one, this structure requires sufficient native tokens for the networks on which dAPIs will be operated. Additionally, payments will be received in USDC on Ethereum Mainnet both for dAPI services from sponsors as well as for OEV services from MEV searchers. API3 will enable these to be redirected to underlying API providers. Similarly, profits in USDC from sponsorships of dAPIs will be split between underlying API providers and the API3 DAO, with the latter portion redirected to the trustless and decentralised acquisition and burning of API3 tokens as described in the whitepaper.

Operating dAPIs

The gas management overhead for sponsored dAPIs is handled by API3. For this purpose, native tokens on each chain that dAPIs are available on are required. As API3 is mainly going to deal with USDC, the recently laid out plans of multichain USDC by Circle will be making it easy for required funds to be bridged to the respective chain directly through them before converting them to the needed native currency. On chains where this is not possible, other opportunities for bridging funds will be explored on a chain-by-chain basis. Overall, API3 will operate multi-sigs on each of these chains which will hold the native currencies that will be distributed to the required wallets for dAPIs.

Profits and API Provider obligations

The profitability of a dAPI is determined through Revenue — (Operating cost * Buffer). Upon generation of profits API providers are owed their share of these. The distribution of these will occur in the same currency and network they are generated on, hence USDC on Ethereum Mainnet. If providers require fiat payments, they will be urged to create an account with Circle that will allow them to convert and withdraw their USDC payment. The additional benefit of this approach is that API3 does not need to store sensitive information of providers, nor act as a fiat payment intermediary.

Buyback and Burn

After apportionment of API provider revenues and gas costs, API3 is left with its share of profits in USDC. In essence, the whitepaper already outlines what should be done with the funds — buy and burn API3 tokens. However, there are certain problems with how this should be achieved. There is the obvious solution, where a decentralised exchange (or DEX aggregator) is programmatically used to acquire API3 tokens. Currently, this approach is less than ideal, considering the liquidity conditions for the API3 token. Attempting to swap 100,000 USDC of profits into API3 tokens in order to burn them would result in losing over 43% of these funds to slippage, which is an unacceptable outcome.

Alternatively, third-parties such as market makers could be involved in order to accomplish said conversion. Entities such as Wintermute can acquire API3 for more competitive rates as they’re using multiple venues including centralised exchanges. The major downside of this approach is the reliance on centralised entities for a problem that is solvable on-chain.

The proposed solution to this issue is that, instead of profits being directly converted into API3 and burned, a middle step is introduced — providing liquidity for the protocol’s own usage. This would be achieved through a dedicated contract, which buys both ETH and API3 with USDC and provides liquidity on a decentralised exchange such as Uniswap. This approach would gradually improve the liquidity conditions of the API3 token and make it possible to rely on fully decentralised token conversions without losing a major amount to slippage. The contract won’t have the options to ‘manage’ pooled assets and will be limited to two functions that can be called by anyone:

1. SwapUSDCandLPWithETHPair — uses ½ of USDC available to acquire API3 tokens, the remaining ½ to acquire ETH and pool these assets on UniswapV2. The resulting LP tokens are held by the contract.
2. RedeemLP — Redeems LP tokens held by the contract, swaps the ETH portion into API3 tokens, and burns all API3 tokens.This function can only be called when a LP position is older than 1 year.

This approach will allow liquidity to slowly build up on decentralised exchanges, have that liquidity be “sticky” (since it is locked for a year), reduce slippage and make it more attractive for potential stakeholders to decentrally acquire API3 governance power. A liquid DEX market will also increase the attractiveness of service coverage for dAPIs, as sponsors that receive a payout will have the ability to exchange API3 tokens on-chain, without losing the majority of their claim to slippage or being forced to rely on a centralised exchange in order to cost efficiently liquidate their claim. An additional side benefit is that the pooled assets will accumulate trading fees over a year, which will result in additional API3 tokens being burned when these positions are unwound.

Conclusion

This article laid out what dAPIs are and how they are monetized. It was explained why the economic moat cannot be gatekeeping data and why access to all dAPIs is free. The concept of BYOG dAPIs was introduced together with the new monetization method of paying for an increased (or any) amount of decentralisation. A first view into service coverage was provided together with an explanation of how potential users will pay for services. In addition, this article touched upon the concept of OEV, which will turn dAPIs into a source of income for projects using them and overall benefit the chains and ecosystems making use of them. Lastly, it was explained how profits will be used to operate dAPIs, pay underlying API providers and buy back and burn API3 tokens (with a little step inbetween).

Disclaimer

The writings herein are solely the opinions of the authors, are provided for information purposes only, and do not constitute financial, legal, or other professional advice of any kind, nor do they commit any authors or any related entities or persons to undertake or enable any described or implied actions. Any forward-looking statements herein are subject to risks, uncertainties, and assumptions which could prove to be inaccurate and, as a result, such statements could be materially incorrect and readers should not rely upon them.

Neither the authors nor any of their affiliates, nor any of their respective directors, advisors, contractors, employees or representatives make any representations or warranties, express or implied, with respect to any of the material or information contained herein, nor do any of the foregoing assume or otherwise have any responsibility, obligation, or liability whatsoever to any reader, any reader’s affiliates, or any of such reader’s or such reader’s affiliates’ respective directors, advisors, contractors, employees or representatives or any other entity or person resulting from the use of the information and material contained herein. To the extent any of the described services or products herein are enabled by or included in software promulgated by or for the benefit of API3, such software is provided without warranty of any kind, and without liability for any claim, damages, or any other liability whether in an action of contract, tort, or otherwise, arising from, out of or in connection with such software or the use of other dealings in the software.