---
# System prepended metadata

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

---

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

# v3 Haus Keeping 🧹 (Thursday)

**March 3, 2022**

- Today's focus is primarily design

## Other Notes

- [v3 Haus Keeping 🧹 (Wednesday)](https://hackmd.io/FGSL2IK4SjO7vukxR4FiTQ?view)
- [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

## Summoning Form

- What would be in Easy Mode (using defaults) and Hard mode (customizable settings)
    - self-sponsor threshold, quorum
- Start with building out Hard Mode and then we'll work back to what is included in Easy Mode
    - When cloning, these settings will be included (quorum, self-sponsor, spam protection)
    - What is included in DAO Metadata?
        - Name, avatar, description, long description, community links, tags? (thinking for Explore)
        - Would we want to pull this into it's own app? "Register your DAO"

### Userflow for Summoning:
- Begin with some standard settings or expand and customize each field set
- Starting Guild Tokens
    - Step users through each element (section by section)
    - Advanced:
        - Paste a token address in or select common tokens from a token list 
        - if pasting one in, check to make sure that it's an ERC20 token
- Proposal Timing
    - voting length and grace period length
    - potentially no velocity (will need to check the latest code)
    - Toggle for if you have an existing safe?
    - Would we want to introduce boosts at this point in the flow?
        - Where would we add boosts? this is tricky from a UX standpoint
        - look at priority boosts as a potential starting point
    - person submitting the proposal is the wrong person who can tweak proposal settings (we need to guard this as its a potential attack vector -- Shamans are very powerful due to their governance abilities)
- Starting Members
    - option to import from list as a CSV (advanced)
        - Address - Shares - Loot
    - Similar to current UI flow
- Starting Shamans
    - Currently an address, but has room for curated Shamans (such as the Yeeter)
    - When setting Shamans, need to tell it what permissions it has:
        - Admin, Manager, Governance and these can stack (will want to leverage explainer content to make sure that this is clear for users since this is highly impactful)
    - Shaman requires a Moloch address to scope itself (unless its an EOA)
        - EOA as a Shaman is something we don't necessarily want to happen much
    - How do we explain what's going on and why certain fields are important?
        - Many users may have questions about these, such as "What is a governance Shaman?"
        - 1) don't provide as options (ignore some aspects at first)
        - 2) provide clear copy that adequately inform users
        - 3) rich content and explainers to help folks who are unaware make an informed decision
    - However, for the Rage 🔥 we should include a clean Hard Mode and then *learn what Easy Mode is* and strip out what is potentially confusing for users
    - Start with *assigning existing Shamans* at first -- you would need to have an address that is already a Shaman
        - Yeeter Shamans require that the DAO already exists, so this is a bit of a "chicken and egg" situation
    - When DAO exists: select Shaman templates and we'll add to the DAO
    - When being created, it has to be a type of Shaman that has to be summoned
    - Will eventually need verified Shamans
    - Address and permissions, but would want to allow for metadata. These could be separate from the initial Summoner flow
    - Determine sensible default: do we want to lock Shamans?
    - Set admin, manager, governor locks -> separate initialization
        - This would remove some of the v3 flexibility if we default to this -- since Shamans can't be unlocked *ever* we may not want to lock by default
        - Option to lock up front, but not default it
        - Will need to be very explicit that they won't be able to use a Shaman after locking it
    - May not want to worry about this upfront -- can we create a solid Summoner that is flexible
        - 3 new initialization actions: Lock Admin, Lock Manager, Lock Governor
    - 
- Other Notes
    - There will need to be an approval step when adding an existing safe
    - Would we want to push this to a Gnosis Safe app?
    - Generally, keep the initial Summoning flow UX straight forward and can always enhance later (boosts as an example)
    - Will need a Summoning Flow that allows for *bringing your own Gnosis Safe*
    - similar to launching a safe minion? approve module in the UI
        - link to the safe for approval?
        - how does Dework handle this
    - Pattern for advanced rollout (importing)
        - This component is used throughout the design, so we could use this in our component library and shared utils
- Web 3 Recipes
    - Difficult for one site to direct users through steps -- videos do a good job here and allow for explanations throughout
    - This is something we should be mindful of as we're thinking about composition


### Additional Considerations 

- Fidelity of Designs (running & testing)
- Can we abstract away the design/fidelity when we are RAGING?
    - Focus more on Modularity & Functionality
- High Fidelity UX Design and Spec
- Get Raging 😡

## Moloch UI (Core)

### Enabling Flexible Nav (component library)
- Giving developers a toolkit where they can use the navigation (npm package)

##### Playing with Activity on the Event List (Timeline)

Alpha version of the component library should contain the core components that we **need** to operate our DAOs

### Core DAO UI - **What is the RageApp for the Core UI** 👇
- Proposals - ***Major Focus***
- Vault
- Boosts
- Members
    - List of read only data for the initial stage
    - Begin with read only and make more interactive over time
- Settings (read-only for now)
- Questions:
    - Do we want a Vault List?
        - Start with base rage quittable Vault and expand from there

**Where is the Marketplace!!!?**

- ~ next 3 months (no MVP - ALPHA)

### Component Library Concerns 
- If one component changes the state of another component
- How to manage sharing state between components in the library?
- Wrapper components
- How to manage stateful components in the library?
    - Typically leverage stateless components in the library

## Hub
- Main utility is list of DAO data
- Start with list and enrich with more data
- Add Ceramic profiles
- Being able to act on all proposals will be a core feature
- 1) List
    - Enrich with data over time
    - Delegate action soon after
- 2) Proposals feed
    - Transactions lego
    - Transfer UIs (in v2) pull from DAO context layer (and now will be a Redux layer)
    - Populate from proposal data 
    - Proposal on Core UI and on Hub is the same thing
    - Will need to work on base SDK or Redux will pass data in same format
        - Alternatively, get data right from proposal itself
- How much of the Hub and Explore is a shared app? How much is it DAOhaus?
    - Ranking based on user value -- user gets more value if it shows *all their DAOs not just Moloch DAOs*
    - An Explorer is much more valuable if it explores all DAOs not just Moloch DAOs
    - Do token DAOs have this explorability since they're not on a DAO platform? Is there something that they share?
        - How would we be able to surface this data if they're not all on a platform?
        - Would we need to do DAO by DAO fetches or is there a programmatic way to do this?
    - Worth waiting for the EIP that Isaac and MetaGov are working on
        - Adds common functions to get all DAO data (members, consitution, proposals, etc)
        - Early stages right now
    - Badges:
        - Display earned badges (issued by DAOhaus or others offering credentialing)

## Boosts
- Where do Boosts fit in?
- Goveranance Layer? Treasury Layer?
    - Standardize what goes where
    - How can we leverage the Safe UI around Treasury type things?
- Could be Boost specific: Governance related Boosts may slot into the Moloch Core UI
- 