zDAO Architecture
zDAO Protocol Architecture
DAO/
A DAO requires a valid name, Token and Omega Token to be instantiated at genesis. Generating a new DAO in Zero requires three parameters:
- DAOName: a string for the DAO's name
- DAOToken: a Token that represents economic value within the DAO
- omegaToken: a Token that represents voting weight within the DAO
- AttentionContract (optional): an AttentionContract that determines the visibility and rank of Choices within the DAO
Unlike Exchange and Dynamic Tokens, DAO Tokens have a fixed supply. DAOs can be linked to individual Networks and Tokens in one-to-one, one-to-many, and many-to-many relationships. Linking occurs when a Network's associated ZNS Registry, Registry Entry, and/or Exchange Token is linked to an individual DAO's Ethereum Address.
Linking tokens and smart contracts in this way provide a valuable path to the fully decentralized governance and operation of a company or organization. For instance, a Network DAO could be funded by using the proceeds generated from an Exchange Token's Dynamic Reserve. Similar to Zero and Infinity, this structure would enable a Network DAO to have reserve tokens automatically transferred to a DAO’s ethereum contract, making the allocation of proceeds subject to a DAO's internal governance structure.
DAO Token/
A DAO Token is an ERC20-compatible Token based on OpenZepplin’s ERC20 library that is associated with a DAO and serves in its core functionality.
A DAO Token is initialized with five parameters:
- name: a string of the token’s name (e.g. InfinityDAO)
- symbol: a string representing the token’s abbreviation (e.g. INI)
- decimals: a uint8 representing the total decimals permitted (e.g. 18)
- cap: a uint256 representing the maximum number of tokens allowed
- transactions: a uint256 store of historical transactions
DAO Tokens are controlled by the DAO Mind. A DAO Token's parameters can be updated by approved Neurons (as outlined in Section 4.3.8 Neuron). Neurons are autonomous code that can be assigned to manage DAO choice making and code execution.
Omega Token/
An Omega Token (Ω Token) is used to represent ‘voting weight’ in a DAO. Voting weight in this context refers to the total choice making weight ascribed to an individual Omega Token that is relative to a DAO’s individual governance structure. Omega Tokens enable Members to have a non-economically motivated mechanism to determine choice making authority within a DAO. Unlike a DAO Token, Omega Tokens are non-transferable, meaning they cannot be purchased, sold, or transferred to other addresses by DAO Members.
DAOs have discretion in how they utilize Omega. A basic implementation could be to have a fixed supply of Omega and to pass (or fail) a Choice (as outlined in Section 4.3.7. Choice) based on the majority of Omega votes. For some or all Choices in a DAO, an ‘absolute’ majority of Omega might be required for a pass – i.e., greater than 50% of the entire Omega supply – while for others, a ‘relative’ majority might be required, which would only require 51% of the voting Omega to pass within a particular time frame. In this context, a Choice could represent the allocation of a DAO’s internal resources, the issuance or Omega tokens to a Member, or the approval of new Neurons that could be assigned to autonomously manage the DAO.
As for how Omega is allocated within a DAO, there can be a variety of ways as determined by the DAO. One simple way is for a Choice to be raised to allocate a certain amount of Omega to a certain Member, and for that Choice to be voted on just as any other Choice as described above. It is also possible for DAOs to utilize more advanced algorithms to allocate Omega, such as using input from a variety of sources like Reputation (outlined in Section 4.3.10, Reputation).
A DAO is required to have a single Omega Token that is automatically generated as part of DAO instantiation. DAO’s have the optional ability to add more than one Omega Token, enabling Members to maintain different amounts of voting power for different purposes or Choice types.
Omega tokens should not be confused with an individual’s ‘Reputation’. Reputation in Zero refers to the community ascribed trustworthiness of an individual, relative to individual skills, characteristics, and observable behaviors that are defined by a DAO. Reputation is outlined in more detail in Section 4.3.10, Reputation.
DAOMind/
The DAOMind is the primary contract responsible for modulating decisions within the zDAO protocol. The DAOMind is managed by approved Neurons (outlined in Section 4.3.7, Neurons), which maintain specific 'permissions' over a DAO's actions.
A DAOMind is instantiated with a single parameter:
- DAO: the address of the corresponding DAO
DAOTokens can be:
| Neurons can be:
|
The DAOMind has seven primary permission modifiers:
- PermissionToActivateNeuron
- PermissionToDeactivateNeuron
- PermissionToMintToken
- PermissionToBurnToken
- PermissionToTransferToken
- PermissionToTransferTokenFrom
- PermissionToApproveToken
Upon activation of a Neuron, one or more PermissionTypes that determine the Neuron’s choice-making capacity are set inside DAOMind.
Choice/
A Choice in Zero is the primary mechanism for initiating a vote to perform a specific action within a DAO. A Choice can be for virtually any type of suggestion or initiative. A Choice must be initiated by a Member who is referred to as the proposer.
A Choice is a proposed voting event within a DAO, managed by the DAOMind. A Choice is initialized with five parameters:
- DAO: the corresponding DAO
- DAOToken: a DAOToken that will be utilized by the result of the Choice
- choiceType: the type of transaction being proposed, i.e., to mint, burn, transfer, or increase the supply of a DAOToken. Please note that approving a new Member is a subset of transferring DAOToken, since holding DAOToken is the criteria for being a Member of a DAO.
- status: one of three valid statuses: proposed, approved, or rejected
- Neuron: the associated Neuron and resulting code sequence that executed in the event of an accepted status.
A Choice has its own internal data structure to store ChoiceData, such as the proposer, an associated url for additional information, the status, vote count, and voter history.
Choices are passed based on a binary yes/no voting system and utilize weighted-Omega as a primary mechanism to determine if a Choice is approved or denied. If a Choice is accepted it will perform the Choice’s corresponding action automatically, as determined by the connected Neuron within the Choice. Choices by default must be executed within a timeframe that is determined universally as part of a Neuron’s interface definition.
In the event of a large DAO, such as a social network, it is easy to imagine millions of Choices being created by Members. This creates an existential problem for collective choice making: how should attention or rank be determined for new Choices? Zero enables DAO’s to choose or build their own ‘attention algorithm’, called an AttentionContract, which defines the order and method by which Choices are displayed within a particular DAO. The AttentionContract is an optional parameter that is defined during or after DAO instantiation.
Neuron/
A Neuron is an autonomous and immutable smart contract that can be assigned to control various aspects of a DAO, according to parameters set and stored in the Neuron’s struct once it is assigned by a DAOMind.
Neurons make calls to the DAOMind based on their own internal logic, and must be registered (approved) by the DAO Mind to execute certain methods (actions) on behalf of the DAO. Neurons may themselves add and remove other Neurons, enabling a DAO to effectively upgrade its own governance system recursively, without the need for a third party or intermediary. Thus, a DAO can not only manage itself according to a defined set of rules, but may evolve itself over time in an autopoietic manner.
A Neuron is instantiated with the following parameters:
- neuronName: a string of the Neuron's name
- neuronToken: a DAOToken associated with the Neuron
- votingEngine: a votingEngine to manage Choices
- permissions: an array representing the permissions defined in DAOMind
A Neuron can be programmed to run with or without spawning a Choice that DAO Members are required to vote on. Developers can easily build custom Neuron constraints as long as the Neuron’s smart contract address is approved and registered in the DAOMind.
In the event that a major technical upgrade is needed, the Mind is capable of upgrading itself by transferring the ownership of all its associated smart contracts to a new address. This transaction is non-reversible and non-transferable. Calling this method can be determined by a vote at the discretion of DAO members.
Voting Engine/
A Voting Engine defines the criteria for whether an individual Choice passes or fails. Creating a new Voting Engine requires the following two parameters:
- name: a string of the Voting Engine’s name (e.g. Absolute Majority)
- acceptanceThreshold: a uint256 representing the percentage threshold the Omega votes for a Choice must achieve in order to be accepted.
Example Voting Engines include:
- Absolute Majority Engine: Votes are counted based on the total amount of Omega that has voted in favor of a Choice, divided by the total supply of Omega token that is connected to the Neuron.
- Relative Majority Engine: Votes are counted based on the relative amount of Omega that has voted in favor of a Choice, divided by the total amount of Omega that has voted within the allotted time frame.
Neurons require a singular Voting Engine that is used to determine the acceptance criteria of Choices.
Task/
A Task is designed to represent the smallest possible unit of work that can be completed in Zero. Tasks can be thought of as a miniature contract, where work is performed in exchange for an amount of tokens. A When a new Task is initiated, tokens are sent to the Task contract, which serves as a form of escrow between the proposer (task creator) and assignee (individual doing the work).
A Task is instantiated with the following parameters:
- taskName: a string of the Task’s name.
- owner: the ethereum address of the Task creator.
- amount: the Task contract amount denominated in Infinity, ETH, or DAI.
- assigned: the ethereum address for the who the task is assigned.
- status: a string of a valid task status.
- url: a link to Zero Task url, which may include additional Task details and fields.
Tasks can be assigned one of six valid statuses:
- 1.New: No one has been assigned to the Task yet.
- 2.Accepted: The task has been accepted by a Member but not started.
- 3.In Progress: The Task has been started and is in progress.
- 4.Ready for Review: The Task is ready to be reviewed, such as with a design, feature or code review.
- 5.Paid: The Task has been paid to the assigned user.
- 6.Dispute: The Task ended in a dispute.
Tasks are a base contract and accompanying interface that can be used to create different types of Tasks with more complicated parameters and decision flows.
Last modified 1yr ago