Q Governance SDK

These are the basic contracts of the GDK, a system with which you can build your own DAO.

Overview

You can use the Q GDK to set up your DAO in a simple and quick fashion. As already battle tested for the governance of the Q blockchain itself, you can set up your organization around a community, set dedicated roles and responsibilities and define the rules that govern your DAO.

GDK Purpose

Simply put, GDK allows you to create a one-click DAO in which you can create your tokens, voting rules, contract infrastructure, etc.

The GDK will give you the ability to organize any Governance over the DAO as you want, distribute responsibilities among Expert Panels (there can be zero or as many as you wish), release your tokens, both ERC20 and ERC721, have voting in which those tokens are considered voting rights, and much more.

With this system, you will have options such as:

• Set up governance with a Permission Manager
• Deploy your own ERC20 or/and ERC721 tokens
• Deploy Expert Panels responsible for specific areas (DeFi, Bridge, Incentives, etc.)
• Manage your own contracts through the DAO Registry and much more.

Architecture

In this section, we will look at the features of the GDK core and how all of the above has been achieved.

For this journey, you should remember the following:

All contracts in the system are resources.

Over each resource you can perform actions.

We will encounter this concept many times during our review of contracts.

How it works

In this section, we will discuss key aspects of GDK, its successes and its potential now and in the future.

The starting point

It all starts with the MasterContractsRegistry and MasterAccessManagement contracts. These contracts help us keep the DAO building contracts in one place.

These are the accessory contracts.

• MasterDAOFactory.
• MasterDAORegistry.

The MasterDAORegistry contract stores all the building blocks (contract implementations) of the DAO.

Basically, during the preparation (the initial deployment of GDK contracts), all contracts used in the creation of the DAO are deployed and stored in the Master DAO Registry.

And MasterDAOFactory uses these blocks to deploy the entire DAO simultaneously.

In the initial deployment phase, you will have contracts such as:

1. A Contract Registry through which you can manage your own DAO contracts.
   • Contracts: DAORegistry.
2. Permission Manager, the heart of the DAO, through which you will set up your own roles for the DAO (who can vote, mine, burn tokens, etc.).
   • Contracts: PermissionManager
3. Vault is a contract used by voting contracts to lock the user's deposited tokens for the voting period.
   • Contracts: DAOVault
4. Parameter and Member Storage, where the parameters and members of a particular panel are stored.
   • Contracts: DAOMemberStorage and DAOParameterStorage.
5. Token Factory, where you can deploy your own ERC20 and/or ERC721 tokens.
   • Contracts: TokenFactory and TokenRegistry.
6. Voting Factory, with which you can deploy voting contracts, where the voting token can be ERC20 or Native Q, or ERC721.
   • Contracts: VotingFactory and Registry.

Token and voting implementations are registered during DAO deployment.

When any contract is deployed through the factory, it is registered in the corresponding registry contract(i.e., if a new token is deployed through the Token Factory contract, it will be registered in the TokenRegistry contract); also, by default, only the BeaconProxy contract is deployed, which looks at implementations in the DAO main registry contracts.

Usage

To deploy the whole system, you could run the following command:

npx hardhat migrate --network <network>

Where <network> is the network name you want to deploy the contracts

To learn more about the migrate command, please refer to @dlsl/hardhat-migrate documentation

Also, you could see the integrations tests in the Q TS GDK SDK repository for interaction with the GDK contracts.

Thanks for creating a DAO with Q!