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.


ZDAO is designed with the following five principles:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.


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 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.


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 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'.

Neurons can really be designed to achieve any type of use-case (putting the 'A' back in DAO).


ZDAO comes with a built-in Treasury module that custodies and secures assets onchain, similar to any standard EVM-compatible wallet or multi-sig. For enhanced security purposes and account organization, a ZDAO can have multiple Treasury contracts, enabling account abstraction and asset organization, similar to different accounts at a financial institution. In order to become part of a DAO's Treasury, tokens can simply be transferred to any associated Treasury contract address.

In addition to ZDAO's built-in Treasury system, DAOs can be associated to an existing multi-sig contract, such as a Gnosis SAFE. This provides DAOs flexibility and enables progressive decentralization over time. This is particularly useful as the ZDAO protocol matures, smart contracts are hardened and more total assets are secured, in order to reduce security risks.


DAOs are limited currently by a poor user experience and unsustainable cost structure. Imagine if you needed to pay every time you wanted to watch a YouTube video, send a message or listen to a song on Spotify. This is the case with DAOs and necessary to solve before they can scale.

It is generally the case in blockchain that improvements in UX and reductions in cost come at the expense of security and decentralization. In the case of DAOs, removing decentralization eliminates the primary benefit of using a DAO over a centralized entity, removing the possibility of architectural short-cuts.

ZDAO maintains decentralization while dramatically improving user experience and scalability. It is designed for internet-scale, enabling the real possibility of decentralized public goods, global coordination and future governance.

An onchain snapshot is updated when Voting Tokens are staked into a vault contract. In exchange for staking, token holders are issued a corresponding amount of Voting Power, in the form of a soulbound (non-transferrable) token. In order to incentivize staking, protocol rewards are combined into a single vault contract, enabling staking incentives to flow back to those who participate in protocol governance.

Scale is achieved by preparing votes off-chain using a cryptographically secure signed message pattern performed by a decentralized network of Vote Indexers. Indexers perform the function of handling and aggregating votes, which are then submitted in the form of an onchain transaction to a secure L2, in the form of a Merkle tree root. Particularly for large-scale DAOs, using a L2 for the execution of voting against the Merkle tree dramatically reduces costs, compared to executing this logic on the L1.

Once the voting period has finalized, as determined by the logic defined inside the Voting Engine on L1, a proof is generated on L2 and then submitted to the L1 ZDAO contract. The ZDAO contract performs the necessary final verification methods prior to processing the L1 state change.