Where are the first-party oracles?
In the last week’s installment of “Getting APIs on the Blockchain”, a comprehensive comparison was made between first and third-party oracles. I will be taking over for this week and set the stage for a spin-off series: “Airnode: The first-party oracle node”.
Okay, first-party oracles are the best thing since the sliced bread, but where are they? It only makes sense for API providers to spin up their oracle nodes, cut off the middlemen, and serve the on-chain data consumers themselves. There certainly seems to be enough financial incentive to do so, and the data consumers would prefer that anyway. However, there are greater obstacles in the way of first-party oracles.
The Great Filter hypothesis poses that the reason why we haven’t met extraterrestrial life yet (see the Fermi paradox) is because there is an absolute obstacle that prevents civilizations (including the one sprung up on Earth) from achieving interstellar colonialism. The exact nature of this obstacle may range from inevitable nuclear war to virtual reality-driven societal collapse, but what is (supposedly) certain is that it is there, and no civilization before was able to overcome it. Then, what is the great filter of first-party oracles?
Our creds
To really appreciate the difficulty of achieving first-party oracles, you need to have done the following:
- Operate an oracle node in a professional context;
- Talk to API providers about operating oracle nodes.
To say we have done these would be an understatement. We built the Honeycomb API Marketplace using Chainlink as the underlying infrastructure (this is especially significant because nothing teaches you about a type of software like trying to build a business on it), operated 6 Chainlink nodes simultaneously, not counting the redundancies (4 for Honeycomb, 2 for Chainlink), and maintained the highest response ratio on reputation.link (meaning that we had stellar monitoring and incident response) until we asked to get removed from the data feeds to focus our entire attention on API3.
Talking to API providers is essentially our forte. During our 1+ year work on the Honeycomb API Marketplace, we educated a very large number of API providers about monetizing their services through oracles, and learned an immense amount about their requirements and constraints while doing so. Towards the end of our efforts, we focused on getting the API providers to operate their own oracles (remember, we didn’t call them first-party oracles back then), which gave us greater insight into why this is such a difficult problem.
List of deal breakers
Through all this fieldwork, we were able to come up with a list of oracle solution characteristics where each item is a certain deal breaker for (reliable and financially feasible) first-party oracles.
1. An unstable oracle node
Nobody would want to work with an unstable piece of software, but this is especially true in the case of first-party oracles because an unstable oracle node requires two things:
- Constant attention to notice incidents;
- Know-how to be able to respond to incidents.
A typical API provider can afford neither of these, which results in an unstable oracle node not being an option for first-party oracles.
2. An oracle node that cannot self-recover
Even if an oracle node fails very rarely, if it cannot recover from the failure on its own, it will require user intervention. Therefore, the node must not only be stable, but it must be able to recover from bugs or adverse network conditions on its own, rather than being incapacitated permanently.
3. Vague configuration recommendations
One cannot expect from an API provider to investigate the node architecture, the use cases and experiment to find the optimal node configuration (where to host the nodes and their databases, how much redundancy to have, how to determine all the parameters, etc.). “It’s up to you!” is a cop-out far too common, which should read “You are on your own.”
4. An oracle node that requires auxiliary software to perform
It’s not reasonable to expect the API provider to find what monitoring, API integration, node deployment/configuration software they need to use (and even develop it themselves if they are not readily available) to provide production-level service. Everything that is needed has to be included in the box.
5. Being paid in cryptocurrency
Being paid in cryptocurrency is easy, dealing with the legal, compliance, and accounting issues is not. It is far too common for real world businesses to leave potential cryptocurrency revenue on the table because taking it would end up costing them more. I’d like to emphasize that this is not a problem you can educate yourself out of. If the API provider doesn’t have existing legal infrastructure to generate revenue in cryptocurrency, they (or at least the law-abiding ones, which are typically the ones you’d want to work with) will not accept it no matter how much of a fan of cryptocurrencies they personally are.
6. Having costs in cryptocurrency
Existing oracle solutions have the oracle node operator pay for the node’s transactions. This means the node operator would have to keep buying cryptocurrency to pay for these. Simply not an option for 99% of the real world businesses, and even less so when you consider that these oracles would be serving on multiple chains and would need multiple types of these cryptocurrencies.
7. Having the API provider stake
This is an even greater issue compared to having revenue or costs in cryptocurrency. For most businesses, it’s very difficult to report potential gains or slashes from staking without getting into AML issues, and avoiding to participate is the wisest option. Unfortunately, even a rock-solid game theoretic proof that looks great on the whitepaper doesn’t mean much when it requires real world businesses to break the law.
Conclusion and next blog post
The obstacles currently in front of first-party oracle adoption are so deeply-rooted that clearing them requires a whole new approach — we need to design both the oracle protocol and the oracle node to directly address the needs of the API provider.
Here is where our blog series branches off. To fully understand and appreciate the design of API3’s Airnode, we begin a new series next week: “Airnode: The first-party oracle node”. This series (“Getting APIs on the Blockchain”) continues next week with why staking is difficult to implement for oracles (and why we thus chose a different security model.) Keep a look out for these posts next week!
[See the next article in our series here.]
