We launched the DAO in July, and have been maintaining it since:
- Fixed a frontend regression that broke the radio buttons
- Redirected dao.api3.org to the DAO dashboard through an IPFS gateway as an alternative to api3.eth.link because it is not reliable due to the distributed DNS infrastructure it relies on (api3.eth.link is still the recommended URL)
- Fixed a number of issues, most notably one that caused unstable WalletConnect experience
The operations proposals went by smoothly, with no technical issues. Furthermore, the feedback on the staking flow is overwhelmingly positive (apart from the connectivity issues addressed above), which validates the design and implementation. Currently, we have a list of nice-to-have features that we want to implement, yet they do not hold top priority on our to do list.
7 weeks after the DAO launch, the DAO has met the staking target of 50% of the total supply. Currently, the staking reward started decreasing slowly, while the staked amount still sits slightly above the target. The main caveat with such dynamic systems is that if they are not initialized well, it will take very long for them to stabilize. The current behavior indicates that the initial values for the staking reward parameters were estimated well, and it should be smooth sailing around the staking target going forwards.
The fact that the staked amount is increasing slowly despite the reward decreasing slowly can be attributed to the estimated smart contract risk decreasing more significantly, and accordingly, more people finding staking API3 to be a good deal. In a similar vein, DAOv1 started migrating her funds to the authoritative DAO. At the moment, the primary treasury holds 10 million API3, while the secondary treasury holds more than 3 million USDC (a proposal requires 50% quorum to use the funds from the primary treasury, and 15% quorum to use the funds from the secondary treasury). In the absence of incidents, the gradual migration will continue.
The DAO dashboard is very minimalist in what it does to provide the following:
- A very simple user experience, as it is meant for all token holders
- Being able to run it on fully decentralized infrastructure that can survive abandonment (in a DAO context, the bus factor also applies at the team scale)
- Being able to run it on chains other than Ethereum mainnet (where certain dependencies in the form of decentralized protocols may not exist)
However, we were quickly let known that this wasn’t going to satisfy our power users. As we were planning to enrich the dashboard with a few additional features, Enormous posted the DAO Tracker on the forum. I recommend you to click around if you haven’t already, but in summary, it’s very good and makes any work by us towards the same end redundant.
The DAO Tracker contributes to API3 in a couple ways. We recently got two additional technical teams (1, 2), yet this is one other that popped up in a permissionless way and managed to make a significant contribution without any coordination with the existing teams. This demonstrates that the scope of API3 is large enough that one can imagine an ecosystem of independent actors working on it and pushing it forwards. Another point is that the DAO Tracker is potentially a critical component of API3 governance, like the Telegram group, Discord, Twitter handle, DAO dashboard, representation at community calls, conferences and interviews, etc. It’s healthy for such channels to not be consolidated at the hands of a single team, and this was one of the reasons why we didn’t want the DAO dashboard to be a web application with a traditional backend (that the core technical team controlled). From this regard, the DAO Tracker being hosted by an entity independent from our team is desirable.
In last month’s report, I mentioned that we’re back to focusing our attention on Airnode. We made a lot of progress this month, but we have yet to reach a milestone that would be appropriate to make an announcement at. In parallel to this work, we are overhauling our project management and release management strategy, which should increase the transparency of the state of development (essentially act as a team-scale roadmap), allow Airnode users to track when we will support certain features and help developers find out where their open source contribution would be most effective.