Guizhou by Jon Juarez (source)

API3 Builder Terminology

The existing general DAO terminology is extremely immature, which results in DAOs coming up with their own according to their needs (see the MetaCartel whitepaper for example). After facing this need in practice, we realized that we will also have to come up with a terminology to describe the activities of the API3 DAO.

API3 has two main areas of activities:

1. Building of the infrastructure that is needed to provide decentralized API services (e.g., design and technical development)
2. Continuous operations that enable decentralized API services and their monetization (e.g., DevOps and business development)

At this stage, the majority of the API3 activities are focused on building. While working on these projects and preparing the necessary framework for the decentralized governance of them, we have faced the following problems:

1. Traditional project management terminology depends on common words (project, client, customer, manager, etc.), which prevents us from being specific with our language and is likely to result in miscommunication.
2. DAOs tend to manage their projects at the grant proposal-level. This is too low-level for API3, which has a concrete long-term vision, and short-term work has to be planned with this long-term vision in mind.
3. Teams (especially external ones) working on a project require a contact-person that can represent the DAO, join calls and provide feedback during the project’s lifetime. This already happens in practice, and thus should be formalized.
4. API3 needs a way to define a roadmap and signal progress. The traditional sequential roadmap on a timeline is not appropriate because there is no central authority that can decide on the roadmap, in what order the steps will be taken and how much resource will be allocated to each of them.

To address these issues, we came up with a minimal terminology that the builders and voters can use to communicate both short and long-term goals accurately. Note that this is meant to be used for building projects with a definitive end, and is not suitable for continuous operations.

The Monolith and the Ape Men 2001 A Space Odyssey, by Hal Hefner (source)

A monolith is a grand project that is a fundamental piece of the greater API3 vision. While not following a particular sequence, monoliths form the general roadmap of the project when considered together. Typically, a monolith is large enough that covering it with a single grant is not appropriate. However, it also loses its gestalt when broken down into its elements, which is why it’s a useful concept. An example monolith is the dAPI insurance service, which includes many facets such as the development of insurance policies, smart contracts and the pricing scheme.

Illustration of how the Great Pyramid of Giza is speculated to have been built.

The initial monoliths will be derived from the whitepaper, and the DAO will need to ratify the following monoliths. Note that ratifying a monolith does not mean that it gets allocated any resources. Resource allocation is done through the DAO accepting bids on undertakings, which can be seen as a call for grant proposals. Each undertaking will have to work towards one of the ongoing monoliths. This allows for a higher-level governance; for example, a token holder may decide that a particular monolith will be especially fruitful, and prioritizes bids on undertakings that work towards that monolith while voting.

Michelangelo Showing Lorenzo il Magnifico the Head of a Faun, fresco by Ottavio Vannini at Palazzo Pitti, Florence (source). Lorenzo de’ Medici was possibly the most famous patron of arts in history.

Each monolith has a patron, a DAO member who has a good understanding of why a monolith is being built and what steps are needed for completion. The patron is often the person who drafted and proposed the monolith, and may even be a part of the undertaking team. Just as ratifying a monolith does not automatically allocate resources to it, being the patron of the monolith does not provide any hard authority. Instead, the patron can be thought of as a high-level secretary.

© Goodluz

It is the DAO overseers’ responsibility to estimate the completion rate of the monoliths by reviewing the status of the undertakings and consulting with the patrons. Furthermore, they will identify what additional undertakings need to be fulfilled for the completion of a monolith, so that the DAO can make calls for bids on them. While patrons are project-specific, overseers don’t have to be.

Patrons and overseers are supposed to act as the representatives of the DAO, and if their performance is not satisfactory, the DAO can hold a vote to replace them. Similarly, the DAO can vote to decommission a monolith or replace it with another. The ultimate authority lies within the DAO in these matters, as it can enforce its will by withholding resources from all related undertakings. Therefore, the concepts proposed here do not undermine the decentralization of governance, but simply provide it with an operational framework.

Conclusion

We believe that the DAO having a mutual and concrete vision, and well-designed conceptual hierarchies to realize that is critical for effective decentralization of governance. In this post, we introduced a minimal terminology that implicitly models how API3 building projects will be managed and governed over by the API3 DAO. Detailed information about how this terminology will be used in practice will be provided in the API3 docs in the form of templates and examples.