Baal UX Worksession Notes (WIP)

--- tags: v3 --- # Baal UX Worksession Notes (WIP) Notes from the Baal UX worksession: overview and Baal lifecycle ## Overview - Baal docs from end of July -- need updates - Baal is a mix a Minion (Moloch v2) and a token contract - Lots of flexibility from this - There is a new *delegation* feature - **Shamans** are also new -- these are essentially superpowered Minions - Retains core functionality of Rage Quit, Sponsorship, Guild Kick - Talking about adding spam prevention - Can do proposals to change voting periods and token transferability - Token starts as non-transferable -- is this set at summoning? - Have to launch through Baal -- though there was some discussion about *bring your own token* but didn't make sense for v3 - What do the tokens represent? - Tokens *are shares* -- instead of integer shares, they're accounted in the storage in same way that ERC20 are (and are visible down to 18 decimal) - We can pick and choose what Baal features we want to support and can gradually integrate more over time - Proposals are much more flexible now -- - There is an *everything propsal* now which uses multi-class to do what we want (as opposed to different proposal types) - This could introduce complexity at the subgraph level, but we have more control on the frontend - We could say that a member proposal is a certain set of calls (can define them in this way) since they'd be the same every time - Can add as many functions as they want -- folks can keep tacking on - `multiSend` array -- need to iterate through this and look for relevant function signatures - Subgraph and data model: - Many of same *entities* -- DAO, proposal, vote, member -- pretty similar and can likely be shaped similar to how we have v2 - What about tokens and internal balances for members? - There's no longer a whitelist proposal -- there is whitelisting as an action proposal that calls `baal` and does a `setGuildTokens` - Token effectively needs to be whitelisted in order for it *to be Ragequittable* - Purpose of setting guild tokens is to calcuate Rage Quit - Anyone can send tokens to the Baal, but they're only Ragequittable if they're whitelisted - Internal balances are gone -- this could be an issue -- need to specify which tokens want to be Ragequittable - Rage Quit sends immediately, so do funding proposals ### Shaman - **Yeeter Shaman** - When someone sends x amount of ETH, it automatically assigns a certain set of shares/loot to that person - Bypasses the proposal, instead relies on Shaman's internal logic - Sending ETH/tokens -> assigns set of shares/loot - Yeeter Shaman contract can be set up in a way to have logic: if hits goal -> shares/loot, if not hit goal -> return ETH - The Shaman can only adjust `message.senders` loot and shares right now -- could we make this more flexible? - Need to whitelist each Shaman - Shaman factory -- need a flow to connect Shaman with a DAO - Some Shamans could be *Boosts* -- devs can build Shamans for DAOs and provide to others via Boosts - Shaman requirement exposes an `interface` called `memberAction` that determines how a person's loot or shares should be adjusted (down and up) ## Baal Lifecycle ### Summoning - **Summon deployment config**: - Set voting periods, transferability of loot and shares (these are separate configs -- transferability set separately), initial guild tokens, minimal and maximal voting period, grace period, loot paused, shares paused (look at `Baal.test.ts`) - voting periods can be adjusted at the proposal layer, but a later proposal can change the bounds of these periods - at summon, all summoners delegate to themselves - in Subgraph, may want to start tracking shares and loot as own entity if potentially transferable - At summoning DAO, could choose from previously whitelisted set of Shamans or alternatively could have 1 main Shaman with customizable parameters - Summon Baal and Shaman for different flavors - Can we have a Singleton Shaman? ### Members & Delegation - Can summon with multi-shareholders and multi-lootholders - *Transferable* shares can be sent outside of app (just like other tokens) - Delegates are now different -- similar to Compound way - Unsure if restricted to existing Members or anybody, but in Compound Governor can delegate to anyone (regardless of their holdings) - NFT: For a token to show up, Member has to call `claim` - Each Member claims NFT version of their shares/loot - If Ragequitting, their NFT zeroes out: zero shares and zero loot - If 0 loot and 0 shares it gives an empty token (could potentially make it a husk of an NFT or fail) ### Proposals - Proposals are all *multi-send* encoded -- can *chain together* many things - Can set `votingPeriod`, `proposalData`, `expiration`, `details` - `expiration`: at what block timestamp should this proposal no longer be executable - Do we want this to be hardcoded or should users set it? - If set to 0 there is no expiration on proposal - If sitting it won't block future proposals -- we may need to do some more investigation into why people will care about this setting - `details`: metadata that gets emitted -- don't need to store in the proposal but can still be emitted - Frontend can read via the Subgraph - Challenge: Subgraph parsing the actual `calldata` -- Subgraph can call view functions on contracts - Function that can parse arbitrary call data (similar to Gnosis `MultiSend.sol`) - Subgraph can call the view function with the proposal data from the actual proposal and receive back the parsed information and handle in a legible way in the Subgraph (which avoids having to decode on the frontend) - Benefit is greater gas efficiency in the proposals since we only need to store hash of the neessary information - ### Questions and Thoughts - Ability to change token name and symbol at a later point? - If we're bundling economic and governance rights into one thing it should likely be transferable - Is delegation restricted to existing shareholders in the Baal? - Removing proposal details (only having the hash) from the proposal will save on gas