Is API3 the ‘Chainlink Killer’?
This post addresses the recent sensationally titled CoinDesk piece, ‘Chainlink Killer’ API3 Closes $3M Funding Round With Placeholder and Pantera, and poses a rebuttal.
The answer, according to Betteridge’s law of headlines, is of course no, but I will elaborate. Because even though we have implicitly explained how API3 relates to Chainlink both in our whitepaper and Saša’s series, Getting APIs on the Blockchain, laying this out now explicitly may prevent future misunderstandings.
Let us start with how our theses differ. API3 poses that decentralized applications need to access Web APIs, and thus the problem we are facing is the API connectivity problem. The only feasible solution to this problem (in terms of security, cost-efficiency, and ecosystem building) is using first-party oracles, which are oracles operated by the API providers themselves. In contrast, Chainlink (and similar solutions) focuses on the lack of an interface, which is called the oracle problem, and aims to build this interface through third-party oracles. As a consequence, neither the protocol, nor the node is optimized to be operated by API providers (because API providers are not even in the picture), which harms the feasibility of first-party oracles.
See the illustration above. We started off with a different definition of the problem (i.e., the API connectivity problem over the oracle problem). This also dictates our solution, which is using first-party oracles. In contrast, Chainlink aims to solve the oracle problem through third-party oracles. (Here, it would be fair to show API providers singing their data off-chain as an alternative solution, though there has not been much progress towards that being done at scale.)
The problem that is being worked on (however you describe it) is not one that can be solved accidentally, but requires deliberate progress to be made directly towards the optimal solution. Then, it becomes clear why API3 and Chainlink are not direct competitors: They see a different problem and are working towards different solutions.
API3 aims to solve the API connectivity problem, and do this in a completely decentralized and ecosystem-driven way. Since we are convinced that this is the correct approach, other efforts that use different methods to reach different goals don’t appear to us as competition that needs to be killed, but as people doing their own things.
The Rebuttal
Let us start by pointing out two unfair advantages that we have. First, while designing our node, protocol, token utility, governance structure, aggregation methods, quantifiable security model, ecosystem approach and countless other aspects of the project, we had the existing oracle solutions to refer to with their merits and faults, including Chainlink. Therefore, if we are doing something in a starkly different way, it is either to fix a shortcoming, or to make an improvement.
Our second advantage is that while we are knowledgeable about existing solutions, Chainlink seems to lack the basic understanding of the most fundamental concepts about API3 —most notably, the difference between Airnode, the first-party oracle node, and API3, the DAO that builds decentralized APIs out of first-party oracles. However, this becomes frustrating when these misunderstandings start being presented as facts as a means of damage control, which is what seems to have happened with the CoinDesk piece. Providing correct information is the best retort, so let us address some points:
It’s a starkly different improved approach from that of API3, which requires all data providers to operate and manage new infrastructure to even get started. Chainlink’s origin-signed data capabilities are complemented by the even more important capability that allows smart contracts to access any and all APIs, a key feature API3 clearly lacks.
We will not comment on Chainlink and first-party oracles here, see this post for that. To correct the bit about API3, despite Airnode being also superior in a third-party usage scenario over the alternatives, API3 opts to use first-party oracles, because third-party oracles are a massive attack surface and cost-sink due to depending on middlemen.
As a second note, when one is serving high value use-cases such as DeFi, the API providers using third-party oracles as training wheels argument goes out the window. At that point, the responsible thing is to either get all the API providers to run their own nodes, or build a node that the API providers can run. API3 is doing the latter. And when we have cost-efficient and secure first-party oracles by a variety of APIs, why would anyone use third-party oracles again, for DeFi, or anything else for that matter?
API3 doesn’t have oracles that run their own Ethereum or other nodes, which means they are forced to rely on centralized third parties to broadcast their results,” the Chainlink Labs representative said. “This means that API3 is entirely dependent on services like Infura being live, which as we’ve seen recently, can fail for hours at a time, which in API3’s case, would lead to hours of downtime, out of sync market prices and therefore massive losses for users.
Here, the interviewee attributes a specific configuration that we have never considered for API3 in the first place (i.e., only using Infura) to the entire solution. What we have proposed was this: An API provider can keep an Airnode online indefinitely and at absolutely no cost by utilizing the Infura free plan and AWS free tier hosting. In fact, this being completely free is a key component in how we plan to achieve an ecosystem of hundreds of first-party oracles.
If an Airnode-operating API provider achieved traction (i.e., is generating revenue, for example, by serving API3), they are supposed to invest in their infrastructure, i.e., not use the Infura free plan, but expend a proportional amount to maintain a combination of Ethereum provider subscriptions/nodes for optimal uptime. This roadmap is a much more realistic strategy for large-scale adoption compared to throwing money at people to operate nodes, which is neither scalable, nor sustainable.
Let us take an illustrative turn and describe what would happen to an Airnode if Infura went down. Airnode is designed to use multiple Ethereum providers simultaneously, without requiring a load balancer. This means that for an Airnode to go down, all of its Ethereum providers have to go down simultaneously (and it doesn’t have a load balancer as a single point of failure). These Ethereum providers are a combination of centralized or decentralized service providers, plus a private Ethereum node if the provider so chooses to maintain and operate one.
At the end of the day, the performance of our decentralized APIs will speak for itself, but in the meantime, we don’t appreciate our solution being libeled with conjunctural scenarios based on misassumptions.
Conclusion
We believe there has been some misinformation regarding recent publicity, and the Chainlink claims about our solution were not fact-checked with us. This article is our attempt at hopefully clearing up some of these. To reiterate:
- We consider Chainlink more as a case study than a competitor due to the differences in our approaches.
- We are building Airnode specifically because we don’t find the existing oracle nodes reliable, especially for a first-party oracle usage scenario. Therefore, we don’t accept Airnode being posed as being less reliable than any of the existing nodes.
- Our more reliable design extends to how the node communicates with the smart contract platform. Specifically, it uses multiple channels simultaneously, which allows it to be uniquely resistant against outages.
