Baal 👺

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

Guilds, venture clubs and control panels can benefit from Baal:

Setup

If you are going to just use this project feel free to clone it. If you would like to submit any pull requests please create an issue or work on a current issue and fork the repo. The main groups that are contributing to this project are Moloch Mystics, DaoHaus MetaCartel.

Setup Environment

yarn install - to install all of the components for the project

.env.sample containes the all required environment variables that need to be set to build, deploy & publish the smart contracts on the blockchain. These should be added to a .env[.*] file.

Building

This project uses the hardhat ethereum tools for solidity compiling and running a virtual ethereum environment for testing.

yarn build - will compile the solidity code and generate your contract artifacts (in the /artifacts directory), and generate all of the necessary types.

Testing

If you are looking to work on unit tests for this project be sure to read the README file in the test directory.

yarn hardhat test - run the unit tests

Publishing

the Baal contracts, types, and abis are published through the CI process, after making changes to the repo, and when you are ready to publish the packages, do the following:

1. bump the version in package.json
2. push and merge into feat/baalZodiac branch

running the CI process will trigger on merges to feat/baalZodiac branch build the dist folder and publish it to @daohaus/baal-contracts package to npm if the package.json version is different than the current latest on npm.

Folder Structure

• ./abi - generated abis
• ./contracts - main solidity contracts, interfaces, tools and utils
• ./deploy - deploy scripts and helpers)
• ./scripts - deploy scripts and helpers (soon to be deprecated)
• ./tasks - hard hat cli tasks
• ./tests - test files

Coverage

currently, coverage is turned off for test efficiency purposes. In order to switch coverage on, add yul to the hardhat config:

{
  ...
  compilers: [
    {
      version: "0.8.7",
      settings: {
        optimizer: {
          enabled: true,
          runs: 200,
          details: {
            yul: true
          }
        },
      },
    }
  ]
}

then run the coverage command:

npx hardhat coverage

Verify Contracts

Run the following command:

yarn hardhat etherscan-verify

Importing the package on your own project

You can yarn add @daohaus/baal-contracts on your own project and get access to Baal smart contracts, ABIs & deployment scripts for local testing your contract integrations:

• Smart contracts: you can import Baal smart contract on your Hardhat /Foundry / Truffle project at @daohaus/baal-contracts/contracts/*

• ABIs: if your custom frontend needs to interact with Baal contracts, you can find contract ABIs at @daohaus/baal-contracts/abi/*

• Local testing: if you're using hardhat-deploy, you can reuse our scripts to deploy all Baal + infrastructure contracts locally to perform integration testing with your implementation. You just need to follow these steps:

  1. Add these lines on your hardhat.config.ts config file to allow hardhat-deploy to find Baal artifacts & deployment scripts:

  ...
  external: {
    contracts: [
      {
        artifacts: 'node_modules/@daohaus/baal-contracts/export/artifacts',
        deploy: 'node_modules/@daohaus/baal-contracts/export/deploy'
      }
    ]
  },
  ...

  2. On your test scripts, you can call await deployments.fixture([tag1, tag2, ...]) (e.g. under beforeEach()) and specify the deployment tags you need. For example, await deployments.fixture(['Infra', 'BaalSummoner']) will deploy both Safe & Baal contracts.

  3. You can also use the baalSetup fixture to setup your tests with factory contracts, baal settings, members, loot/shares/token distributions, etc. Moreover, you can also customize it to cover new use cases such as custom summoner contracts, shamans and other setup needs by implementing thesetupBaalOverride and/or setupUsersOverride fixture function parameters. You can take a look at a few example implementations of (baalSetup and setupUsersDefault) for inspiration. You can find and import all the available scripts/fixtures available for hardhat testing as follows:

  import { baalSetup, ... } from "@daohaus/baal-contracts/hardhat";

  Below, there's the list of parameters can be customized when calling the hardhat fixture:

    type BaalSetupOpts = {
      fixtureTags?: Array<string>; // additional deployment tags
      daoSettings?: Partial<DAOSettings>;
      summonSetupOpts?: Partial<SummonSetup>;
      safeAddress?: `0x${string}`;
      forwarderAddress?: `0x${string}`;
      lootAddress?: `0x${string}`;
      sharesAddress?: `0x${string}`;
      setupBaalOverride?: (params: NewBaalParams) => Promise<NewBaalAddresses>;
      setupUsersOverride?: (params: SetupUsersParams) => Promise<UsersSetup>;
  }

To learn more about using fixtures on hardhat visit link1 and link2. It is also recommended to check out the Baal shamans repository for examples.

Contracts

Baal (contracts/Baal.sol)

It 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.

Interfaces

• EIP721
• OZ Minimal Clone Factoy EIP 1167 Clones Gnosis Safe Module Zodiac

Shares (contracts/SharesERC20.sol)

Have direct execution, voting, and exit rights around actions taken by the main DAO contract. Shareholders are the collective DAO admins.

Interfaces

• ERC20, Initializable OpenZeplin v4

BaalVotes (contracts/utils/BaalVotes.sol)

Abstract with a similar Implimentation of ERC20VOTES with the main difference being auto self-delegation and the use of timestmap instead of block.number.

Interfaces

• ERC20Permit

Loot (contracts/LootERC20.sol)

Has only exit rights against the DAO treasury, so loot does not have the ability to admin the DAO config. However, because it has exit rights, it is still a powerful unit, and because it is an ERC-20 can be used in many composable ways.

Interfaces

• ERC20, ERC20Snapshot, ERC20Permit, Initializable OpenZeplin v4

TributeMinion (contracts/tools/TributeMinion.sol)

It is a helper contract for making tribute proposals. Provides contract to approve ERC-20 transfers. Provides a simple function/interface to make a single proposal type.

BaalSummoner (contracts/BaalSummoner.sol)

Factory to summon new dao contracts. It can take an existing safe or exsiting tokens

Higher Order BaalAndVaultSummoner (contracts/higherOrderFactories/BaalAndVaultSummoner.sol)

Factory to summon new dao contracts with an extra 'sidecar' non-ragequitable vault. A registry is used to save safe addresses for use in UI. It can also add a external safe to an existing DAO as owner

Higher Order BaalAdvTokenSummoner (contracts/higherOrderFactories/BaalAdvTokenSummoner.sol)

Factory to summon new dao contracts with custom loot token name and symbol Minting and pausing of token happen upfront before Baal is setup

Privileged roles

• 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.
• Governor - can cancel a proposal, set Governance Config (change the length of proposals, if there is a required quorum, etc.).
• Manager - can mint/burn shares/loot.
• Admin - can set Admin configuration and pause/unpause shares/loot.
• DAO - is always a super admin over its config and can vote to make changes to its configuration at any time.

Risks

• In case of Shaman keys leak, an attacker can get access to Baal (admin) functionalities, burn, mint, give shaman roles etc. Because of this Shamans are ment to be external contracts and not EOAs but it is up to the DAO to enforce this.

More Documentation

More docs for Functions and Events, V3 updates, patterns, stories and other superficial musings can be found at the Docs Page here

initial audit

See audit notes in ./audits

Addresses Beta Factories and Templates

Would you like to deploy to another chain? Use scripts/deployFactories and scripts/deployTribute. Please reach out for more info on deploys

see current deploys at: src/addresses/deployed.js

License

MIT