Summary: DAOHaus is best cataloged as a governance operating stack built around Moloch v3 (Baal) rather than as only a DAO launcher or club frontend. Its official docs describe a layered system of contracts, subgraphs, and apps where Moloch-style governance sits above a Safe multisig treasury through Zodiac-compatible modules. The reusable mechanism is the combination of tokenized membership, ragequit rights, Safe-based execution, arbitrary proposal actions, and powerful external shaman contracts with explicit permissions. Analytically, that makes DAOHaus a useful comparison class for Safe, Aragon, Hats, and Llama because the real control surface sits in treasury wiring and extension permissions as much as in the vote itself.
What it does:
Provides a DAO framework centered on Moloch v3 governance contracts, Safe treasuries, subgraphs, and admin tooling
Represents membership through ERC-20 shares and loot rather than only through non-transferable voting records
Uses a Safe as the treasury layer, with proposal execution routed through Safe multicall and Zodiac-compatible module patterns
Supports arbitrary proposal actions, adjustable governance parameters, and custom DAO setup via summoner contracts
Lets DAOs install shaman contracts with admin, manager, or governor permissions to automate or extend DAO behavior outside the normal proposal flow
Preserves Moloch-style ragequit logic while allowing one main ragequittable treasury Safe plus optional non-ragequittable sidecar Safes
Key claims:
The official developer docs say DAOHaus is powered by the Moloch DAO framework and that Moloch v3 is a minimal yet modular governance layer, which is why it is more useful to treat as governance infrastructure than as a single app
The contracts overview says Moloch v3 sits on top of a multisig treasury and uses Gnosis Zodiac standards to interface with that treasury, making the governance/treasury seam the central design choice
The same docs highlight tokenized membership, shamans, arbitrary actions, adjustable governance parameters, and high-order summoners, which shows that DAOHaus is about modular authority surfaces rather than just basic proposal voting
The treasury docs distinguish a main ragequittable Safe from non-ragequittable sidecar Safes, which means asset location and exit rights can differ materially inside one DAO structure
The shamans docs explicitly warn that shamans can make critical changes outside the proposal process and can hold admin, manager, or governor permissions, making them the clearest hidden control point in the stack
The Baal README says the system continues work from Moloch, Minion, Compound, and Safe frameworks and documents arbitrary action proposals, ERC-20 shares and loot, flexible voting periods, gasless approvals, and ordered proposal processing rooted in ragequit economics
Because DAOHaus combines Safe custody, Moloch consensus games, tokenized membership, and extension contracts, the key analytical question is where authority actually accumulates: in member votes, Safe signer/module structure, shaman permissions, treasury sidecars, or summoner-defined setup defaults
Whitepaper: No standalone DAOHaus whitepaper surfaced in this pass. The strongest primary materials were the official developer docs, contract pages, and the Baal repository README; see ../whitepapers/daohaus-primary-sources-2026-05-09.md.