We released Airnode v0.8 this month, which introduces a few useful features that we’ve been using in customized versions for a while. We’re currently working on v0.9, and have already planned out v0.10 and v0.11. As a reminder, we track our work on a public board (even though we can’t make all issues publicly visible), and have started representing more of our work there by fully migrating from our Jira boards.
The more curious people may have already noticed that we track our data feed operations (new API integrations, new Beacons being set up, dAPIs being reconfigured, etc.) using a public repo. We used this both to easily coordinate among ourselves through git, which we’re all conveniently familiar with, and also to provide the public and dependent services with an easily accessible, human-browsable, single source of truth. This approach made a lot of things possible — for example, tracking subscriptions and coverage services and the related payments, and processing these automatically with minimal development overhead — yet we found that it’s not dynamic and scalable enough for what is to come. In line with our future direction, we started rebuilding this piece of backend this month. Additionally, we did a lot of work this month on refactoring and improving the infrastructure that we have developed to operate data feeds at scale.
With recent additions to the core technical team, we finally gained the capacity to be able to do in-house API integrations (as the core technical team), and more importantly, analyze APIs for fitness to be used in dAPIs. Being able to use ChainAPI in integrations was reportedly a huge help in data feed integrations, which is good news considering that ChainAPI has launched workspaces and we decided to do all future data feed integrations through this functionality. While speaking of ChainAPI, it now supports all chains that Airnode protocol v0 (which will be used by Airnode v0.x) is officially integrated to.
We continued working on the data feed-coverage smart contracts and their frontend. This frontend will be implemented as a part of the DAO dashboard, as it’s essentially a dApp that the data feed users will use to interact with the DAO. Similar to how you would use the DAO dashboard to stake and vote, and Enormous’s DAO Tracker to see what the other DAO members are doing, there will be a separate frontend where you can inspect what coverage policies have been created for others, what claims people are making and what their statuses are. One thing that I forgot to mention in the August report is that Enormous’s team —which was an independent DAO grantee previously — has joined the core technical team for better coordination.
The most important news of this month is that the Market is updated to allow users to make a transaction on the respective chain to allow their contract to read any dAPI for the next 30 days. The previous version of the Market required the users to contact us for this in preparation of the on-boarding flow we had designed. As we diverged from these plans, the requirement to contact someone became a needless friction point, which we temporarily alleviated by this change. We’re planning to improve this data feed integration process further.
To avoid announcing announcements in these monthly reports, I either note what we have already delivered, or continuous infrastructure work whose results you will never see directly. This requires me to omit a lot of ongoing work. However, things have finally reached a level of maturity that warrant them being shared, so be on the lookout for new articles over the next month, which will unveil plans that will greatly affect API3 and this team.