---
title: DAOhaus Dev Docs Cleanup
tags: devrel
---
# DAOhaus Dev Docs Cleanup
```
│ Overview (NEW - Refer to section 1)
│
└─── Concepts (NEW - Refer to section 2)
│ Proposals (NEW)
│ Safe & Minions (NEW)
│ Boosts (NEW)
└─── DAOhaus App (RENAMED)
│ Client Overview (EDITED, fka Code Legos/overview - Refer to section 3)
└─── Code Legos
| Transaction Lego
| Field Lego
| Contract Lego
| Form Lego
| Contexts
│ Activity Feeds
| Contract Services
| TX Polling Service
| Boosts (FUTURE)
| Summoning DAOs
| Common Utilities & Patterns
└───Tutorials (NEW)
│ How to Build a Boost (NEW - Refer to other HackMD)
| ... (FUTURE: Subgraph Queries)
└───Contributing Guidelines (RENAMED, fka JS Code Review)
│ Overview
│ Code Review Process
│ Javascript Rules
│ Async Rules
│ Caching Rules
│ React/Structure
│ React/Components
│ React/useEffect
| React/JSX
| Component Layout
```
# 1. Overview
Today, the DAOhaus app empowers any community to summon a Moloch DAO and coordinate with a human-friendly interface.
The three following components enable the DAOhaus app to function smoothly.
* **Smart Contracts (Moloch)**: DAOhaus uses Moloch DAO's smart contracts to facilitate on-chain DAO functionalities (e.g. permissioned membership via loot/share, proposals, treasury & minions, ragequit, etc.)
* **Subgraphs:** DAOhaus uses subgraphs from The Graph to ensure that on-chain data is indexed and available for querying.
* **Client:** The DAOhaus app is built on React.
When a user interacts with DAOhaus, he/she is using a client that references on-chain data from Subgraphs, as well as on-chain functionality from Moloch smart contracts.
Today, DAOhaus is largely open source on Github. There are some services (e.g. data middleware) that are managed by the DAOhaus core team. We are currently exploring more open source and decentralized alternatives.
## Smart Contracts (Moloch, Baal) (current: [/docs/devs](https://daohaus.club/docs/devs))
As a no-code platform for Moloch DAOs, the DAOhaus app interfaces with Moloch contracts for all on-chain actions and features.
Currently, the DAOhaus app supports Moloch v2 DAOs using the following contracts:
* Moloch v2.1 (see repository [here](https://github.com/HausDAO/Molochv2.1)): All Moloch v2 functions with multi-summoner capabilities, plus register function for metadata & EIP-1167 proxy pattern to reduce gas costs during summoning
* Moloch 2.5 (see repository [here](https://github.com/HausDAO/Moloch2.5)): All Moloch v2.1 functions with Shamans support
* Minion (see repository [here](https://github.com/HausDAO/MinionSummonerV2)): All Minion functions with the ability for the DAO to intract with smart contracts while keeping funds safe in a Gnosis Safe
Moving forward, the DAOhaus app will be using Moloch v3 (Baal). For more information on Moloch V3 (Baal), refer to the [official Baal documentation here ](https://baal-docs.vercel.app/)
## Subgraphs (current: [/docs/devs/subgraphs](https://daohaus.club/docs/devs/subgraphs))
> Note: Nothing much to change here. Pretty much copied the entire thing over
### What is TheGraph?
The Graph is an indexing protocol that incentivizes and coordinates indexing of public blockchain data. The Graph provides queryable data using GraphQL for your API to plug into. By indexing Moloch contracts with The Graph any user with an access to TheGraph can find data on all compatible DAOs instantly.
### Subgraphs
The primary DAOhaus Subgraph tracks the primary entities of DAOs: members, proposals, votes, and tokens.
#### DAOhaus Subgraph Explorers
- [Mainnet](https://thegraph.com/hosted-service/subgraph/odyssy-automaton/daohaus)
- [Kovan](https://thegraph.com/hosted-service/subgraph/odyssy-automaton/daohaus-kovan)
- [Rinkeby](https://thegraph.com/hosted-service/subgraph/odyssy-automaton/daohaus-rinkeby)
- [Gnosis Chain](https://thegraph.com/hosted-service/subgraph/odyssy-automaton/daohaus-xdai)
- [Polygon](https://thegraph.com/hosted-service/subgraph/odyssy-automaton/daohaus-matic)
- [Optimism](https://thegraph.com/hosted-service/subgraph/odyssy-automaton/daohaus-optimism)
- [Arbitrum](https://thegraph.com/hosted-service/subgraph/odyssy-automaton/daohaus-arbitrum)
- [Celo](https://thegraph.com/hosted-service/subgraph/odyssy-automaton/daohaus-celo)
#### Stats Subgraph Explorers
The DAOhaus Stats Subgraph provides aggregated statistics and metrics for users and communities across the platform.
- [Mainnet](https://thegraph.com/hosted-service/subgraph/odyssy-automaton/daohaus-stats)
- [Kovan](https://thegraph.com/hosted-service/subgraph/odyssy-automaton/daohaus-stats-kovan)
- [Rinkeby](https://thegraph.com/hosted-service/subgraph/odyssy-automaton/daohaus-stats-rinkeby)
- [Gnosis Chain](https://thegraph.com/hosted-service/subgraph/odyssy-automaton/daohaus-stats-xdai)
- [Polygon](https://thegraph.com/hosted-service/subgraph/odyssy-automaton/daohaus-stats-matic)
- [Optimism](https://thegraph.com/hosted-service/subgraph/odyssy-automaton/daohaus-stats-optimism)
- [Arbitrum](https://thegraph.com/hosted-service/subgraph/odyssy-automaton/daohaus-stats-arbitrum)
- [Celo](https://thegraph.com/hosted-service/subgraph/odyssy-automaton/daohaus-stats-celo)
#### Boosts Subgraph Explorers
The DAOhaus Boosts Subgraph provides aggregated statistics and metrics for boosts across the platform.
- [Mainnet](https://thegraph.com/hosted-service/subgraph/odyssy-automaton/daohaus-boosts)
- [Kovan](https://thegraph.com/hosted-service/subgraph/odyssy-automaton/daohaus-boosts-kovan)
- [Rinkeby](https://thegraph.com/hosted-service/subgraph/odyssy-automaton/daohaus-boosts-rinkeby)
- [Gnosis Chain](https://thegraph.com/hosted-service/subgraph/odyssy-automaton/daohaus-boosts-xdai)
- [Polygon](https://thegraph.com/hosted-service/subgraph/odyssy-automaton/daohaus-boosts-matic)
- [Optimism](https://thegraph.com/hosted-service/subgraph/odyssy-automaton/daohaus-boosts-optimism)
- [Arbitrum](https://thegraph.com/hosted-service/subgraph/odyssy-automaton/daohaus-boosts-arbitrum)
- [Celo](https://thegraph.com/hosted-service/subgraph/odyssy-automaton/daohaus-boosts-celo)
## Client (current: [docs/devs/legos/overview](https://daohaus.club/docs/devs/legos/overview))
The DAOhaus frontend is built using React. For greater ease of development, we will be releasing component libraries shortly.
For more information on the DAOhaus Client, please refer to [Working with the DAOhaus app]()
# 2. Concepts
As a no-code platform for Moloch DAOs, most of DAOhaus' concepts and functionality originate from the functionalities of a Moloch DAO. If you are new to Moloch DAOs, refer to this [Mirror article](https://daohaus.mirror.xyz/U_JQtheSzdpRFqQwf9Ow3LgLNG0WMZ6ibAyrjWDu_fc) for an introduction to Moloch DAOs.
## Proposals (current: [/docs/devs/proposals](https://daohaus.club/docs/devs/proposals))
> If you are new to Proposals in Moloch DAOs, refer to [Introduction to Proposals](https://daohaus.club/docs/proposals).
Proposals are the mechanism which all Moloch DAOs use to take any action, from issuing shares to members to sending funds to addresses or interacting with smart contracts. Before a proposal can be executed, it has to go through the 6 lifecycle stages: Submission, Sponsorship, Voting Period, Grace Period, Processing, Execution

**Default Proposal Types**
Every DAO comes with default proposal types which enable the core functions of Moloch DAOs such as Membership, Funding, GuildKick, etc. These proposal types come with field inputs that are necessary for their respective functions.
For instance, a **New Member Proposal** is a proposal that allows new members to join a DAO by requesting shares and providing tribute. This Proposal Type contains the default fields ("Title", "Description" & "Link") as well as custom fields like "Shares Requested" and "Token Tribute".

Another example is **Funding Proposal** that allows members to request funds from the DAO. Apart from default fields ("Title", "Description" & "Link"), the Proposal has fields such as "Applicant" and "Payment Requested".

==Follow with a link to a complete list of the default proposals, or cover them all here==
**Custom Proposals (Boosts)**
DAOHaus is designed to be extended by external developers. By working with our proposal "code legos" developers can create "Boosts" to extend DAOhaus functionality. A Boost can include custom fields, inputs and layouts to build new proposal types. ==[Building Boosts on the DAOhaus platform]()==
## Treasury, Minions & Safes
**Treasury** (current: [docs/devs/bank](https://daohaus.club/docs/devs/bank))
A Moloch DAO is able to hold ERC-20 and ERC-721 assets. Members of a DAO can withdraw their their proportional ownership of the treasury using the ragequit feature.
> If you are new to Treasury in Moloch DAOs, refer to [Treasury Introduction](https://daohaus.club/docs/users/bank).
The DAOhaus app displays token balances and prices from the DAO treasury. ERC-20 token prices are fetched from Coingecko's price APIs, whereas the token icons are fetched from TrustWallet's repository . ==Anything else to add?==
**Minions**
A minion is a smart contract that enables the DAO to make arbitrary calls to external smart contracts. A minion is also able to hold ERC-20 and ERC-721 tokens within the internal balance, but these funds are not ragequittable by DAO members.
When a Minion Proposal is submitted, voted on and passed, the Minion will execute the instructions contained in the Minion Proposal, enabling trustless voting and execution.
> If you are new to Minions in Moloch DAOs, refer to [Minions Introduction](https://daohaus.club/docs/users/minion).
==Anything to add here?==
**Safe Minions**
DAOhaus has integrated with the Gnosis Zodiac framework to create the Safe Minion, where a DAO can store funds in a Gnosis Safe but use the Minion to control the Safe through proposals.
The Minion inherits the `Module.sol` contract from the Zodiac library. When a Minion Propsal is passed and executed, the Minion uses the Module’s `exec` function to execute arbitrary external calls on behalf of the Safe.
==We link to the minion page, so maybe put this Safe Minion detail there?==
## Boosts (current: [docs/devs/boosts](https://daohaus.club/docs/devs/boosts))
Boosts are functionality added by developers to expand functionality beyond the default.
> If you are new to Boosts, please refer to the [Boosts 101](https://daohaus.club/docs/users/boosts/boosts)
The most common types of Boost are custom proposals forms. Custom field inputs, form layouts and transaction payloads introduce added functionalities to Moloch DAOs. These Boosts can interact with external smart contracts (via Minions) or off-chain APIs, allowing for a wide range of use cases to be built.
Developers are able to publish these Boosts on the Boosts Marketplace for DAOs to install and access these functionality. Once a Boost is installed, the DAO is able to create, vote and execute the custom proposal based on the developer's customizations.
# 3. DAOhaus App / Client Overview
Built on React, the DAOhaus app uses **Code Legos** to create all its components and functionalities. Written in Javascript, these code legos are packets of static objects that contain instructions for the app to render UI or make calls to external smart contracts.
Here are some examples of Code Legos and their purposes:
1. Field Legos: Instructs the app to render fields where they are needed
2. Form Legos: Instructs the app to render forms (i.e. collection of fields) for proposals
3. Transaction Legos: Provides the transaction schema & prepares the arguments for external smart contract calls
4. Contract Legos: Provides the contract addresses and ABIs required for external smart contract calls.
These code legos work together to create UIs and interfaces such as Proposal Forms, Form fields and Contract interactions. We use Code Legos to ensure that Boost development is as easy as assembling the appropriate Legos from existing components to fit your use case.
For more information about each type of Code Lego, refer to their individual pages.
## Code Legos in Action
**Rendering UI**
For instance, to render a Funding Proposal Form on the DAOhaus app, we will need to create a **Form Lego** which contains the UI (i.e. fields) functionalities of a Proposal. This Form UI can be further broken down into **Field Legos** for each field such as Payment Requested, etc.

**Making External Contract Calls**
For illustration, let's take the case of the Disperse Proposal (i.e. using disperse.app's contract to distribute tokens to a set of addresses).
When a Disperse proposal has been voted on, the app will need to execute calls with the Disperse contract. The app will get the transaction schema from **Transaction Legos** and prepare the transaction arguments following the schema. Next, the app will make the smart contract call to the contract address in the **Contract Lego**.

## Why Code Legos
- Speed up and simplify the flow of boost development.
- Drastically reduce the amount of code the application needs to store.
- Create building blocks that are composable with others.
- Make the app more interopable with potential backend architecture (ex. DAOhaus Marketplace, DAOhaus API, Boost APIs).
- Remove the need for community developers to alter the core application architecture.
- Maintain consistent patterns and types across the app that can be easily tested and maintained.
- Better tools for DAO devs so they can create better tools for DAO communities.
---
# Appendix: All these can go into the individual lego pages
**3 Entities Boost Developers should concern themselves with**:
**1 Contract Legos** - contracts.js
* Relatively Simple
* Ties ABI to some sort of object
* tells us where the contract address lives "local" or "fetch"
* contractAddress: where in the application it lives.
* dot notation
* Sometimes we want to find it in chain.js
**2 Form Legos** - forms.js > classics.js (forms holds indexes, classics holds metadata (probably others like classics.js))
* src/data/formLegos/
**3 Transaction Legos** - molochTX.js
* src/data/txLegos/
* a way of describing an ethereum transaction in static data
* Looking through the form or the application for certain values
* It's like a query, but we're querying the application, not some server
* Sort of the opposite of the ABI
* ABI says what it needs, this says what ABI is getting
* Lifecycle methods
* Actions we can propose when the proposal passes
* What poll we're using to update the UI (e.g. subgraph)
* Display error messages etc