Baal 👺

Meet Baal


Baal sets the season, and gives forth His voice from the clouds._

There was a time when humanity mistakenly assumed that we were at battle against each other. Then, the original Moloch DAO contract made us aware that the enemy is Moloch, the demon god of coordination failure.

Moloch v2 helped us to begin efforts of working together to solve the problems that affect all of humanity. Baal is Moloch v3 and offers more tools to improve these efforts.

Your skills at wielding a pair of battle axes have improved. It is now time to test your courage. Moloch is a worthy foe. Aim for the head.

Initial Development and much of this section is from the Moloch Mystics GitHub Baal Repository

Current active development is happening in a fork on DAOhaus Github

This is the most recent collaborative repository for Moloch V3, codename Baal. (July 15, 2022). This message will change when the repository is deprecated.

Baal is a minimal yet composable DAO template continuing work from the Moloch, Minion and Compound frameworks to make it easier for people to combine and command crypto assets with intuitive membership games.

Baal Animation


Baal is a governance layer that sits on top of a multisig treasury layer. It uses the Gnosis Zodiac standards to interface with the treasury.

By abstracting governance into its own layer Baal allow a more nounced 'Moloch style' control over consensus.

Governance Units

Just like in the Moloch V2 contracts there are 2 main governance units

  • shares
  • loot

These are both represented now by erc20s which can have minting, burning and transferability controlled by the main DAO contract.

Unlike Moloch V2, transferability of these tokens can be controlled by the DAO.


SoulBound DAO
A DAO may start soul bound (like v2) but then decide at some future time to turn on tradability for shares and/or loot.


Just like Moloch V2 shares have direct execution, voting and exit rights around actions taken by the main dao contract. Shareholders are the collective DAO admins.


Also similar to Moloch V2, loot has only exit rights against the DAO treasury, so loot does not have the ability to admin the DAO config. But because it has exit rights it is still a powerful unit and also because it is an erc20 can be used in the many composible ways a token can be used.

DAO configuration and guild management

There are many configuration options that can be updated in the contract through standard governance and proposal flow. For example:

  • Mint/burn/pause shares/loot
  • Set governance or admin configuration
  • Enable/Disable Shamans

Whats a Shaman?

Besides standard governance by share holding members there is a new idea of a Shaman. Shamans are specific addresses that have more granular control outside the standard governance proposal flow. These addresses should always be contracts that have been explicitly given these rights through the standard proposal flow or during initial DAO setup.


Shamans are addresses that can be granted roles that allow them to control some aspects of the DAO configuration without proposal.

Roles and Shamans

The DAO is always a super admin over it's own config. Meaning the DAO can vote to make changes to its own configuration at any time.

Along with this, through roles, a more granular control can be given to Shamans.

  • Governor - Cancel a proposal, set Governance Config (change the length of proposals, if there is a required quorum, etc.)
  • Manager - mint/burn shares/loot
  • Admin - set Admin configuration and pause/unpause shares/loot

Initial setup

Initial setup of the dao can happen in 2 ways. See the baal Summoner factory for details.

  • Standard summon - Deploy and setup all contracts (Core Dao, Erc20s) and treasuries (Gnosis Safe)
  • Bring your own treasury - Summon contracts but use an already deployed treasury (Gnosis Safe)

In standard summoning, the summoner will provide a DAO name and token symbol along with a list of actions to be executed on setup. These initial actions may be setting governance/admin config, minting shares/loot to other initial members and/or adding any initial Shamans.

If you are bringing your own Safe - Setup will occur through a signed transaction in the multisig. This will do the same actions in the standard summon but will also enable the Baal module on the Safe.

Proposal flow

The proposal flow is similar to a Moloch V2 but there are a few differences. Basically proposals are made to the dao to execute some code (could be minting shares, transferring funds, changing config, or any mix of things... every proposal is a multicall). It includes a time boxed window for voting, followed by one for a grace period. The basic flow is mapped out here:

  • Submit - A proposal is submitted by anyone
    • An offering may be required by the DAO on proposal submission. This is mainly to prevent spam and is especially relevant on side chains. THis setting is configurable by the DAO.
  • Sponsor - Any member, as long as they have enough shares to meet the ‘sponsor threshold’ can sponsor a proposal. It may even auto sponsor if submitted by a member with enough shares.
  • Voting - The proposal will go into a voting period where shareholding members can vote yes or no
  • Grace - The proposal then goes into a grace period, this is where minority members or the dao can take further action (ragequit or cancel)
  • Ready - The proposal goes into a ready state, this is where actions included in the proposal can be executed.
  • Execution - After execution or if the proposal was terminated for some other reason then the proposal will be in one of these states
    • Canceled - either canceled through failed execution or through a manager shaman or the sponsor.
    • Processed - executed successfully
    • Defeated - did not pass and will not execute

Proposals must be processed in the order they are voted on.


Canceling a proposal
Cancellable if proposal is in voting, sender is sponsor, governor, or if sponsor has fallen below threshold
A Governor Shaman can cancel a proposal, it can be canceled anytime while in voting period.

Member actions

  • Vote - a member uses its shares to vote yes or no on a proposal.
  • Vote with signature - vote though eip 712 (allows votes to be collected through a gasless signature and submitted later)
  • Ragequit - burn some amount of shares/loot to a proportional amount of funds in the treasury
  • Delegate - add or remove your shares voting power to another address, this address can be another member or any address.

Optimistic voting
A proposal passes with more yes votes than no votes. Depending on governance settings there may also be a required quorum of total votes for a proposal to pass.

Governance Config, settings that can be modified by the DAO or by a Governor Shaman

  • voting - minimum voting period length of a proposal
  • grace - minimum voting period length of a proposal
  • newOffering - the amount a native token that must be used when making a proposal, this is transferred to the dao and is non refundable.
  • quorum - minimum % of shares that must vote yes for it to pass
  • sponsorThreshold - minimum number of shares to sponsor a proposal (not %)
  • minRetention - auto-fails a proposal if more than (1- minRetentionPercent) * total shares exit before processing

See the Governance config section for more info.

Admin Config

Admin config is to control the transferability of shares and loot.

Note on other other baal only actions

You may see that "Guild Kick" (Changing shares to loot, a major tenent of Moloch v2) is not present in Baal, this is because it can be created through a baal only proposal (multi call that is voted on by the DAO). Also besides Guild kick you can also do the inverse as a "Promotion" (loot to shares).

  • execute as baal - A proposal can be executed from the baal contract directly (this mainly is used to for DAO configuration and member management, In can also be used to rescue funds that where sent directly to the baal contract)
  • admin locks - The DAO can permanently lock special rights that could be given to Shamans (for example, permanently disable Governor/Admin/Manager Shamans)

In the Wild

These are the Dapps and developer toolkits that use this contract


  • Battle Testing DAOs in the wild


  • Currently in audit

Deployed on Netowrks

Goerli Baal Factory: 0x0C5fd8AAdF995e11E5Ac1CD72139Ee4fd72cDeFC

Moloch v3x and v4

We only just begun, stop by and say hi to learn about features/contracts in the works and how to get involved.


The Moloch contracts are built and maintained by larger group of opensource developers and teams.

Code is open source and any contributions, reviews, and sanity checks are welcome.

Working branch that these docs refer to is at the Daohaus Repo feat/baalZodiac branch

Forked from Moloch Mystics Repo

Convorsations are happening in the metacartel discord #los-moloches MetaCartel