---
# System prepended metadata

title: Baal Run-through
tags: [baal]

---

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