`Please keep in mind that this is an early and incomplete draft that is likely to be changed significantly based on the feedback received. It’s published today simply to give an idea of the direction we’re thinking in and act as a starting point for discussion. The Dai Foundation intends to leave as many decisions as possible to the Maker community to decide, i.e., as long as this is compatible with the Foundation’s mandate.
20210727: Changed name of “Allocation Process administrator” to “Allocation Manager” and specified the Content Production Core Unit holds this role according to its mandate.`
Managing centralized assets in a decentralized organization is a challenging task. Ensuring that the right contributors can access the right assets, therefore, requires an asset allocation process.
For example, the makerdao.com domain is seen by many as the official Maker DAO domain that is the primary gateway for new potential users, partners, and ecosystem participants to be introduced to the protocol and the DAO.
This begs the question: who takes care of the content on "the Maker homepage" in a decentralized environment? How do we decide who gets to control the website if there are multiple candidates? What is the role of the DAI Foundation, which is created to hold legal ownership over these assets, but not their management?
Similar considerations can be made about official GitHub organizations, Twitter accounts, e-mail addresses, and so on.
In the following sections, we describe a possible structure to think about these and other centralized assets and a process to allocate these assets to ecosystem participants.
This document is a draft version, mostly meant as a starting point for discussion. The draft isn't necessarily complete, and additional details may need to be defined. The Dai Foundation intends to leave as many decisions as possible to the Maker community to decide (i.e., everywhere where this is compatible with its mandate.)
A large part of the structure that needs to be set up is the documentation of the available assets, their allocation process, and whom they have been allocated to. We start by outlining a possible structure for this documentation.
The Asset Register is an overview of all MakerDAO assets, detailing their asset class, asset allocation policy and asset instances.
Assets that share similar qualities are grouped into classes. A class has the following properties:
- Name: the name of the asset class such as "web2 domain", "email address," or "social media account."
- Parent / Child Classes : many of these assets are hierarchical by nature. For example, web2 domains can be split up into multiple subdomains, and email addresses belong to a specific domain or subdomain. This hierarchy is documented by defining the potential parent and child classes of every asset class.
- Usage Restrictions : almost every asset class will have certain restrictions as to which content is allowed or how the asset can be used. For example, a web2 domain should not be used to host illegal content; email addresses cannot be used to run spamming operations, and so on.
The Usage Restrictions are defined by the Dai Foundation and define the playing field within which the content managers are free to use the assets. These restrictions are meant to be the minimal possible set to cover legal and potential security concerns. They are not meant to dictate the content itself or how it is structured.
- Delegation Method : on a technical level, it is necessary to know how the asset ownership can and will be delegated. A web2 domain and its subclasses are typically delegated by configuring its DNS records. A Github Organization is delegated to its content manager by configuring the proper permissions, and so on.
- Technical Delegation Manager : who will have the permissions and be responsible for configuring the delegation of the asset on a technical level, for example, set the necessary DNS records.
- Allocation Administrator : the allocation administrator is a community individual or group, appointed and removed through the governance process, responsible for enacting the Allocation Policy.
An asset has a policy that specifies how it can be allocated. This policy is defined by the Allocation Administrator in collaboration with the Community.
An Asset Instance denotes a specific instance of an asset class. An Asset Instance has the following properties:
- Asset Class: reference to the aforementioned asset class that this instance belongs to.
- Name / Identifier / Location (URL): a short text that identifies the asset instance. Depending on the asset class, this may be a name, URL, etc.
- Content Manager: core unit, group or individual to whom the usage rights are assigned.
- Delegation Target: This configuration value needs to be applied to give the content manager control over the asset's content. For example, if the asset is a domain name, the delegation target could be the IP address of the webserver that hosts the content.
- Technical Content Platform Manager : the individual or group responsible for managing the content platform. Sometimes this is a cloud service provider or a tech ops core unit.
- Allocation Status : Unavailable / Available / Requested / Pre-approved / Approved / Challenged.
Legal Owner (Dai Foundation)
The Legal Owner is the legal entity that has the legal rights to, and holds, the assets. In this context, the legal owner is the Dai Foundation.
The Legal Owner pays for the ownership maintenance of holding the assets. The Legal Owner also defines the asset classes and usage restrictions.
The Content Manager is a Core Unit, group or individual to whom the usage rights are assigned for a particular asset instance (i.e., the asset is allocated to.)
The Content Manager is responsible for publishing and managing the content, information, or data on the content platform.
The Allocation Manager is a Core Unit, group or individual appointed by Maker Governance. The Allocation Manager's job is to define and ratify the Asset Allocation Policies for the different asset classes and administer the process of allocating the Asset Instances of one or more Asset Classes to the Content Managers.
The Content Production Core Unit is fitting the role of Allocation Manager as its mandate includes that it shall “coordinate the management of MakerDAO’s digital properties.”
The relationship between MakerDAO, Dai Foundation and the Allocation Manager is shown in the following figure.
Technical Delegation Manager
A group or individual contracted by the Legal Owner to perform the technical work to maintain asset ownership and apply the necessary configuration to point the Asset Instance to the allocated content platform.
Technical Content Platform Manager
A group or individual contracted by the Content Manager to perform the technical work to set up and maintain the content management platform or configuration necessary to give the Content Manager access to the content management platform.
This section needs to be extended with a lot more detail. We're just giving an idea of the processes that should be defined and what they might look like on a high level.
The Legal Owner (Dai Foundation) publishes the asset classes in the asset registry. An update is provided to the Maker Community on the Maker Forum on any changes to the registry.
Maker Governance appoints an Allocation Manager to define and manage specific asset allocation policies. Candidates (i.e. a relevant Core Unit or individual) can apply to become Allocation Manager by utilizing a MIP template, specifying their intent and mandate.
The Allocation Manager proposes a MIP to define (or update) the policy through which the asset instances are allocated.
Ideally, once ratified by Maker governance, the policy gives the Allocation Manager enough leeway to assign the necessary assets quickly enough for the content managers not to get blocked. These allocations may then later be confirmed or contested through a vote.
A Maker DAO contributor or Core Unit can utilize an asset using the Asset Allocation Policy as ratified by Maker Governance.
If the Allocation Manager accepts the application, the asset instance is added to the registry, configured, and thus allocated to the content manager by the Technical Delegation Manager.
A Core Unit, group or individual can challenge an Asset Instance by submitting a Challenge claim to the Allocation Manager, using a template. The Allocation Manager processes the claim as defined in the Allocation Policy.
See this spreadsheet for an example Asset Registry with some Asset Classes and Instances.