The evolution of DAOs: subDAOs
In 2018, I published an article analyzing the pros and cons of (de)centralization. As I was considering the topic, I was very particular about two aspects of decentralization that are pertinent to the blockchain space.
“Blockchain technology enjoys architectural and political decentralization, i.e. multiple computers in multiple locations worldwide (architectural decentralization) and no single party controls the software running on the network (political decentralization).”
We often talk about architectural decentralization which drives the kind of accidental fault tolerance and attack resistance, i.e. no central points of failure, that so many blockchain idealists dream about. However, in many ways, this is an easier problem to solve because, at its heart, architectural decentralization is a technological issue; we understand what we need to do, but we have physical and technological limitations.
Concerning DAOs, we deal with the hard problem of decentralization i.e. political decentralization. Political decentralization is essential to the general idea of decentralization because it builds ‘trust’ in the system by increasing attack tolerance and, most importantly, collusion resistance. Theoretically, the more nodes (participants) involved in the governance of the network, the higher the collusion-resistance, and the lower the influence of a single node which increases attack resistance. One might think that the more people governing a system, the better it is, right?
While it is easy to theorize, it’s very difficult to implement practically. In the aforementioned article, I stated three major drawbacks of absolute “political” decentralization:
1. Lack of focus: Too much emphasis on independent decision-makers at each level of a decentralized system can potentially create ambiguity about principal objectives and reduce their importance. Individual decision-makers may take actions that benefit their segments and not the system as a whole.
In centralized systems, central bodies make strategic decisions, defining the focus, while the rest of the system follows. In decentralized systems, governance is often complex, and decision making is slow and drawn out, which over time creates distractions.
2. Duplication of work: Decentralized systems are secure through the concept of redundancy. Each node (participant) in the system often repeats the same task that all the others do, creating an uneconomical system in terms of monetary cost, time, and energy. This model assumes that a central authority would be better at distributing tasks and resources, although the assumption need not apply in every situation.
3. Speed of action: Another tradeoff for the security and innovation that comes with decentralization is the expected loss of speed. This exchange is prevalent in many other areas of life. For example, if you go out to eat alone, you often find it easier to decide what to order; however, if you go out with friends, attempting to reach some level of consensus over what to eat and where to eat, takes a long time. This tradeoff also correlates to the first drawback: the lack of consensus, or rather a potential increase in the effort required to reach consensus, not only slows down the decision-making process but also removes focus from essential objectives.
The issue with how DAOs should best be governed, or even the more deep and underlying issue of how humans should optimally govern themselves, is an unsolved problem, as Saša Milić [co-founder API3] pointed out in her article on DAOs.
Political decentralization is the ‘hard’ problem of decentralization because, unlike architectural decentralization, we don’t even have a conceptual understanding of what is required from DAO members. The question of how best DAOs should be governed doesn’t have a right answer. However, as is usually the case for all hard human limits, the answer is probably not at the extremes but in the balance of the extremes. A balance must be found, some level of compromise on absolute political decentralization, so that the above-mentioned problems don’t undermine the long-term objective.
All of the above finally brings us to the topic of DAOs and sub-DAOs. As some very expensive experiments with DAOs have shown, completely flat token ownership/governance models haven’t succeeded. They either become too slow to stay flexible enough to adapt, or they become plutocratic and self-serving to a few ‘whales.’ Theoretically, a model where DAOs consist of a network of sub-DAOs seems much more promising. As a DAO scales and as the permanent functions required to sustain it grow with it, the network of sub-DAOs can continue to increase, creating decentralized focus areas that make the DAO much more efficient. With each sub-DAO delegated responsibility and specialized in a particular area, the network ensures efficiencies at scale, reducing redundancies and increasing the relative speed of action all at the same time. While the sub-DAO isn’t going to be as decentralized as the main-DAO, the point is that it doesn’t need to be either because once again, a subDAO limited in its scope, is not concerned with making all the decisions anyway, but rather a limited subset of the decisions that its members specialize in. On its own, the subDAO itself can act as a node on the main-DAO, representing the collective decisions of its constituents, internally decentralized enough to be secure yet focused enough to be efficient.
This topic was briefly explored by Saša in her article “On DAOs” with the API3 ecosystem in perspective. It has since been comprehensively discussed by Burak [co-founder API3] in his medium post “The Fractal scaling of API3” with a more robust argument for why subDAOs help with the evolution of API3, as a DAO across multiple blockchain platforms.
About API3
API3 builds decentrally governed and quantifiably secure data feeds that power Web 3.0 applications without employing third-party intermediaries. Powered by Airnode-enabled first-party oracles, API3’s dAPIs are fully decentralized and blockchain-native APIs with quantifiable security. Download the full whitepaper here.
API3 Links
Twitter — https://twitter.com/API3DAO
Telegram — https://t.me/API3DAO (Community Chat)
Discord — https://discord.gg/qnRrcfnm5W (Builder Chat)
Github — https://github.com/api3dao
Reddit — https://www.reddit.com/r/API3/
