Lessons from DAOv1
API3: The DAO & Staking, Part II
Ever since its conception, API3 has been governed over by DAOv1, which has secured the investor funds, public distribution proceeds, and most importantly, the ownership of the API3 token contract. It has even topped the Deep DAO chart for a while now.
DAOv1 was not only a useful vessel to hold the project assets for the authoritative DAO, but it also acted as a training ground for the decentralized governance of API3. In this post, we will discuss what we have learned from this process.
Fractal structures are the way to go
DAO scalability is often considered in the context of gas fees. Even though casting votes on Ethereum is indeed pricey, I’d argue that this is not the main bottleneck, especially for an operations-heavy project like ours. Stakers’ attention will be a much scarcer resource than their ETH. The organizational scalability is also another point to consider — how do we have the API3 DAO fund a large number of groups that work towards the common goal of solving the API connectivity problem? The solution to all of these is adopting a fractalized structure, or sharding the DAO.
We have started off with a flatter approach in the first operations cycle, and quickly found out that it hindered autonomy, because it’s much less likely for individuals to take initiative in groups of larger sizes (akin to the bystander effect). We quickly migrated to a team-based structure in the second operations cycle, where a team proposes a budget to take ownership of a specific part of the operations. After the proposal passes, the team can utilize their funds at will, and are expected to report their outcomes. This model was foreseen in the whitepaper, but it was surprising that the need for it arose so quickly.
I’m glad to say that the current teams are absolutely killing it, and knowing the fact that there are multiple teams out there, cooking things up and will be constantly delivering bolsters confidence. This is also very promising for our organizational scaling plans in the form of fractalized DAOs, about which we will talk more in the next post.
Running a DAO team requires entrepreneurship
In addition to doing their work, the DAO teams need to be able to write convincing proposals, keep diligent accounts of expenses and outcomes, and lobby to get what they need to do their job. In short, running a DAO team requires entrepreneurship. It becomes an issue if none of the members of a team is inclined that way, and they just want to do their work (which they may very well be good at).
It will be interesting to see how demanding the members of the authoritative DAO will be in terms of being convinced to fund teams, and if this will ever hinder operations. Of course, it cuts both ways, as reviewing the operations of these teams and deciding on one’s position on proposals will similarly not be everyone’s cup of tea.
On-chain incident response by the DAO is not a reliable option
In the context of oracles, an incident is service outage or misreporting due to a software bug, widescale infrastructure outage, attack, collusion or human/centralized governance error. There are two main ways of responding to these:
- On-chain, by making a transaction that will resolve the issue by making a modification or activating a fallback. This is fast and easy, as it merely requires a single transaction.
- Off-chain, by remedying the root cause. This requires cat herding and will result in the problem to persist for a few hours minimum.
The on-chain response is commonly executed by a single wallet or a multisig, though both of these options are not decentralized enough (and in fact, this centralization is why this option is fast and easy). Furthermore, any non-transparency regarding who the authorized parties are, on what basis they are chosen and how the token holders can depose them (if they can) degrades the security of the system further. Note that aggregation on permissioned side-chains or off-chain aggregation are already non-transparent, in which case this kind of a heavy-handed incident response may be preferable.
This begs the question: can’t we rely on the DAO for on-chain incident response? Our experience has shown that even within the smaller circle of DAOv1, it’s difficult to coordinate and pass proposals under time pressure. Therefore, in general, one shouldn’t design models that depend on swift and accurate DAO proposals. Therefore, on-chain incident response at the authoritative DAO level is out of the picture. Regarding what good off-chain incident response looks like both regarding execution and transparency, MakerDAOs post mortems are good case studies. (The opposite of this is the central command dictating actions and the details of the incident being swept under the rug.)
When it comes to maintenance (e.g., a new first-party oracle needs to be added to the dAPI), in the whitepaper, we have specified dAPI management teams (represented by subDAOs or multisigs) with programmatically limited authority that would act out the necessary on-chain interactions. Delegated maintainers with limited authority retains the decentralized quality of the provided services, while not suffering from the same issues that are caused by depending on the DAO for micromanagement.
Conclusion
In this post, we have discussed what we have learned from DAOv1, which were mostly validations of our assumptions. In the next post, we’ll talk about the organizational structure of the API3 DAO in a more comprehensive way. This will be about how we are planning to scale fractally and what its tokenomic implications will be.
