API3 Operations
Previously, we have introduced the API3 Builder Terminology as a framework for the decentralized governance of the project roadmap. As we are gearing up for DAO-governance, we are faced with the need for another framework, this time to structure our operations.
Since a DAO’s main means of governance is the allocation of financial resources, from a decentralized governance perspective, an operation can most generally be defined as a recurring expense. Some practical examples for these are:
- Personnel costs of long-term technical and business developers, analysts, etc.
- API provider compensation and the related payment processing costs
- Gas costs for dAPIs
Although operational expenses can be covered by individual grants, doing so would incur a significant overhead, as each compensation event would have to be considered separately by the governing parties. Therefore, it’s more convenient to formalize recurring expenses as a specific operation so that a governing party may choose to vote to cover it or not in more general terms.
The relation between building projects and operations
The cost-centric definition of operations may make it seem like that they don’t have a specific end, and thus they can’t work towards a goal. However, operations can indeed work towards accomplishing the completion of building projects.
Let us consider an example operation: Core development. The core development operation employs developers that work on core API3 development, most prominently including Airnode (node&protocol) and dAPI contract development. These developers are part-time or full-time employees of the DAO that work on the undertakings that build towards Airnode/dAPI-related monoliths (refer to this post if you’re not familiar with the terminology). However, this doesn’t mean that monoliths related to core development will only be built by developers employed by the core development operation. For example, the budget of an undertaking for a monolith related to core development may look like this:
- Developer A (employed by the core development operation)
- Developer B (employed by the core development operation)
- Developer C (Junior, $X)
- Developer D (Senior, $Y)
Here, Developers A and B are employed by the core development operation, and are likely working on multiple undertakings across multiple monoliths. On the other hand, Developers C and D are more freelance-types, and are only working on this specific undertaking on a contract basis.
A framework for DAO employment
The majority of the API3 DAO operations will be continuous, which means that when the DAO finds qualified people to execute them, it would rather keep them. However, it is difficult to reconcile this with the traditional grant-based approach of DAOs. Here, the operations framework we propose provides an alternative.
Let us take the business development operation of reaching out to API providers to have them host Airnodes as an example. Ideally, instead of giving out grants that require the recipients to have N API providers host Airnodes, we would rather have a team of business developers that work on this continually. Moreover, we would probably want multiple of these teams to provide further decentralization and roster robustness (i.e., if a team leaves, the API3 DAO is alright). Then, the DAO may have the following operations:
API reach out team 1
- Business developer A
- Business developer B
API reach out team 2
- Business developer C
Note that this scheme also allows the DAO to employ individuals, as long as this doesn’t become a bottleneck on scaling — we don’t want the DAO to have to vote on if it will compensate each person. Similarly to the earlier example where the core developers were contributing to multiple undertakings, business developers A, B and C will likely contribute to multiple operations, and the DAO will prefer to compensate them based on the nature of this versatile contribution.
Conclusion
The API3 DAO will have recurring expenses, and it’s not ideal to approach these independently. Instead, we propose the concept of an operation, which corresponds to meaningful groups of recurring expenses. The API3 DAO will periodically vote on compensating each operation, and as a result, will maintain full authority over the allocation of resources.
With the introduction of the API3 Builder Terminology and API3 Operations in this post, we believe that we have the necessary framework for the decentralized governance of all current API3 activity. We made sure that the governance framework is minimal as possible, while covering all of our immediate needs. As API3 evolves from an infrastructure-building to a service-providing role, these needs may change. By then, we will have the decentralized governance scheme in place to be able to enact the required updates.
