We have released Airnode v0.7, which was a big update that both reworked parts of Airnode and implemented new features that we’re using heavily in new integrations. We have started working on v0.8 and an important part of this release is that its development will be tracked publicly. This has two implications: (1) The users will know what to expect from v0.8 before it’s released, (2) External contributions will be more feasible, as one can pick up a task from the backlog and work on it.
Another important development is that the OIS (Oracle Integration Specifications) implementation in the Airnode monorepo is migrated to its own repo (and the package name is updated from @api3/airnode-ois to @api3/ois). We have separated the OIS docs from Airnode docs before and this sets OIS further apart from Airnode as an oracle integration standard, rather than the integration specification format of a specific oracle node implementation. The current version of OIS was specified almost 2 years ago and what is expected from an oracle has changed since then. Specifically, in addition to delivering API responses, oracles are required to read on-chain, archival and logs data from arbitrary chains, and combine the resulting data in arbitrary ways. By supporting this functionality in coming versions of OIS, we will enable first-party keepers and bridges, in addition to more novel services.
ChainAPI being launched this week is probably important news for people reading our reports. For people who have already used an Airnode following our docs, the most interesting feature that ChainAPI provides is being able to check the status of the Airnode you have deployed. It is generally recommended for the API providers to have redundant deployments. These should at least be on separate availability zones, but the gold standard is a multi-cloud deployment (for example Amberdata has an AWS and GCP deployment at the moment). Furthermore, we practice A/B updates, which means an old deployment isn’t taken down before the new one is confirmed. Therefore, to provide a very reliable service, an API provider will sometimes have four deployments at a time on multiple platforms, which is obviously difficult to juggle. Airnodes deployed using ChainAPI are configured to send heartbeats to ChainAPI (a fully-outbound, trustless process), which allows ChainAPI to display what deployments you have online at a time, on which cloud providers and regions, etc. This functionality and everything else that ChainAPI provides is completely trustless (so that it doesn’t degrade the security guarantees that first-partyness provides) and for free.
As a final note, we’re finally there with our dAPIs. We have been running them on various mainnets for a long time now with great success. We have revamped our data feed docs to be more dAPI-focused, including the dAPI Browser embedded in our docs that displays on-chain data in real-time. While continuing the development of Beacon set-based dAPIs and the coverage product (and by the way, we released a whitepaper patch related to that), our next step is to start getting our first dAPIs in use.