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.
Guilds, venture clubs and control panels can benefit from Baal:
Baal shares are pausable, fungible tokens. Non-conformant tokens can also be handled by Baal by implementing
safeTransfer/From().
Baal shares support EIP-712-style approvals by implementing
permit(), allowing pulls in a single transaction and 'gas' to be paid in tokens (including Baal shares), abstracting the need to hold ETH.
Baal is a 'safe' receiver of NFTs by implementing
onERC721Received().
Baal is a 'safe' receiver of tokens issued under 'multi-token' contracts by implementing
onERC1155Received()andonERC1155BatchReceived().
Tokens held in Baal can be flash lent for an amendable fee by implementing
flashLoan(). This feature can be turned on and off.
Baal voting shares are fungibles tokenized under ERC-20. Voting weight can be delegated and balances are checkpointed using the Compound governance token template. This therefore allows for shares to be exchanged and staked into DeFi positions, but always at the will of the underlying DAO, as they can be burned into loot ('ragekick') through a Membership Proposal (1) and paused through a Period Proposal (2).
Signed approvals following EIP-712 can be retrieved by a relayer and allow Baal members to transfer their voting shares (EIP-2612, permit) as well delegate voting weight (COMP, delegateBySig) without needing gas in their wallets.
Baal members can vote to execute any arbitrary logic, which can be in a series of arrayed data and value, through a new Action Proposal (0) type. This is familiar to Minion, which has extended the functions available to Moloch DAO members as an external helper contract (also cf., Aragon, Gnosis SAFE).
By incorporating this functionality into the Baal base, such actions can be streamlined and tap Baal assets more directly (at the tradeoff of increased vigilance), as well as combine with other proposal types through multiCall. Further, support for low-level calls natively extends Baal to support ETH as an asset.
Baal voting periods can be set within bounds on summoning with a minVotingPeriod and maxVotingPeriod, as well as amended through Period (2) Proposals. Further, if a Baal has a single member, or a proposal has already passed its consensus threshold, such periods are ignored to accelerate Baal operations.
Extensions to the core Baal logic for membership rights (ragequittable shares, loot, proposal flow, etc.) can be attached as a shaman and removed through a Whitelist Proposal (3).
For example, a Baal DAO may want to automate aspects of membership admission, and launch a crowdsale contract that is approved to grant 10 Baal voting shares per 1 ETH called as a memberAction or have a merkle airdrop of voting and loot weights unique to prospective members.
Short of redeploying a new Baal, such shamans also allow members to experiment with new ways to engage and incentivize members--for example, a contract could serve to increase a member's loot weight based on their voting participation, offering efficient ways to subsidize voting attention and TX costs.
Baal follows Moloch DAO game theory around membership capital claims through ragequit (below), and as such, requires proposals to be processed in the order they are submitted. Proposal types are also identified by familiar flags (Action (0), Membership (1), Period (2), Whitelist (3)), and execute different logic by such type on processProposal. By including a flag as an input param on submitProposal, submission is similarly simplified in Baal.
To expand available logic and streamline execution, proposals also include arrays for target accounts (to) and associated value and data, which can express grants of membership weights, attached ETH value for action calls, as well as signal between grants and revocations (which can even be combined, for example, in granting a team membership right while also converting a member to loot status).
Like Moloch, Baal holds an internal account of purely economic rights. Baal extends here by allowing such loot to be granted on summoning, transferable, as well as claimed through shaman extension contracts.
Like any Moloch DAO, Baal membership shares and loot can be burned to claim a fair share of whitelisted tokens (below) after the last proposal a member voted 'yes' on is processed. Baal further allows a recipient to be listed (to), where such claims might be treated as means of payment.
To help ensure predictable token redemption behavior beyond whitelisting, 'safe erc20' checks are included, as well, for each token that is claimed (for example, Moloch DAO V2 cannot hold BNB tokens since they do not conform with erc20 fully).
Baal makes a more opinionated change by removing the banking 'pull pattern' of Moloch DAO V2 to opt for transactional efficiency in making direct token transfers on ragequit. (To note, pull-pattern banking can always be added as a shaman extension.)
Ragequittable tokens are represented by a whitelist array (guildTokens). To improve on this, Baal also allows for tokens to be removed from such list through Whitelist (3) proposals.