---
# System prepended metadata

title: "v3 Haus Keeping \U0001F9F9 (Wednesday)"
tags: [' haus keeping', v3]

---

---
tags: v3, haus keeping
---

# v3 Haus Keeping 🧹 (Wednesday)

**March 2, 2022**

## Other Notes

- [TW Notes](https://hackmd.io/@TravisWyche/rJnCLGal9)
- [v3 Haus Keeping 🧹 (Tuesday)](https://hackmd.io/YHHwIeK8SlStMWjInUUVMw?view)
- [Baal Walkthrough (with Moloch Mystics): 2/9/22](https://hackmd.io/11coeaF_StCudM176W3ghw)

## Resources

- [Baal.sol](https://github.com/Moloch-Mystics/Baal/blob/main/contracts/Baal.sol)
- [feat/baalZodiac](https://github.com/Moloch-Mystics/Baal/blob/feat/baalZodiac/contracts/Baal.sol) branch
- MetaHaus Fig Jam

## Potential Topics
- Get through the rest of the Baal events and to a point where bill and dekan can fork Baal into the DH repo to get the Summoner up
    - Jord to Rage 🔥 on a Summoner app to start process 

## Baal Questions
- What should we name things? We use Moloch a lot already (for subgraph considerations)
    - Keep generic? Generic "DAO"
- How do we talk about it generally? "Baal" or "Moloch v3"?
- 

## Baal Events
`event Approval`
- ER20 `allowance` but applying to shares
    - Need to check if member approves Baal to spend/transfer shares when creating proposals
- ERC20 approval that applies to shares since these are quasi-ERC20
- Transaction *before* transferring shares 
    - ie: Approve Baal to spend/transfer shares
- Called on Baal itself in similar way you'd call DAI contract to spend DAI, you'd call Baal to spend your shares (or have someone else spend them)
- Summoning: `name` and `symbol` are for `shares`
    - for Loot, it's appended: ie
    - `Cheese-loot` 
    - Loot named at factory contract and the shares get named at the Baal contract

**Questions and Considerations**: 
- Need to explore patterns and common ABIs to get same level of proposal data in subgraph
    - Previously able to discern a lot from the proposal, so may need to decode (Baal is infinitely variable -- Could be difficult in a subgraph mapping)
- Strong content strategy around base proposal types that we offer in the UI, but then can add additional context in the `details` that can contain patterns we can decode
- What to do if someone stacks multicalls? Will need audit ability in the UI
    - Could be a good Rage 🔥 simulation
- Show warnings in UI when interacting with *unverified contracts*
- Making subgraph data less rich has impacts on the UX

`event Transfer`
- Focus on shares, but doing double duty
- Covers mint, burn, and transfer, and can determine based on from/to:
    - if from member -> maybe burn
    - if to Baal -> burn
    - if from Baal to member -> minting
    - if member to member -> transfer
- Can potentially break into separate events (transfer, mint, burn)
- If able to see the from and to together, able to discern
- TO Baal -> burn
- FROM Baal -> mint

`event TransferLoot`
- This is the same, but now that `loot` is own token has own events (potential for cleanup)
    - Inherit `ERC20` events
- bill looking at this with new loot contract so may not need this in Baal itself

`event DelegateChanged`
- Emitted when member delegates to another member:
    - From Sam to Bill -> `DeleteChanged` emitted and then triggers `DelegateVotesChanged` providing current snapshot of Sam's votes (`delegateFrom`)

`event ShamanSet`
- setting `shaman` and giving it permission levels (shamans are basically admins in the DAO, so attention needs to be given to the permission levels)
- What can a Shaman be?
    - Any address (EOA or contract) that can call `mint` or `burn`
- Permissions:
    - Three levels: `admin`, `manager`, `governance` -- docs needed for this. governance > manager > admin (power levels)
    - `admin`: 
        - ability to turn on or off transferability of shares
    - `manager`:
        - can set guild tokens and convert shares to loot (rage kick)
    - `governor`:
        - all parameters that define the way the DAO works
            - eg: set governance config, set/unset grace periods, set/unset voting periods, very high impact
    - permission levels build: 
        - eg: `permission 5` = `admin` + `governor`
    - can *only give something less power*

`event GovernanceConfigSet`
- emits when governance config changes
- `voting`
- `grace`
- `newOffering`
    - anti-spam protection: how much ETH/xDAI must be sent to the DAO to submit a proposal
    - UX consideration: if this is on, needs to be on all of our forms
        - Spam protetion setting
- `quorum` 
- `sponsor`
    - how much voting power is needed to self-sponsor
    - number of shares threshold, whereas `quorum` is a percentage
- `minRetention` -- parallel is `dillutionBound` in v2 (3 = 1/3 of DAO rage quitting kills a proposal)
    - based on a 100 scale now. to have equivalent of 3 (current) we'd set at 66.6
        - if 1/3 of the DAO quits, you retain 66.6% of the members
        - could be a slider in the UI ("How much of the DAO needs to rage quit to kill a proposal")
        - percentage based so cleaer to understand
    - this applies to any proposal, not just mint
- Will want a special proposal detail view for proposals changing governance

`event GuildToken`
- Sets token on the default ragequittable list, needs to be set as a guild token (but can always *advanced rage quit*) to pass in additional tokens
    - unset is Baal/manager only
    - `guildTokens.pop()` - pop last token from the array
- How much do we want to expose in the UI?
    - What do we want to show regarding Advanced Rage Quit (ARQ)? 
        - lean toward simpler -- ARQ meant for situations when member realizes that token is broken (such as missing a `transfer` function) and needing to skip over the broken token to successfully RQ
        - safety valve if something has gone wrong (not being choosey about tokens)
            - would sacrifice the token that isn't selected
- Is there an *attack vector* here? 

`event SharesPaused` and `event LootPaused`
- logic for transferability of loot
- independent of each other: shares can be paused and not loot
    - Example: LLC DAO
        - Most LLCs allow transferance of economic privileges (loot)
        - Allow another option to transfer governance (shares)
    - Have this in settings: users can pause/unpause loot
    - Top priority is focusing on making loot transferable since shares can be delegated (not transferred)
    - Would want this to be *off* by default since this impacts the permissioned nature (need to think through quorum)
        - This could make DAOs very complex, so start with permissioned and then extend outward as DAO evolves
        - Cover the evolution of the DAO:
            - Multi-sig -> permissioned -> token DAO (DAO can then evolve in complexity as community grows)

### Event Questions
- Are there any we don't want to include in the feed?
- What would we want in a UI news feed? How do we alert DAO members about things (especially things we're not exposing in the UI?)
    - Flag events for high visibility
        - Shaman creation definitely should be exposed since it's so powerful

## v3 Roadmap Order of Operations
- Get version of the Factory out and getting a Rage 🔥 going for the Summon flow
- Build out some junk apps to start building familiarity and identify what we need before building heavy UI
    - Junk apps can be used to test packages, and then begin working on the real apps (either building on top of junk apps or building fresh app)
    - Start with more bite-sized apps and go for the main course once we have the hub and summon apps built
- Junk apps: apps for iteration, not throwaway apps
    - Rage 🔥 experiments

## Design
- Ven sharing MetaHaus FigJam
- Microservices coming through a curated Marketplace
    - Shamans, Apps, Boosts, etc.
- Examples (purple is collaborative):
    - Hub and Explore will be useful if not just Moloch
    - Hub that has a list of DAOs
    - Hub & Explore can be more open to other DAO types (token DAOs)
    - MetaOS
        - Interface above DAOhaus already (such as the Poster work)
        - Where is the non-technical stuff? Our walkthroughs such as "What is as DAO?"
    - Hub -> MetaOS
        - Static site with core governance that then links to the respective interfaces (Gnosis Safe, Snapshot, Moloch)
        - With Baal v3.1, DAOs aren't just Moloch DAOs anymore
    - Can build Moloch UI *first* and build out from there
- Differentiation between micro-services and apps
    - Having apps and boosts able to be shared between different places
- Where do layers on top of the Moloch UI go? Such as the Yeeter
    - Yeeter to form Moloch DAO -> in the Moloch ecosystem
    - There may be other similar examples that can lead into the formation of the Moloch UI
    - DAOBooks would be an app 
    - Yeeter, DAOBooks, etc. are using tools from the Marketplace to build
- MetaOS:
    - Frontend for your DAO
    - Frontend of the Frontend
    - Center of operations that can pull in lots of differnet items
    - DAOs are amorphis, this can serve the purpose of helping unify
    - This is a great place to explore some of the other features (docs, micro-blog, etc.)
    - Could this be something that DH should do? Potential collaboration with less technical folks
    - Why would we not want this in Moloch UI?
        - Not everyone would wnt to engage with a Moloch, so this would take it one step higher and allow for integration for folks using different models (Snapshot for example)
    - Separation of concerns (whoever is building this doesn't need to *build* the Moloch but would be able to *read* it)
    - "UI middleware of DAOs"

### Feedback and Questions
- Consider adding Rage Reports and DAO blog experiments to this roadmap
- Hub and Explore: start with building ourselves and then collaborate with the community
    - DeepDAO and DiamondDAO are working on something similar to Explore, so there are opportunities for collaboration
- As we build libraries we can use them in other junk apps for testing
    - eg: Summoner app can be used to summon other experiments where we can test libraries we're making
        - See how composable things are while building and can see how pieces *interact*
- Concern with library strategy:
    - Need to be treated as non-production level code
    - Should *inform* how we build things, but if we carry to prod we may incur code debt (especially with libraries)
        - There is a large maintainence cost -- need to be able to update w/o breaking consumer code while retaining flexibility
        - Best way to do this is to maintain a solid prod app that battle tests the libraries
- MetaOS will need to be community owned -- similar to a DAO first/community owned Notion
    -  Editing content as a DAO
- Creating apps along the way is motivating

### UberHaus Bolt-on
- Become it's own thing -- all DAOs that are using the MolochUI
- Bolt-on showing the UberHaus DAOs
- This could be a MetaOS thing
    - Take the current Docusaurus and plug-in some MetaOS features
- What functionality is required?

## Next Steps & Action Items
- Scope out what initial builds could look like for each of these? Think about UX for a nimble version (MetaOS, Hub, Explore)
- Can we build a solid starter without our libraries at a prod level?
    - Would do a better job when libraries are closer to ready

[] Compile list of the Rage apps
[] jp revisit the Baal Docs site started earlier this month and begin compiling the notes/docs everyone has contributed
[] Start with Summon and Moloch UI and review where we are and determine if ready to start raging
[] Think about UX for MetaOS, Hub, and Explore