In the June report, we have announced that the public DAO test started on June 28. After a fast-paced and fruitful test process (which we again thank the participants for), we announced the mainnet launch, which was executed successfully on July 15. This has been the most financially ambitious achievement of the project, and surpassed the public token distribution in its scale. This is the second project-scale milestone that the core technical team has achieved after the delivery of the pre-alpha version of Airnode, and we see it to be our mission to deliver similarly long-running and mission-critical projects.
To give some context for governance purposes, I’ve published an article, recounting the unanticipated development process of the authoritative DAO. The relevance of that to this report is that the core technical team was only responsible for “overseeing and supporting” the development of the DAO contracts and dashboard, yet we stepped up to undertake the entire development and operational tasks when it ended up becoming a necessity. To finalize the project in a timely manner, we had to deploy a total of five senior developers (three full-time, two part-time) and two designers from the core technical team and the ChainAPI team (distributed approximately 50–50 between the two teams).
This has two implications:
- The core technical team is willing to get the DAO out of trouble at the cost of diverging from its own plans. Furthermore, it’s quite successful at this. (Good intentions by themselves do more harm than good, taking over the project only to fail would have been disastrous.)
- The only reason we succeeded at this was that we had a number of senior developers across the core technical team and the ChainAPI team that could easily adapt to a project that they weren’t selected for in the first place, and we had the authority to make this call (i.e., “We will stop what we’re doing and will now take over this task that someone else was supposed to do.”)
Performing well when everyone else is doing their jobs perfectly is not a feat, it’s the bare minimum. Through this affair, the core technical team has proven that it can be trusted with turning funds into a general kind of problem solving capacity, which allows it to turn unexpected problems into wins.
It has been more than a year since we started working on Airnode, which is what makes the value proposition of API3 feasible. That’s because if you propose first-party oracles as a solution to the ecosystem building problem around oracles, you first need to answer the question of why we don’t already have first-party oracles and how that will be possible going forwards. We released the pre-alpha version of Airnode towards the end of 2020, aiming to test it in real world conditions and iterate on it so that we have a much stronger foundation to build on. During this time, we received a lot of confirmation that it makes a lot of sense to the stakeholders by design and performs very reliably, but we also discovered some friction points that seem to consistently cause UX and business problems. In a similar way, some of the nice-to-haves that we have implemented at the cost of increasing complexity turned out to be not necessary at all.
During this month, it became clear that there is immediate demand for a future-proof (read: that won’t get breaking updates) and production-ready Airnode with all the new features that we have implemented since the release of the pre-alpha version to address the issues mentioned above. As a result, we started working on Airnode Beta (a working title) this month. We have greatly revised the protocol to simplify the UX and extended it to implement the monetization features that were omitted in the pre-alpha version. Following its audit and the implementation of these changes at the node-end, we’re planning to start using this internally with our partners and release it for the public to use to integrate APIs to smart contracts.