dAPIs: APIs for dApps

Author: Burak Benligiray

Compiled by: ChatCatcher

As discussed in the white paper, API3's goal is to "build, manage dAPIs at scale and profit from them." All the development we have been doing in this regard is because existing tools do not support dAPIs as we envisioned. So what exactly are these dAPIs?

A dApp is an application that is implemented as a smart contract running on a decentralized blockchain. For the same reason, a dAPI is a class of API service provided to smart contracts. Simply put, just as applications use APIs, dApps will also use dAPIs.

From the user's perspective, the design of dAPIs is similar to APIs:

• The relationship with users is transactional. Users pay according to a transparent pricing model to enjoy comprehensive services without bloodline contracts.
• It has a standardized, user-friendly interface designed to abstract the technical implementation.
• It is a managed service, as the complexity of operations is abstracted away. The user's only responsibility is to not miss payments.
  In addition to the above, dAPIs also have quantifiable security, as they can avoid losses due to failures (although this can even be compared to API SLAs). Here, the first-party nature or API-level decentralization of dAPIs strictly serves as a tool for optimizing insurance risks. Furthermore, dAPIs are not necessarily real-time data sources but represent a more general oracle service.

After this general definition, let’s examine the first generation of dAPIs we will build and their relationship with Beacons. As introduced in a recent talk at ETHDenver, our solution is designed as a hierarchy:

The lowest level consists of the Airnode protocol (RRP, PSP, relay RRP, relay PSP, API signature data). Authorized users can make requests to the corresponding Airnode at the protocol level. The Kassandra/Heimdall use case can serve as an example of this usage. Generally, implementing such use cases requires an in-depth understanding of the Airnode protocol.

The middle layer consists of oracle primitives such as Beacons. Whitelisted users can read the corresponding Beacons. The Amberdata Beacons built for ETHDenver are a great example. Although Beacons are built on the Airnode protocol, this fact is abstracted from the users, meaning they do not need to know any specific information about the Airnode protocol supporting the Beacons they are using.

The highest-level solution we will build is the dAPI. In real-time data feed use cases, a dAPI is a Beacon or a set of Beacons wrapped by a higher-level interface. Whitelisted users can read the corresponding dAPI without specifying which Beacons should be used in the background. In other words, by using dAPIs, users can offload the responsibility of managing the individual Beacons in the data feed.

The goal of this modular architecture is to allow users to choose the most suitable tools for their work. If they need a turnkey, one-stop oracle solution, they should use dAPIs. If they want complete control over the data sources, they should use one or a set of Beacons. If the solution they need is very niche, they can build directly on top of the Airnode protocol. Access control and monetization mechanisms are implemented at each level, meaning API providers can effectively productize their services to cover the entire range.

Since most readers will be familiar with Beacons, let’s compare the user flow of dAPIs with these for further illustration. Beacons are addressed by an ID, which derives from the corresponding Airnode address and request parameters. This means that the Beacon with ID 0x49e889871813b16854fd7faecad16b5ba59d33a9669b47f927501136840c021b will always represent the BTC/USD price reported by Amberdata. Similarly, a Beacon set is addressed by the hash of the list of Beacon IDs that constitute it, meaning the Beacon set ID will always reference a specific combination of Beacons. This is great because it allows users to specify the exact data source to the request parameters, eliminating any possibility of errors on the API3 side—such as converting silver to gold—and allows API3 to feasibly serve projects with a market cap 100 times larger. This is not so great because users will need a robust decentralized governance mechanism that can choose which specific Beacons to use and update them when necessary, which often does not apply to projects that are not yet mature.

This is where dAPIs start to play a role. A dAPI is essentially a name that maps to a Beacon ID or a Beacon set ID. Users address dAPIs by name, and the contract routes it to the corresponding Beacon or Beacon set. The API3 core technology team will perform multi-signatures across all chains of API3 services, making expert decisions to maintain the security guarantees provided by the coverage policy. Once this process matures, dAPI management will transfer to a separate, chain-native DAO described in our fractal scaling plan. For users managing dAPIs, this is not important, as they will receive insurance against governance incidents, regardless of who caused them. Therefore, any risks arising from the dAPI management scheme are considered part of the insurance risk, managed by the API3 DAO.
We are rapidly realizing the raison d'être of API3 dAPIs, which makes us proud. However, as the white paper states, the goal is also to achieve this "at scale," which means creating a dAPI economy comparable to the entire Web3. Our solution is designed to address bottlenecks that may limit ecosystem growth, so the way to achieve this goal is simply to do more of what we have been doing and let the Web3 space catch up.