Skip to content

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

License

Notifications You must be signed in to change notification settings

Flip-Liquid/Baal

 
 

Repository files navigation

Baal 👺

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:

Interfaces Supported

ERC-20

Baal shares are pausable, fungible tokens. Non-conformant tokens can also be handled by Baal by implementing safeTransfer/From().

EIP-2612

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.

ERC-721

Baal is a 'safe' receiver of NFTs by implementing onERC721Received().

ERC-1155

Baal is a 'safe' receiver of tokens issued under 'multi-token' contracts by implementing onERC1155Received() and onERC1155BatchReceived().

ERC-3156

Tokens held in Baal can be flash lent for an amendable fee by implementing flashLoan(). This feature can be turned on and off.

Optimizations:

Tokenized Shares

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

Gas-less MetaTXs

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.

Arbitrary Actions

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.

image

Flexible Voting

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.

image

Member Automation

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.

image

Moloch DAO V2 Parity:

Proposal Flow

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

image

Loot

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.

Ragequit

image

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

Token Whitelisting

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.

About

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

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • Solidity 73.3%
  • TypeScript 24.2%
  • JavaScript 2.5%