---
# System prepended metadata

title: v3 Haus Keeping (Wednesday) - TW Notes 3-2-22
tags: [' haus keeping', ' notes', v3]

---

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

# v3 Haus Keeping (Wednesday) - TW Notes 3-2-22

- Do we need to rename the contracts? Moloch > Baal > Baaloch > Pokebaal...?

#### Shares
- Loot named through a separate contract
- Shares named on the Baal contract
- Can DAO shares be transferred via their wallet/MetaMask?
    - Yes, shares can be transferred from one EOA to another EOA
    - No call required. Info already in subgraph.
- Tribute: historically included token approval. Has been removed in v3.
    - Could make a multicall to stack approval, funds transfer, and mint token to the person that transferred funds.
    - While proposal is open, the funds are still vulnerable.

#### Proposals
- Types cannot be easily discerned in the subgraph. Need to explore patterns to discern. 
    - Factors for ID have changed. Decoding is the way to go, although infinitely variable.
    - Details of the metadata attached to proposals will reveal patterns for DH to decode.
    - UI needs strong audit-ability for deciphering "wild west style" multi call stacks in custom proposals.
    - Can't store a million AVIs - need to decide on a subset.
    - [Tenderly](https://dashboard.tenderly.co/explorer) was building a decoder, but this tech is a ways out.
- Verify contracts via Etherscan via AVI: only works for verified contracts.
    - **Need a warning for unverified contracts.**
    - Make subgraph data less rich, has reverberations down to UX related to filtering/querying proposals.

#### Transfer (Line 256)
- Event is focused on shares. Does double duty. 
- Might add separate events for minting/burning.
- Discerned by: 
    - from Baal = minting. 
    - from a member = might be burning. 
    - to Baal = definitely burning. 
    - Member to member = transfer. 
    - Baal to member = verified mint.
- The from/to discerns the nature of the event.
- In v2.5 there are set share/loot events. Will that trigger this new mechanism? = yes.
- Loot minting/burning/transferring is the same format, although loot is it's own token and has it's own events. => place for additional cleanup to save ourselves from conditional logic and possibly removing the "loot" event.
- ERC-20 conditions should be kept for true transfers, but refine to mint/burn event.

#### Delegate
- Delegator always has to be the person delegating.
- FromDelegate will be you without delegation, or to the person delegated to.
- Triggers DelegateVoteChanged
- New shares automatically go to new delegate.
    - Delegation is 100%, no percentage. All or nothing.

#### ShamanSet
- Sending a shaman and designating its permission level as an admin in the DAO.
- A shaman = any contract that exposes certain functions, that can mint/burn, can even be an EOA (any address)
- Changes occur through proposal process
Admin = just ability to turn on/off (pause or unpause) transferrability of shares

Manager = can also mint/burn shares + loot, and set guild tokens, and convert shares to loot. The original conception of a shaman.

Governer (god mode) = all the additional parameters. Could brick the DAO by setting unlimited voting/grace period.

Permissions = 
0 = no permission
1 = admin only
2 = manager only
3 = admin + manager
4 = governance only
admin + governance
5 = admin + governance
6 = manager + governance
7 = admin + manager + governance

Shaman Parameters = 
- Voting period length
- Grace period length
- New Offering: how much ETH would need to be sent to a DAO to submit a proposal. *Important* to ensure user proposals don't get rejected. Correlated to spam protection.
- Period for submitting a propsal
- Quorom required for passing a proposal.
- Sponsor threshold: how much voting power is required, a number of shares threshold
- MinRetention = new dilution bound based on 100% scale. How much of the DAO would need to kill a proposal. "3" corresponds to 1/3 of the DAO or 33%.

UX considerations: how to adjust these settings? Work flow > proposal states

#### GuildTokenSet
- For a token to be RQ-able it needs to be on the default RQ list, set as a guild token. Otherwise, user can use an advanced RQ function to designate specific token to RQ.
- RQ can happen to a different address
- How complex will we want the UI for the advanced RQ transfer function? This feature is intended for the situation where a member RQs, recognizes that there is a broken token that needs to be bypasses in order to RQ successfully.

#### SharesPaused / LootPauses
- Designates transferrability.
    - True = transferrable
    - False = non-transferrable
- One might be paused without affecting the other.
- Greatly affects the permission nature, leads to thinking about the settings for quorom, shamans, etc.
- Allows the DAO to evolve in complexity as the community grows


#### Battle Testing
- Decide on the specific software/code/experience being tested
- Form intentional internal teams for identifying specific problems
- Allocate intention teams to be summoned in the testing DAOs
- Conduct specific post-game UX sessions to extract essential learnings from the war game.