API3 Core Technical Team Report, September 2021
We host our DAO dashboard on IPFS. There are a few ways to reach it:
- You can connect your Metamask to Ethereum mainnet and go to api3.eth/ This looks up the IPFS CID from the ENS contract and uses a public IPFS gateway to take you to the dashboard.
- You can go to https://api3.eth.link, which uses Cloudflare’s name resolver.
- You can go to https://dao.api3.org to be redirected by api3.org to the public IPFS gateway.
In addition to some not always being available, all of these options require you to trust third parties. As a trustless alternative, we now provide instructions for building and running the DAO dashboard locally. In addition to being more secure, this method will always be available despite potential IPFS infrastructure outages.
In the July report, we have mentioned that demand for a new Airnode release was building up, and after the DAO launch — which was most imperative — we finally had the opportunity to focus on it. We responded in three main ways: (1) Design a project management and release management flow to support rolling releases (mentioned in the August report), (2) start working towards a fast initial release, which can then be iterated on, (3) finalize the request–response protocol and have it audited.
We have made a lot of progress on all three of these items, but I will focus on (3) specifically. We have released the pre-alpha version at the start of this year both as a POC to demonstrate that we can feasibly achieve a large number of first-party oracles, and also to collect feedback from internal and external stakeholders. The contracts of this version were audited, and additional review and usage did not uncover additional issues. Therefore, despite its name, the pre-alpha version is actually quite solid.
One issue with the pre-alpha version is that it keeps the authorizer implementation out of the scope, and expects the user to implement it based on their needs (or make all endpoints public, which is quite fine in most cases due to how the protocol is designed to have the requester pay for all gas costs). As described in the March report, the authorizer is where the first-party oracle business model is implemented. This is why we refrained from locking in the authorizer design prematurely, yet we are now at a position where we have a clear understanding.
This month, we implemented authorizers, finalized RRP and are currently undergoing an audit by Certik. Once we pass the audit, we will publish an in-depth article about what has changed in the protocol since pre-alpha, but in short, it’s a much more streamlined user flow + ready-made authorizers.
As a final note, we would like to showcase the Airnode RRP Explorer, a tool to search for and decode requests and responses submitted through the Airnode protocol (specifically, the pre-alpha version, though updating it should be simple). To explain roughly, for the same reason that a regular Ethereum user needs to refer to Etherscan frequently (and developers a lot more), it’s not possible to imagine widespread adoption of the Airnode protocol without this kind of a tool being available. Therefore, it’s difficult to overstate the importance of this tool, and we’re excited to see how its development will continue.
