# DoinGud Technical description

> Three *Guilds* for the Servicemen under the sky,
> Seven for the Volunteers in their halls of stone,
> Nine for Charity orgs doomed to help,
> One for the DoinGud on its decentralised throne
> In the Land of Web3 where the Crypto lie.
> One *DAO* to manage them all, One *DAO* to find them,
> One *DAO* to bring them all and in the decentralization bind them
> In the Land of Web3 where the Crypto lie.
> ***The Book of DAOs. 32:1***

DoinGud DAO is a project, whose goal is to help different charity organisations to enter the Web 3 space, digitalize and increase the reach of their funding. The main idea of this project is to handle the "main" MetaDAO governed by the DoinGud community, which manages the creation of the DAOs for different charities and voluunteers, and allows to streamline the DeFi to the good cause. This part of the article is going to tell about the architecture of the DoinGud DAO project.

## The architecture


The project consists of two main levels, that interact between each other for the propper functioning of the system:
- MetaDAO level 👑. This level is needed to do the moderation of the guilds. Also to fund the development and decide the further direction of the project. This DAO will be managed by the DoinGud community, and will serve as a `gatekeeper` for the guilds. As well, it provides a middle ground between the Guilds, through which they can possibly interact and exchange between each other. (Literally a picture of the MetaDAO below).
- Guild level 🫶. This level is needed specifically for the Charity organisations. MetaDAO manages multiple Guilds, and each Guild represents a specific organisation and is owned by the organisation representatives. Guild is atomic to all other organisations/MetaDAO and doesn't require external interaction for the propper functioning. This level serves for management of the guild's funds and donations, distributing the tokens between the impact makers and managing other possible needs of the Guild.

## DAO pattern

Both levels follow the general architectural pattern with small fluctuations. This is the pattern consists of Tokenomics and Governance parts. Tokenomics is needed to assure the propper functioning of the DAO. It consists of 2 important tokens:
- Liquidity token 💵. This token is required for the financial support of the DAO. It is tradable and transferrable, therefore it can be exchanged on the platforms like Balancer or Uniswap. It is also used for the production of the Governance token.
- Governance token 🗳️. This token is needed for the DAO governance, and works as a voting power mechanism. It is genrated by staking the liquidity token into the contract. Voting of the guild happens with the usage of the Snapshot.


Governance part on the other hand works as a managing force for the DAO. Three main components constitute this module of the DAO:
- Controller 🕹️. This is a main functionality hub of the DAO. Fees collection, creation of the reports about DAO functioning, Donations management, everything goes through it, as through the heart of an organism.
- Avatar 🏦. This contract works as a main "executioner" and the Bank of the DAO. It stores the funds, and executes the calls on behalf of the Decentralized organization.
- Governor ⚔️. This part functions as a guilds moderator. The round table of the guardians take a look at the proposals that have passed the snapshot vote, and either approve or dissaprove the results. ALl proposals can pass only after they were approved by at least 20% of the round table. Guardians on the other hand are being chosen by the community vote on the snapshot.

## Governance flow

Now let's take a look at the most important part of any DAO: the governance flow. Governance happens the same way both for the MetaDAO and for each specific guild, and consists of two votes for each proposal. The algorithm of the vote is as follows:

## Levels intrinsics

And as a dessert, let's take a deeper look at the differences between the MetaDAO and Guild governance.

### MetaDAO

We will start by the MetaDAO level. First thing that you can catch when you take a look at the overall SC construction, is that it has another module, called Vesting.

This module is needed for the initial token allocation, when the AMOR(MetaDAO liquidity token) is going to be minted. So the contributors and the creators of the DoinGud DAO will have some token rewards, which will become accessible eventually, after some time.

MetaDAO also has a very important functionality as a part of its Controller. Donate of the MetaDAO distributes the tokens not to the MetaDAO itself, but between all of the guilds, based on the weights of the guild. Those weights are called `indexes`, and can be manually created by the users of the DoinGud.

Also MetaDAO takes care of the fees which are taken for the AMOR transfers and the creation of the Guild's liquidity tokens. Those taxes are getting distributed between the Guilds and the MetaDAO itself.

### Guild

Very visible difference on the guild side is a one more token, called FXAmor. This is the reports token. The idea is following: Each charity organisation during its functioning is going to be audited/checked by someone. After the audit the person can create a guild report which will be telling about the effectivness of this specific charity organisation. Reports token is needed as a kind of both governance and funding token. It is being produced from the small fee on the guild donation which is being locked in the reports token. And the corresponding amount of the reports token is being sent back to the user that have donated.

User can later utilise this token to leave a positive or negative feedback about the report. If the report is positively accepted by the community, its creator will receive the locked tokens which were used during the report evaluation.