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