API3 DAO Development Report, March 2021
To summarize last month’s development report, you currently can use the pre-alpha version of Airnode to integrate an API to a smart contract (see the related monorepo branch and docs).
This version of Airnode can be operated as
- An AWS serverless function
- A Docker container (on cloud or locally)
The pre-alpha contracts have been audited by a third party, and this version is being used to prototype integrations. We are working on a v0.1.0, which functionally will be exactly the same, yet have a stable (read: unchanging) protocol and UX flow based on the feedback from the pre-alpha.
Roadmap
In the most recent community call, there was a question about whether the roadmap is flexible. If you have referred to the roadmap more than a few times, you probably have noticed that monoliths and undertakings move around. This reflects the fluidity of the roadmap, which is why we prefer to use a board instead of a static image or webpage. Such changes tend to be based on new data, and what we have found out is that not only first-party oracle-based dAPIs, but also stand-alone first-party oracles are very much in demand (and more importantly, in a way that cannot be substituted by third-party oracles in any feasible way).
In this paradigm, quantifiable security through insurance is the focus, and dAPIs are a tool to be used to maximize the amount of insurance that can be provided, which is redundant for a lot of untapped use cases. In other words, the dAPI concept is a tool to be able to provide a specific (even niche) level of security, and not the goal. Being able to purchase first-party oracle access and insurance is what creates the demand for the API3 token, so focusing on this aspect (instead of dAPIs specifically) will align the direction of the project with its tokenomics more directly and at a wider scale. In short, the roadmap is indeed fluid, and is coupled with the strategic direction at an abstract level.
Authorizers
Let’s start with a related topic: The specifications for the authorizer contracts are established, followed by their implementation. To briefly explain what an authorizer contract is, it’s used to extend the Airnode request–response protocol to allow an Airnode operator (i.e., API provider) to manage access to their first-party oracle based on a customized policy.
We strive to design a flexible framework that will cover all potential use-cases, as we want to build the standard to integrate APIs to smart contracts. On the other hand, we’re not a fan of under-defining solutions under the guise of “giving the user freedom”, because that is often used as an excuse to dodge the more difficult problems (how do you decentralize oracle governance, how do you quantify security, how do you specify integrations, etc.). The solution is to implement the customizable authorization framework mentioned above, but also provide the user with ready-made authorizer contracts.
Authorization is about managing access, and access management is the primary tool for monetizing a service. This is why establishing specs for these ready-made authorizer contracts is difficult; it’s not a purely technical matter — nothing about oracles ever is — and requires strong assumptions about monetization both for API providers and the API3 DAO. Furthermore, one needs to consider the UX implications; if you need oracle node operators to reconfigure their node or make a transaction each time a new use-case will use their services, your solution will not scale.
Considering all these factors, we came up with two authorizer contracts: Api3Authorizer.sol allows one’s Airnode to be accessible with the usage of API3 tokens without requiring any API provider interaction (more details about this will be announced later on). This is the primary authorizer contract that will be utilized by the API3 partners the majority of the time. SelfAuthorizer.sol allows the API provider to whitelist users themselves based on any criteria they want, and ChainAPI (with its requester interface undertaking) will include an interface (essentially, a dApp) that will allow the API provider to do this (note that this will simply be an interface, the API provider can also do this by interacting with the authorizer contract directly). An Airnode operator is free to use a combination of these authorizers plus ones that they may have implemented to enforce more complex authorization policies that these ready-made contracts may not support.
Airnode developments
- Work on dAPI contracts has started. The initial goal is to have a typical aggregating contract that will be integrated with the request–response protocol, with more novel features to be delivered in the future.
- The new deployment file specs and flow for v0.1.0 is established and are currently being implemented. This will support configurations that utilize multiple simultaneous deployments across cloud providers as first-class citizens, which will result in unmatchable resiliency.
- The OIS validator package is updated according to these new specs, and will go into use with v0.1.0. A quick plug here for a recent post that explains what OIS is and why it’s a big deal.
Docs
We have moved our docs to the api3.org navigation bar because it has reached a stable point. It has a lot of customized components such as a version selector (that only lists pre-alpha at the moment) and an extra table of contents on the right that makes navigation easy. The docs starting from v0.1.0 will be divided into sections according to roles. At the moment, a documentation page targeted at the API3 DAO members (hopefully you!) is being worked on.
Authoritative DAO & Staking
In the last month’s report, we had left off where we were preparing for the first DAO audit on March 8th. I’m happy to say that we’ve received an approving report on March 22nd. The suggestions are largely addressed at the moment (with the addition of some significant gas cost optimization) and we’re doing our final tweaks before sending it off for the final stamp of approval. This will probably coincide with the start of our second audit on April 4th mentioned in the last month’s report.
The beginning of the first audit also marks Curve Labs, one of the API3 founding teams, starting to play a much more active role in our DAO development. You can see their first proposal here, which covers the phases starting from the audit to the launch of the authoritative DAO. What is exciting about this development is that as mentioned in their proposal, they are planning to take ownership of the long-term development of the authoritative DAO and its extensions, which was something that was very much needed.
I’ll end this with some very significant news that may have gone under your radar. AWS has announced that they now provide managed Ethereum nodes for public chains through Amazon Managed Blockchain. We knew that this was in the works as early as last Summer based on our communications and were designing the Airnode architecture accordingly, but it being delivered this early accelerated the timeline for API3. The implications are two-fold:
- On the practical side, a managed Ethereum node is the perfect complement to Airnode, the managed oracle node. As an alternative to using centralized service providers like Infura and decentralized service providers like Pocket Network, this will allow an API provider to run their own Ethereum node with no effort. Since Airnode is already run on the cloud as a serverless function for maximum availability, operating the Ethereum node on the same platform doesn’t degrade security (and is even preferable).
- More importantly, public blockchains are starting to become a part of the cloud stack in the form of managed services, and we can expect this to be followed by integrations with more chains and cloud providers. This is bad news for the middleman node operator and solutions that depend on it as their moat, yet is perfectly in line with our vision for Airnode as the API gateway for blockchains, and positions API3 as the provider of this piece of technology.
