Baal Run-through

--- title: Baal Run-through tags: baal --- # Baal Run-through ## Baal Overview 1. **Delegation of Shares** - Full delegation of votes might not be needed at the start 2. **Shamans (super-powered minions)** - Shamans are super-Minions that bypass the proposal process & can execute any internal logic that only it can use. Shamans can execute logic base - Shamans can adjust (up or down) share and loot balances, but members need to claim shares. Shamans need to be whitelisted first. - E.g. 1: Do a snapshot on tokenholders & issue shares to members - E.g. 2: YeetDAO - when somebody sends X ETH, it assigns Y loot and Z shares to the person - For optional plug-ins/use cases, Shamans could be Boosts. For common use cases, there could be 'master Shamans' that are installed (& customised) during Summoning 3. **Normal MolochDAO concepts** (e.g. ragequit, sponsoring proposals, etc. ) 4. **Spam prevention** (e.g. proposal deposits) 5. **Token transferrability** - Token is a summoning parameter which can be tweaked but set as non-transferrable by default - As compared to v2, the tokens are no longer integer shares, but work the same way as ERC-20 tokens (e.g. 18 decimals). - Token transferability is rather advanced & later in the life cycle 6. **Flexible voting periods per proposal** 7. **More flexible Proposal Types** (Multi-call proposals instead of many different types of proposals) - This makes it harder for us to flag proposal types on the Subgraph, but we still have control over the frontend to filter & show - Function signature within the bytes submitted can tell us the proposal types ## Life Cycle ### Summoning - Configurable summoning parameters: - Loot transferrability (lootPaused ?) - Shares transferrability (sharePaused ?) - Initial guild tokens - Minimum voting period (Specified with every proposal) - Max voting period (Specified with every proposal) - Grace period (Mutable) - The summoning setup involves a multi-send which calls the configuration functions (e.g. SetPeriods, GuildTokens, Shaman, mintShares, mintLoot, delegateSummoners) - delegateSummoners delegate Shares to themselves - dilutionBound seems to be removed - Summoners need to give the shares a name & symbol. These cannot be changed currently (but could be changed in the future TBD) - Loot can be transferred but it is not an ERC-20 token - Shamans: There could be Shamans already deployed & set it on summoning - When writing the Shaman, do we need to hardcode the DAO contract? No, the DAO is whitelisting the Shaman contract - If there are common/whitelisted Shamans, we could expose it at summoning where summoners can customise parameters (Shaman per Baal) ### Members - Summon with multi-share holders & multi-loot holders (2 different arrays) - Generally members look the same, but members now have (if enabled) transferrable ERC-20 shares and a NFT representing their Shares/Loot data - Having both the ERC-20 token & NFT might be problematic. The wallet might think that the NFT is transferrable, but the signatures are not matched - Delegation is new where you can delegate to any address, regardless of their holdings (similar to Compound) - Multiple people can delegate to 1 address, but the delegates can only vote on behalf of another, they do _not_ have the power to ragequit - More options for different governance models - Members can now claim a NFT based on their Shares & Loot ownership - There should be some logic to handle ragequitters ### Token Balances - Whitelisting: Baal can do arbitrary executions, but the whitelisting proposal (SetGuildToken) is needed to whitelist a token for RageQuit calculations - Internal Balances: There are no more internal balances - tokens are sent directly without any need to request tokens - Rage Quit: It seems like the user can select tokens which they want to ragequit ### Proposals - Proposals are pretty similar to the Multi-Send proposals currently - For each proposal, - voting Period (needs to be set every time) - proposalData (concat state changes happening to the DAO) - expiration (This is set at time of proposal creation - at what block timestamp, should this no longer be executable - should this be configurable to user? we can set to 0, so no expiration) - Proposal data will not be stored onchain & need to be read via the subgraph, giving proposals processing more gas efficiency. - The subgraph will need to call a view function on the BaalFactory with the proposal hash to receive metadata - Processing a proposal also does the execution, but will be cheaper as one tx ## Next Steps We don't have to support everything that Baal supports right out of the gate. We should prioritise what's needed in the earlier / general life cycle stageso of a DAO. The following areas require a deeper dive on the parameters & UX implications 1. Proposal controls 2. Delegation models from Compound/Gitcoin 3. Shares (How does ApproveShares & Whitelisting work?) - Approve Baal to send tokens to someone 4. DAO configurations & settings - upgrade your DAO 5. Shaman - use cases: staking for power - Maybe how guild kick works? - Single contract that works for everybody, but the DAO has to set the ratio, etc. 6. RageQuit looks exactly the same 7. New function called Flashloan 8. User Profile: Internal Balance is gone & membership NFTs, perhaps even Delegation