API3 DAO Development Report, April 2021
This is the final development report for cycle #2, following the February and March reports. See the DAO & Staking Part I post for the state of the development on that front. I’ll be keeping this report brief and factual and focus on the rest of the DAO & Staking posts as there is a lot of material that needs to be covered.
Airnode
In the March report, I had mentioned that the new Airnode deployment file specs and flow had been established that will support multiple simultaneous deployments across different cloud providers and regions. This month, the deployer package is updated to implement these. In addition, the RRP admin CLI is updated and a lot of additional minor updates were made towards the v0.1.0 release. (A note about the “v0.1.0 when” questions, pre-alpha is doing the job well for prototyping and there is no particular reason to rush the release.)
It has always been the plan for the Airnode deployer to be migrated to use bare Terraform (instead of Serverless Framework), as that would provide the optimal flexibility regarding using additional cloud infrastructure (VPCs, managed Ethereum nodes, etc.) and different cloud providers, yet it was approached as more of a long term plan. This month, we had additions to the team that could make that a reality much sooner. Therefore, this is now on the menu for v0.1.0.
Authoritative DAO
The Aragon framework uses MiniMe to implement governance tokens by default. The authoritative DAO was implemented with a similar approach. In one of the audit reports, it was (rightly) suggested that this should be replaced because its access methods (based on binary search) require a variable amount of gas, which may end up being a problem. As a solution, we replaced all instances of these access methods with workarounds with deterministic bounds for gas costs, both defusing the risk and optimizing the gas costs.
Unrelated to the audits, we updated the DAO structure so that there are two levels of quorum that need to be reached to enact different types of proposals. This will allow us to better secure critical functionality such as API3 token minting rights management (by having it require a higher quorum threshold than day-to-day proposals), and will be explained in detail in one of the upcoming DAO & Staking posts. The DAO contracts are still undergoing audits at the moment.
Open Bank Project
The big news of this month was the announcement of our long term development partnership with the Open Bank Project. As implied by the lifetime of the partnership, there is a long road ahead to solve the API connectivity problem for the banks, and there is no better reason to start working on it right away. This month, a combination of the core technical team and the integration people of the API BD team started familiarizing ourselves with the OBP solutions. In addition, we started having joint calls with OBP for exploration and to plan the following development steps.
dAPIs
This month, we have conceptualized the RRP-based dAPI architecture, which ended up elegantly mirroring the Airnode RRP architecture (i.e., calling a dAPI or a single Airnode looks and feels rather similar to the user). Alternative reduction methods have been implemented in a very scalable way, both complexity and gas cost-wise. We are currently implementing a dAPI server contract that will use these reduction methods to create and serve dAPIs in a permissionless way.
Keep tuned-in for the DAO & Staking series posts as they will dive into the implementation details, which you should definitely be aware of if you are intending to stake and participate in governance.
