Fractal scaling of API3
API3: The DAO & Staking, Part III
In the absence of a consensus mechanism, immutability is required for smart contracts to be trustless. DAOs are commonly used to provide this consensus functionality at the smart contract-level to update parameters of a decentralized application, and even upgrade entire contracts without having to resort to centralization. Although this is the main reason for being for most DAOs out there, today, we are experimenting with a far more impactful use case.
API3 is a first-party oracle solution, which necessitates significant business and integration operations — in the real-world, the “meatspace”, not the blockchain space — in addition to the regular software development and marketing that blockchain projects tend to conduct. For API3 to fulfill its goals, these wide variety of operations will have to be run at a massive scale. Only a few entities in the blockchain space need to cover so much ground, yet paradoxically, they opt for centralized means to achieve this. In contrast, the API3 vision foresees that it’s not a centralized entity, but a decentralized conglomerate that can reach the scale required to solve the API connectivity problem.
The second, much less explored functionality of a DAO is being a building block for an infinitely scalable organization. When the product is one that facilitates connectivity, it’s only as good as the number of business developers that are going around (not only talking to blockchain projects, but more importantly, businesses and enterprises ), integrations that the engineers implement and the useful products that are built with these. A centralized organization cannot reach a scale that can serve all chains, all APIs, all use-cases. In that case, the inefficiencies of decentralization will be greatly outweighed by its scalability towards reaching market dominance.
Scaling DAOs
DAO scalability is often discussed in terms of gas costs. However, when it comes to human cooperation, tribe capacity and attention scarcity are limiting factors that are just as valid. Whatever you regard as the root cause, DAOs are not scalable by default. Our proposed solution is the authoritative API3 DAO acting as the highest governing body, with additional entities fractalizing outwards.
At the moment, DAOv1 is scaled in the form of operation teams. For example, the core technical team makes a budget proposal to the DAO, and receives the funds to a multisig controlled by 3 senior members. This multisig is used to fund the developers and the technical services that the DAO receives, and the outcomes are reported to the public in the form of monthly development updates. It can be said that the core technical team is already a mini-DAO in that it receives proposals (or invoices) from external parties, negotiates on prices/salaries and accepts/denies them without having to escalate these to DAOv1.
For the same reasons API3 is governed by a DAO, a subsidiary whose budget and influence exceed a certain level should be governed by a DAO of its own (which we will refer to as a subDAO). Therefore, the organizational structure we are proposing is not of a single DAO, but multiple DAOs of varying interrelations. We should note that existing DAOs can also be added to this ecosystem through a token swap or other game theoretic tools.
What is a subDAO good for?
We should clarify that forming an API3 core developers DAO is not the goal, nor do we see it being productive. The subDAO scheme is suitable to achieve a distinct, high-level objective, while the core technical team is more of an extension of the API3 DAO. Then, let us discuss two potentially useful types of API3 subDAOs.
API3’s objective is to natively operate on any and all smart contract platforms where there is demand for its services. There are two issues with this:
- There are a lot of smart contract platforms where there is demand for API3’s services. In fact, the majority of the smart contract platforms lack any kind of oracle service, as it is difficult for oracle solutions to scale their operations to provide full service coverage.
- It’s difficult for API3 to justify investment (in the form of funds or development resources) into an up-and-coming chain. Furthermore, due to not being native to that chain, the API3 DAO members won’t know its quirks and needs (which people are good to work with, what projects/use-cases have a future, etc.)
A subDAO that is partially composed of the natives of the target smart contract platform would solve both of these problems. The members of the subDAO could take on the business development and integration efforts, and being native to the chain, they would be much better at executing and maintaining these. In addition, a subDAO deployed at the target smart contract platform could interact with the contracts deployed on that chain directly, which would ensure the decentralized governance of the integration.
One can conceive an alternative type of subDAO that targets having API3 services adopted by a specific project. The subDAO does the necessary focused marketing and business development towards the project, scopes out the requirements, and may even implement a proof of concept fork that runs on API3 services. Once the end goal is achieved, the subDAO lives on to maintain the integration, all the while capturing some of the value being generated.
subDAO incentive alignment
Since the authoritative DAO and the subDAOs won’t necessarily be programmatically integrated, their incentives need to be aligned in a game theoretic manner for them to cooperate. Here, the burden falls mostly on the subDAO, i.e., the subDAO must convince the API3 DAO to fund its operations and support it with its products, know-how and network of business partners (e.g., API providers). In other words, the subDAO should lobby for its API3 DAO proposals to pass.
Here, what we refer to as the API3 DAO are actually the API3 stakers, as they hold the voting power. Therefore, if a subDAO needs to appease the API3 DAO, it needs to pay tribute to the stakers. For example, a fraction of the total supply of the subDAO governance token can be airdropped to API3 stakers (the related functionality is already implemented at the API3 pool contract), which would result in some of the recipients voting in favor of the subDAO (if the combined benefit at the API3 DAO and the subDAO sides appears as a net positive to them). This airdrop is also what would make the subDAO governance token to have a (non-zero) market price, as the subDAO would be useless if it’s not backed by the API3 DAO — or rather, it’d just be an obscure fork. This allows the subDAO to not have to depend on the API3 DAO fully, but also be able to finance itself using its token.
Permissionless scaling
Decentralization only provides trustlessness when it’s transparent. Similarly, decentralization only provides scalability when it’s permissionless. In a permissioned environment, innovation either gets smothered, or it breaks free and causes a schism. Therefore, permissionlessness has to be ingrained into the design, both to be able to benefit from innovation and to outgrow the competition.
Say we have a smart contract platform team that is bound by contract from publicizing usage of API3 services on their platform, and the general internal consensus (among the operation teams) is that it’s not worth working with them for this reason. On the other hand, there is an external team that are experts on an existing oracle solution that is already integrated to that platform. They propose to serve the API3 catalog by whitelabeling the existing integration, which the core technical team is not happy about because we think Airnode is the bee’s knees. Even in these circumstances where there is no permission from the target smart contract platform, the API3 teams or the whitelabeled solution, the aforementioned external team of experts can launch a subDAO, airdrop tokens to API3 DAO stakers, make their case and ask the authoritative DAO for support. Therefore, outsiders do not have to appease insiders, and scaling will not only be unlimited, it will be permissionless.
Conclusion
In previous posts we alluded to using DAOs for organizational scaling, yet we hadn’t, at that point, described the exact mechanics. In this post, we have introduced the fractalized network blueprint of subDAOs and teams, the incentive alignment mechanics, and the implications of that for API3 tokenomics as an additional staking incentive. As mentioned in the article, the model is permissionless and open to your interpretation as a potential subDAO founder/backer (or an authoritative DAO maximalist). In the next post, we will go into a long awaited topic — staking.
