We do two things at API3:
- Build the tooling that will make Web APIs available to smart contracts in the form of first-party oracles. This is not limited to integration, but also productization and monetization.
- Foster an API-first oracle ecosystem to break through the chicken-and-egg problem that is common in emerging technologies.
The goal is to turn services that real-world businesses provide into building blocks on the blockchain, which developers will be able to compose into complex use-cases in a trustless way. These projects will be able to create value by the virtue of embodying real-world services, and will be a quantum leap over the speculatory Rube Goldberg machines that DeFi composability is limited to today.
The implications of this far exceed the traditional DeFi use-cases, yet an elegant solution should be expected to apply for a variety of problems, and this is the case for first-party oracles. If one wants to set up a live asset price feed on-chain, doing this through first-party oracles is the ideal solution due to many reasons listed in our whitepaper. In this post, we will build up on this and discuss the how of it.
What is wrong with “decentralized” oracles?
The weakness in the traditional decentralized oracle model is that the assumption that powering a service through multiple nodes or APIs makes it decentralized. However, there are two additional requirements that all decentralized blockchain projects must satisfy:
- Lack of centralized governance
- Transparency, to be able to validate the decentralization requirements
Transparency, to be able to validate the decentralization requirements
Take the recent issue with the CoinMarketCap API for example. What can you make of this screenshot?
On the surface, it looks like only 01node was affected by the issue. Were they only using the CMC API, or were they using other APIs that have misreported? What about the other nodes, how many others were using the CMC API (and/or others that have misreported), and how close were they to misreporting themselves? The answers to these questions don’t matter, the point is that they can’t be answered trustlessly.
Normally, one should assume a lack of decentralization if they can’t verify it. However, this is not always the case:
This begets the question: Why would anyone assume that Chainlink has never operated a “decentralized” data-feed using only 2 APIs? If this has ever happened under the veil of source obfuscation, is this not a graver issue than Band doing it openly?
Our solution: First-party oracles, Beacons, dAPIs, insurance
First-party oracles imply an inherently one-to-one mapping between data sources and oracles. Then, discussing transparency is redundant, as the oracle is the data source and the data source is the oracle. This is very useful in dealing with issues such as the recent CMC misreport, because one can be ensured that other first-party oracles are guaranteed to not be affected by the incident. Moreover, this allows the consumers to choose their oracles based on data source performance. Compared to this, you can’t tell to what degree third-party oracles will be affected by such an error or if they will take precautions in the future because their data sources can’t be investigated transparently.
Individual first-party oracles will fare better in the case of data source problems, while third-party solutions obscure weaknesses until a catastrophic failure. What we want to discuss in this post is how data feeds should be designed to complement the first-partyness of the constituent oracles. To this end, we introduce a new concept called a Beacon, which is an atomic data feed that is powered by a singular first-party oracle.
Michael Thompson, The Lighting of the Beacons, 2017.
A Beacon is a point of data that is kept alive on-chain by the respective first-party oracle. Anyone is able to request a Beacon to be updated, given that they have funded their sponsor wallet that will be charged for the gas cost of the update. These updates can either be triggered by requests made through the request–response protocol, or will happen automatically based on the respective condition specified through the publish–subscribe protocol. In other words, Beacons will be built on the Airnode protocols, and carry over the data source transparency from the oracle-level to the data feed-level.
The traditional way a data feed is built is that the data consumer is confined to what the centrally governed oracle project thinks is a good idea, and they don’t even know what they are agreeing to due to third-party oracles not being transparent with their data sources. In other words, the lack of composability is as important of a problem as the lack of transparency, as it disables the data consumer from rejecting data coming from a particular provider.
Beacons will be the building blocks of dAPIs, meaning that a particular dAPI will be built as an arbitrary combination of Beacons. The Beacon-based dAPI architecture creates a paradigm shift in that it not only allows the user to see where exactly the data comes from, it also gives them granular control over the selection if they wish.
Although Beacons are excellent components to build dAPIs out of, they are also ideal for standalone use when:
- The Beacon is reliable enough for the use-case and decentralization creates an unjustifiable overhead
- The Beacon is exceptionally reliable to the point that any decentralization would degrade the result
Therefore, we foresee that API3 services will include both individual Beacons and dAPIs that are built out of these Beacons.
But what if a client uses a Beacon in standalone fashion and the data provider keeping the Beacon experiences a failure? Beacons and their vast combinations in the form of dAPIs all appear as equivalent live data points on-chain, with differing levels of reliability. Then, singular Beacons — or from another point of view, dAPIs built out of individual Beacons — can share the same security guarantees that are meant for dAPIs: Insurance, made possible by API3 staking. The same incentives would apply, in that the DAO would only insure Beacons for standalone use if they are assessed to be adequately reliable, and black swan events would be covered by insurance premiums collected during normal operation.
The recent CMC issue has validated our concerns about third-party oracles lacking data source transparency and how this makes it impossible to assess their level of reliability or decentralization. We found this to be an apt opportunity to introduce Beacons, as they are both data source-transparent and give the dAPI consumer not only information, but also control over where they get their data from.
An important benefit of standalone Beacons secured through insurance will be breaking down the currently monolithic state of DeFi. When an oracle project is operated by a traditional centralized organization, this limits the number of chains and data feeds that they can serve, which forces their consumers to flock to the same chains to use the same data feeds or starve. Beacons will enable many previously infeasible use-cases and allow DeFi to grow wide, and not only tall.
Finally, we find Beacons to be a very important step towards democratization of data feed composition and governance. This is closely related to our fractal scaling vision, in that we expect dAPI curation out of Beacons to be one of the important verticals that API3 ecosystem projects will pursue. For that to be possible, it is of utmost importance for dAPI composition to be easy and permissionless, which is one of the aims of the Beacon-based architecture.
In this post, we have briefly introduced Beacons and how they fit in with our existing first-party oracle approach, dAPIs and insurance. We’re sure you have questions and ideas, so feel free to join our Discord and discuss them with the community.
Previously published here