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

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