API3 Core Technical Team Report, January 2022
As explained in the December report, the core technical team carefully started expanding its efforts towards building products that utilize Airnode, in addition to building Airnode itself. Beacons are the first of such oracle primitives, yet “building Beacons” doesn’t say much because a Beacon is an abstract product, and is brought into reality by building and combining many pieces of technology. What unites these is that they all depend on or interact with Airnode or its protocol, and this recent work has shown us that Airnode is a really solid foundation to build things on thanks to its design and implementation.
We continued our work on Airnode v0.4 this month, and are expecting to release it in a week. We didn’t rush the work on v0.4 — as the current v0.3.1 is provably capable of powering Beacons — and aimed to achieve all of our wants instead. The scope for v0.5 is agreed on; the features to be implemented will mostly be focused on improving Beacon performance further in terms of cost-efficiency.
Here’s something that you may not have heard about before: Airkeeper. We have been criticizing oracle nodes for not being designed to optimize the user requirements. The truth is, the same requirements apply for keeper nodes and bridges, people want them to be performant and set-and-forget. Furthermore, adding the ability to make API calls to such nodes would supercharge them, and in our case, these would be first-party API calls that can be depended on for executing transactions of financial nature. This all is obviously exciting, but our reason for building Airkeeper now is more practical: We want Beacons to be operable solely through the request–response protocol (RRP).
At the moment, Airkeeper is specifically designed to “keep” a Beacon alive based on an arbitrary deviation threshold. It is similar to Airnode in terms of operational requirements, meaning that it can easily be operated by an API provider. Furthermore, one can operate as many of them as they want in a third-party way to create redundancy, and add an incentive mechanism to increase their robustness. Note that the Airnode protocol also doesn’t include an incentive mechanism. From the whitepaper:
…Finally, let us briefly mention how the Airnode protocol approaches monetization. It is common for a project-specific token to be worked into the core of the protocol in an attempt to ensure that the said token is needed. However, this induces a significant gas price overhead, severely restricts alternative monetization options and creates overall friction. For these reasons, the Airnode protocol purposefully avoids using such a token. Instead…
Here, the motivation is the same. The keeper protocol that isn’t built around a token will eat the others.
I like describing the publish–subscribe protocol (PSP) as an oracle and a keeper rolled into one. Therefore, Airkeeper could be seen as a less-protocolized, proto-PSP node. In other words, Airnode that supports PSP will be able to do everything that the Airkeeper is currently doing, including triggering first-party RRP requests when necessary. We are getting into the weeds a bit here, but the point is, the long-term plan for Airnode is for it to be a first-party, cross-chain oracle and keeper node. This new functionality is developed in components independent from Airnode (such as Airkeeper) to avoid introducing issues to Airnode, which is desired to be very stable. Once this functionality reaches maturity, e.g., is able to support full-PSP, it will be merged to Airnode.
Another key component of Beacons are their operational side. In a decentralized solution, this means keeping a transparent source of truth, which can then be used to top up the sponsor wallets periodically, visualize the metrics and monitor them to detect anomalies. The key thing we have considered here was to not reuse any Airnode/Airkeeper implementation. Although we have a strong toolbox we can draw from, we are verifying the integrity of this very toolbox, which makes it off-limits for this kind of work.
Finally, one builds a product for it to be used. Any developer knows the importance of a good SDK. However, what that means completely depends on what it’s for. The Airnode protocol is very powerful, which is a requirement for some builders such as OBP. There are also some builders that just need the price of X, and they can’t be bothered with reading through our Airnode documentation, however much pedagogical it is. What we are aiming with the Beacons is to abstract away the entire Airnode implementation, so that the user simply needs to interact with a contract that they read a value from. But even while doing so, we are benefiting from the Airnode protocol design, in that a first-party Airnode has the same address on all chains, and a specific request to these Airnodes are all identified by the same ID on all chains, which means we don’t need to duplicate documentation across chains — one thing that works on one chain also works on another in a verifiably identical way.
And this is the end product:
A first-party Airnode–Airkeeper pair, operating a Beacon (yellow) that tracks the API response (green) at the deviation threshold they were configured for. We will be making a variety of these Beacons available at ETHDenver, of which API3 is the official DeFi track sponsor. We are big proponents of user-centered design, so we will use the feedback gathered from Web3 developers and projects to hone our design.
As a final note, I find it ridiculous how swift and skillfully everything around Beacons is tied together, all the while not disrupting the work on Airnode. For this, I feel the need to congratulate the core technical team.
