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