ZDAO
ZDAO
ZDAO is a flexible and modular protocol to easily create, operate, extend and scale DAOs (Decentralized Autonomous Organizations) on EVM-compatible chains. The vision of ZDAO is to create large-scale coordination networks with millions of interoperable DAOs, which share resources, members and code modules to achieve collective objectives.
ZDAO is aimed to be powerful but also simple, enabling deep configuration or out of the box use. Individuals can create and configure a DAO with limited technical experience in a matter of minutes. DAO members can participate and coordinate DAO-based decision making without the knowledge that they are operating within a DAO. Similar to a modern App Store, developers and members can easily extend DAOs with autonomous modules called Neurons.
Principles
ZDAO is designed with the following five principles:
Simplicity: Many existing DAO systems require technical knowledge, limiting adoption from a large percentage of the public. ZDAO is designed to be simple to use, even for individuals unfamiliar with crypto and blockchain.
Maximal Decentralization: Current DAO systems tend to be highly centralized, often being managed on a SAFE with a small number of signers, who bare the ultimate responsibility for processing onchain transactions. ZDAO aims to be maximally decentralized, removing the possibility of third-party capture, censorship and the need for a separate treasury system.
Cheap and Fast: Due to high gas fees that can fluctuate unpredictably, existing onchain DAOs limit member voting and participation, which in turn decrease decentralization. ZDAO is designed to enable fast and inexpensive voting, removing friction and barriers to entry.
Actually Autonomous: Existing DAO systems rely mainly on manual operation through the use of proposals and require active member engagement. Despite the process being digital, the current management of DAOs is archaic. ZDAO is built for an autonomous future, enabling modular bits of code and AI-powered modules, which can drive the majority of decision-making on behalf of a DAO's members.
Interoperability: ZDAO is designed to be as interoperable as possible with existing DAO protocols and systems, as well as is highly interoperable with DAOs built on ZDAO. Interoperability enhances discovery, liquidity and the capacity for shared resource allocation, increasing the likelihood of large scale coordination.
ZDAO is designed to enable non-technical users to quickly launch and begin participating with DAOs. Without advanced knowledge of DAOs, individuals can configure and fine-tune their DAO and voting process.
Experience
Rather than complex governance software, ZDAO can be thought of as being closer to a group chat with a bank account. ZDAO is focused on both Dunbar scale and large-scale collaboration and decision making. Think of a group of friends allocating funds in a fantasy football league, all the way up to a large social network voting on the details of platform-wide creator royalties.
In both cases, ZDAO is being designed for mainstream adoption by optimizing for minimalism and scalability at the protocol and application level. This means targeting the long-tail of DAO use-cases—enabling resource distribution and coordination to happen efficiently between many small and large groups.
Within ZERO, every DAO points to a unique ZNA on the ZNS protocol and is interoperable with one another. Advanced users can create proposals that easily extend the default logic of the DAO to implement advanced voting schemes and Neurons—autonomous bits of code that manage rules, processes and functions within the DAO.
Voting can take place on the blockchain where the DAO is deployed, or be connected to a secure Layer 2 chain (L2), reducing the transaction costs associated with voting, while maintaining security and decentralization. Voting that takes place on an L2 is posted in the form of a proof to Ethereum mainnet, where proposals are further verified before final execution.
Membership
Membership in ZDAO is determined by holding a valid Voting Token.
Voting Tokens are used to assign Voting Weight to each DAO member during an active Proposal. Supported Voting Token standards are: ERC-20, ERC-721, ERC-1155 and ERC-6551, as well as ZNS domains, utilizing parents as namespaces.
In order to enable voting, a ZDAO must connect one or more valid Voting Tokens to the DAO's Voting Engine (outlined in more detail below). The Voting Weight is the calculation used to determine the percentage of power of an individual token and associated holder, when voting on an active Proposal in the DAO.
MIND
The MIND of a ZDAO is the central logic and access control layer of the DAO.
The MIND acronym represents the 'Main Interface for Necessary Determinism':
Main: The MIND is the main runtime of the DAO program.
Interface: The MIND defines the interface for connecting transaction senders, associated sub-systems and modules.
Necessary: The MIND is intended to be as simple as possible, only including the fundamental parts that are necessary, reducing the security footprint of the core protocol.
Determinism: The MIND enforces and promotes deterministic design, ensuring that all control flows and system states are known, considered, and tested.
The MIND is the main contract address of a specific ZDAO.
Upon registration, a ZDAO must verify itself with a valid ZNA. From the perspective of ZDAO, only a single ZNA can be verified by a single ZDAO (forming a one-to-one relationship).
From the perspective of ZNS, multiple domains can resolve to a single ZDAO by specifying the MIND contract address to the ZNS Resolver contract (forming a many-to-one-relationship).
The integration of ZDAO and ZNS enables the construction of a logical index for all ZDAOs that are registered within the ZDAO protocol, enhancing DAO discovery, search and coordination.
A MIND has three Initializable state variables:
DAO Name (Required): The DAO's official name.
Mission (Optional): A concise statement of the DAO mission.
Metadata (Optional): A link to JSON metadata of arbitrary structure and length (such as IPFS hash).
A MIND can be connected to one or more modules, including a:
Proposal Engine: Responsible for the submission of new Proposals.
Voting Engine: Responsible for the tallying and calculation of Proposal votes.
Neurons: Responsible for delegating decision making to autonomous code modules.
Treasury: Responsible for managing and securing DAO assets.
L2 Voting: Responsible for delegating and deploying a Voting Engine to a separate L2 chain.
Proposal Engine
A Proposal Engine defines the core logic for Proposals that are voted on within the DAO.
At a minimum, a Proposal includes:
A Name: The Proposal's official name.
Metadata: A link to JSON metadata of arbitrary structure and length (such as IPFS hash).
A Proposal Type: The types of Proposals that have been enabled on the DAO.
Proposal Types can vary and be extended. The default Proposal Type is a 'Token Proposal', which enables the DAO to send tokens from their treasury to an external address. Proposal Types define the required inputs and processing logic of for a successful Proposal.
A Token Proposal requires the following fields:
Token: A valid ERC-20 Token Address.
To: A valid EVM-compliant Address.
From: A valid EVM-compliant Address.
Amount: A uint256 representing the amount to be transferred upon the Proposal being accepted.
By default, a Proposal has several statues:
Warm Up: A new Proposal has been created and is in the Warm Up phase. This signals that the proposal will be open for voting soon.
Open: A Proposal is open for voting for anyone who holds valid Voting Tokens.
Passed: The proposal has been completed and accepted.
Failed: The proposal has been completed and failed.
The 'Warm Up' phase and 'Open' phase can be configured based on a specific amount of duration (blocks) that is defined within the Proposal Engine. Both the Proposal module as well as Proposal Types can be added, configured, and extended within a Proposal Engine.
Voting Engine
A Voting Engine specifies the eligible Voting Token configuration and onchain calculations used to determine the success or failure of a Proposal within the DAO.
After a Proposal is created, voting data is aggregated by votes from DAO members in the Voting Engine module. This module, in its sole discretion, determines whether or not a vote has successfully passed or failed. Once a Proposal has passed, the internal logic within the Proposal Type handles the execution of the transaction.
The default Voting Engine that ships with ZDAO requires the following configuration parameters:
Voting Method: An Absolute or Relative Majority.
Voting Threshold: The percentage of total voting powered required to pass a Proposal, relative to the Voting Method.
Quorum: The minimum number of votes (expressed as a percentage of total voting power), required in order for a Proposal to be considered valid.
Phase Duration: The standard time required for a Proposal, as outlined in the previous section.
Similar to other modules within ZDAO, a Voting Engine can be extended beyond its base configuration, or new Voting Engines can be created to support a diverse range of configurable voting schemes.
A ZDAO must have a single Voting Engine that is applied to all Proposals, which can be deployed to either the L1 the DAO is deployed on or a L2 system.
Neurons
Neurons are autonomous bits of code that can be added or removed to the DAO. Once added, Neurons are authorized to perform certain functions on the ZDAO MIND, similar to a contract owner. Adding and removing a Neuron is done with a DAO Proposal.
Neurons are designed to be as customizable as smart contracts themselves, infinitely extending the possibility of what a DAO is capable of doing. In order to promote reuse, security and upgradeability, Neurons are intended to be highly modular and focus on the single use principle. They maintain a basic interface and indexing system, which enables collective security verification, discoverability, and the reuse of Neurons between ZDAOs.
Examples of possible Neurons include:
Payroll: Enable this address to claim 'n tokens' every month in perpetuity.
Treasury Management: Stake 'n tokens' in this protocol under the scenario of 'x'.
Collective Grants: Enable 'n percent' of the DAO treasury to be eligible for community grant issuances, based on the growth scenario of 'x'.