---
# System prepended metadata

title: Baal UX Worksession Notes (WIP)
tags: [v3]

---

---
tags: v3
---

# Baal UX Worksession Notes (WIP)
Notes from the Baal UX worksession: overview and Baal lifecycle

## Overview
- Baal docs from end of July -- need updates
- Baal is a mix a Minion (Moloch v2) and a token contract
    - Lots of flexibility from this
- There is a new *delegation* feature
- **Shamans** are also new -- these are essentially superpowered Minions
- Retains core functionality of Rage Quit, Sponsorship, Guild Kick
    - Talking about adding spam prevention
- Can do proposals to change voting periods and token transferability
    - Token starts as non-transferable -- is this set at summoning?
    - Have to launch through Baal -- though there was some discussion about *bring your own token* but didn't make sense for v3
- What do the tokens represent?
    - Tokens *are shares* -- instead of integer shares, they're accounted in the storage in same way that ERC20 are (and are visible down to 18 decimal)
- We can pick and choose what Baal features we want to support and can gradually integrate more over time
- Proposals are much more flexible now -- 
    - There is an *everything propsal* now which uses multi-class to do what we want (as opposed to different proposal types)
        - This could introduce complexity at the subgraph level, but we have more control on the frontend
    - We could say that a member proposal is a certain set of calls (can define them in this way) since they'd be the same every time
    - Can add as many functions as they want -- folks can keep tacking on 
    - `multiSend` array -- need to iterate through this and look for relevant function signatures
- Subgraph and data model:
    - Many of same *entities* -- DAO, proposal, vote, member -- pretty similar and can likely be shaped similar to how we have v2
    - What about tokens and internal balances for members?
        - There's no longer a whitelist proposal -- there is whitelisting as an action proposal that calls `baal` and does a `setGuildTokens`
        - Token effectively needs to be whitelisted in order for it *to be Ragequittable*
            - Purpose of setting guild tokens is to calcuate Rage Quit
            - Anyone can send tokens to the Baal, but they're only Ragequittable if they're whitelisted
        - Internal balances are gone -- this could be an issue -- need to specify which tokens want to be Ragequittable
            - Rage Quit sends immediately, so do funding proposals

### Shaman
- **Yeeter Shaman**
    - When someone sends x amount of ETH, it automatically assigns a certain set of shares/loot to that person
        - Bypasses the proposal, instead relies on Shaman's internal logic
    - Sending ETH/tokens -> assigns set of shares/loot
    - Yeeter Shaman contract can be set up in a way to have logic: if hits goal -> shares/loot, if not hit goal -> return ETH
    - The Shaman can only adjust `message.senders` loot and shares right now -- could we make this more flexible?
    - Need to whitelist each Shaman
        - Shaman factory -- need a flow to connect Shaman with a DAO
        - Some Shamans could be *Boosts* -- devs can build Shamans for DAOs and provide to others via Boosts
- Shaman requirement exposes an `interface` called `memberAction` that determines how a person's loot or shares should be adjusted (down and up)

## Baal Lifecycle

### Summoning
- **Summon deployment config**:
    - Set voting periods, transferability of loot and shares (these are separate configs -- transferability set separately), initial guild tokens, minimal and maximal voting period, grace period, loot paused, shares paused (look at `Baal.test.ts`)
        - voting periods can be adjusted at the proposal layer, but a later proposal can change the bounds of these periods
        - at summon, all summoners delegate to themselves
    - in Subgraph, may want to start tracking shares and loot as own entity if potentially transferable
- At summoning DAO, could choose from previously whitelisted set of Shamans or alternatively could have 1 main Shaman with customizable parameters
    - Summon Baal and Shaman for different flavors
        - Can we have a Singleton Shaman?

### Members & Delegation
- Can summon with multi-shareholders and multi-lootholders
- *Transferable* shares can be sent outside of app (just like other tokens)
- Delegates are now different -- similar to Compound way
    - Unsure if restricted to existing Members or anybody, but in Compound Governor can delegate to anyone (regardless of their holdings)
- NFT: For a token to show up, Member has to call `claim`
    - Each Member claims NFT version of their shares/loot
    - If Ragequitting, their NFT zeroes out: zero shares and zero loot
        - If 0 loot and 0 shares it gives an empty token (could potentially make it a husk of an NFT or fail)
### Proposals
- Proposals are all *multi-send* encoded -- can *chain together* many things
- Can set `votingPeriod`, `proposalData`, `expiration`, `details`
    - `expiration`: at what block timestamp should this proposal no longer be executable
        - Do we want this to be hardcoded or should users set it?
            - If set to 0 there is no expiration on proposal
        - If sitting it won't block future proposals -- we may need to do some more investigation into why people will care about this setting
- `details`: metadata that gets emitted -- don't need to store in the proposal but can still be emitted
    - Frontend can read via the Subgraph
    - Challenge: Subgraph parsing the actual `calldata` -- Subgraph can call view functions on contracts
        - Function that can parse arbitrary call data (similar to Gnosis `MultiSend.sol`)
        - Subgraph can call the view function with the proposal data from the actual proposal and receive back the parsed information and handle in a legible way in the Subgraph (which avoids having to decode on the frontend)
        - Benefit is greater gas efficiency in the proposals since we only need to store hash of the neessary information
    - 

### Questions and Thoughts

- Ability to change token name and symbol at a later point?
- If we're bundling economic and governance rights into one thing it should likely be transferable
- Is delegation restricted to existing shareholders in the Baal?
- Removing proposal details (only having the hash) from the proposal will save on gas


