---
title: "DAOhaus & the Moloch framework"
url: "https://caper.network/wiki/dao-governance/tooling/frameworks/daohaus"
updated: 2026-08-31
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
---

# DAOhaus & the Moloch framework

|  |  |
| --- | --- |
| **Category** | DAO framework · no-code summoner · [Safe](/wiki/dao-governance/tooling/treasury/safe) module |
| **Framework** | Moloch v1 (2019) → v2 → **Baal** (Moloch v3, [HausDAO/Baal](https://github.com/HausDAO/Baal)) |
| **Summoner app** | [DAOhaus](https://daohaus.club/) — no-code UI to deploy and run a Moloch DAO |
| **Governed by** | HausDAO (itself a Moloch DAO) |
| **Signature mechanic** | **Ragequit** — burn shares/loot to withdraw a proportional slice of the treasury |
| **Membership units** | **Shares** (vote + exit) · **Loot** (exit only) |
| **Networks** | Ethereum mainnet · Optimism · Arbitrum · Gnosis Chain · Polygon · Base (testnet: Sepolia) — [docs.daohaus.club](https://docs.daohaus.club/networks) |
| **Contract status** | Baal's last commit is **11 June 2024**; the contracts are effectively frozen (see below) |
| **Operating surface** | [Admin App](https://admin.daohaus.club/) · [user guide](https://guide.daohaus.club/) · [developer docs](https://docs.daohaus.club/) |
| **2026 direction** | Autonomous **agent members** — a CLI, a hosted read/pinning service, and a published vote-decision procedure |
| **License** | Open source (MIT / GPL); primary sources: [Moloch v1](https://github.com/MolochVentures/moloch), [Baal](https://github.com/HausDAO/Baal) |

**DAOhaus** is the no-code home of the **Moloch** DAO framework — the lineage that gave the whole industry the word _[ragequit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights)_. Where a [Safe](/wiki/dao-governance/tooling/treasury/safe) multisig holds money and [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) holds opinions, a Moloch DAO fuses treasury, membership, proposals, and a guaranteed exit into one minimal on-chain contract. DAOhaus is the app that lets anyone deploy and operate one without writing Solidity, and the community (organised as HausDAO) that maintains the framework.

## The Moloch lineage

The original [Moloch v1](https://github.com/MolochVentures/moloch) contract shipped in 2019 to fund Ethereum public goods, and its GitHub description — a line from Ginsberg's _Howl_ — set the tone: a deliberately ruthless, minimal DAO. It introduced four primitives that recur everywhere in this wiki: **shares** (membership + voting power + a claim on the treasury), a **guild bank** (the pooled treasury), a simple **proposal and majority vote**, and — the innovation that mattered — **ragequit**: any member can burn their shares and walk away with a proportional slice of every asset in the guild bank.

Ragequit is a design answer to the [tyranny-of-the-majority problem](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks): a voting bloc cannot expropriate the minority, because the minority can always exit at fair value before a contested proposal executes. [Moloch v2](https://github.com/MolochVentures/moloch) generalised the model — multiple treasury tokens, guild-kick proposals, and a second non-voting unit called **loot** that carries exit rights but no vote.

The v2 contracts then forked in two directions. DAOhaus kept a fixed contract and put a no-code app in front of it; OpenLaw's [Tribute DAO Framework](/wiki/dao-governance/tooling/frameworks/tribute), generalised out of [The LAO](/wiki/daos/investment/the-lao), instead broke the same model into adapters a DAO could vote to replace. Tribute has since been archived; DAOhaus is still summoning DAOs.

## Shares, loot, and the guild bank

A Moloch DAO tracks two internal units. **Shares** grant voting power, the right to submit and process proposals, and a redeemable claim on the treasury. **Loot** grants the same treasury claim but no vote — useful for paying contributors or investors economic upside without handing them governance control. Both are minted through proposals, and both can be ragequit.

Everything routes through proposals against the guild bank: request shares/loot in exchange for a tribute of tokens, spend treasury funds, add or kick members, or call an arbitrary external contract. Because exit is always available, Moloch DAOs can run on thin process — there is less need for elaborate [governance machinery](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) when the credible threat is "if you pass this, I leave with my share."

## Baal — Moloch v3

The current framework is **Baal**, described by [its repository](https://github.com/HausDAO/Baal) as "a minimal yet composable DAO template continuing work from the Moloch, Minion, Compound/OZ and Safe frameworks." Baal keeps shares and loot as transferable ERC-20s, retains ragequit, and adds two things that make it modern:

- **Safe-native execution.** A Baal DAO implements the [Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac) standard and runs as a module on a [Gnosis Safe](/wiki/dao-governance/tooling/treasury/safe), so the treasury is a battle-tested Safe while governance logic lives in a separate, upgradeable module.
- **Shamans.** Privileged roles (minting shares, managing membership, pausing transfers) are delegated to external _shaman_ contracts rather than trusted addresses — composable permissions that pair naturally with [roles](/wiki/dao-governance/tooling/membership/hats-protocol) tooling.

Baal deploys on Ethereum mainnet, Optimism, Arbitrum, Gnosis Chain, Polygon and Base, with Sepolia for testing, per the [supported-networks page](https://docs.daohaus.club/networks) of the developer docs.

## Where the code stands

A framework page that says only “the current framework is Baal” hides the more useful fact, which is that the _contracts_ and the _product_ are on very different clocks.

The contract layer has stopped moving. [HausDAO/Baal](https://github.com/HausDAO/Baal)'s default branch is not `main` but a feature branch, `feat/baalZodiac`, and its [last commit landed on 11 June 2024](https://github.com/HausDAO/Baal/commits/feat/baalZodiac) (a factory upgrade); `main` itself has been untouched since [28 March 2022](https://github.com/HausDAO/Baal/commits/main). The original [Moloch v1 repository](https://github.com/MolochVentures/moloch) last saw a push on 30 December 2022. For a framework this is not necessarily decay — Moloch's whole design claim is minimalism, and a small audited contract that has not changed in two years is doing what it promised. But it does mean that anything new in the DAOhaus world arrives _around_ the contracts rather than inside them, through Zodiac modules, shamans and off-chain tooling.

The product layer, by contrast, is actively maintained. The [Admin App](https://admin.daohaus.club/) is the current operating surface (its repository was last pushed on 1 August 2026), the [user guide](https://guide.daohaus.club/) is maintained by the PublicHAUS community, and the [developer docs](https://docs.daohaus.club/) carry the contract reference, subgraph endpoints and deployment addresses. Reading the two clocks together is the honest summary: **frozen primitives, moving surface**.

## Agents as DAO members

The clearest thing DAOhaus shipped in 2026 is not a contract change at all. It is a stack for running an **autonomous agent as a member of a Moloch DAO**, split across three repositories: [moloch-skills](https://github.com/HausDAO/moloch-skills) (agent skills for reading and acting on Moloch v3 DAOs), [moloch-agent](https://github.com/HausDAO/moloch-agent) (a local CLI runtime), and [moloch-service](https://github.com/HausDAO/moloch-service) (a hosted helper that proxies subgraph reads and pins artifacts to IPFS).

What makes it worth a wiki entry is that the trust boundary is written down rather than assumed. The service's own README states that it “must never receive private keys”, that it “does not sign transactions”, and that it “does not make governance decisions”; signing stays in the local agent runtime. That is a deliberate split between _reading the DAO_, which is centralised and convenient, and _acting on the DAO_, which is not.

The [published vote-decision flow](https://github.com/HausDAO/moloch-skills/blob/main/VOTE_DECISION_FLOW.md) is more interesting still, because it is an explicit answer to a question most [voting tools](/wiki/dao-governance/tooling/voting/snapshot) leave to the voter. It states that agents “should not vote only from proposal text”, and requires a proposal to be classified first — signal, membership, treasury, metadata, governance settings, or **arbitrary execution** — and then checked for whether “action data match[es] proposal text” before any vote is cast. The document is careful to be “opinionated about _how_ agents decide, not _what_ values they must hold,” leaving the mandate to the operator.

Two things follow for the rest of this wiki. First, that final classification bucket is the whole problem of [typed versus arbitrary execution](/wiki/dao-governance/concepts/voting/typed-vs-arbitrary-execution): a proposal that can encode any call is one an agent (or a human) cannot judge from its title. Second, an agent holding shares is a [legal-personhood](/wiki/dao-governance/concepts/membership/dao-legal-structures) question as much as a technical one — the same question [MIDAO](/wiki/dao-governance/tooling/analytics/midao) started selling a wrapper for in the same year. The general case — what changes when software holds the shares rather than assisting whoever does — is covered at [autonomous agents as DAO members](/wiki/dao-governance/concepts/membership/autonomous-agent-members).

## Who runs on it

Baal's `sponsorThreshold`, `proposalOffering` and `minRetentionPercent`, and the agent runbook's "no new proposal while three are in voting" rule, are compared against Compound and Moloch's equivalents at [proposal throttles and rate limits](/wiki/dao-governance/concepts/voting/proposal-throttles-and-rate-limits).

The Moloch pattern anchors a whole class of [grant and investment DAOs](/wiki/dao-governance/concepts/fundamentals/types-of-daos). [The LAO](/wiki/daos/investment/the-lao) and its MetaCartel-lineage cousins are Moloch-based venture DAOs; [MolochDAO](/wiki/daos/public-goods/molochdao) itself continues as a public-goods funder. DAOhaus lowered the barrier from "deploy a contract" to "fill in a form," which is why the framework shows up under so many small, purpose-built treasuries rather than the mega-DAOs that dominate [DeepDAO](/wiki/dao-governance/tooling/analytics/deepdao) rankings.

See also the broader [DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview) for where a summoner sits relative to [Tally](/wiki/dao-governance/tooling/voting/tally), [Aragon](/wiki/dao-governance/tooling/frameworks/aragon), and voting front-ends.

## How Caper approaches this

Caper treats ragequit as a first-class primitive rather than an emergency hatch. A [caper](/wiki/foundations/what-is-a-caper) holder calls [exit](/wiki/foundations/leaving-a-caper) on-chain, burning their tokens to redeem a slice of the treasury – a direct descendant of Moloch's exit. Unlike ragequit it is not open to every holder: `exit` asserts a non-empty vote-token bucket alongside the governance tokens (`assert!(vote_tokens.amount() > 0, "Exit requires vote tokens")`), so a member who has earned no vote tokens – neither by trading on the curve nor by casting a ballot – has nothing to hand back and no exit to take. The difference is what sizes the slice: a caper's exit share equals its _canonical vote weight_, the same metric that determines voting power, so the treasury claim scales with both what a member holds and the [vote weight](/wiki/governance/voting-mechanisms) they have earned, not a flat pro-rata of one token. The exit right that Moloch pioneered for minority protection becomes, in Caper, the everyday accountability lever on the founder and the treasury.