Baal Run-through 2 & 3

--- title: Baal Run-through 2 & 3 tags: baal, magesmiths --- # Baal Run-through Round 2 & 3 The discussion was mainly around Ven's Design notes from the previous session. ## General **Minions** `Priority: Low` Minions are not required, as all proposals are multi-call transactions under the hood. But we will not remove Minions as a concept in general, as they can be useful in the following use cases: - Non-rage-quittable vaults/safes - Alternative voting models: Minions have more flexibility of Early Execution, so DAOs can have different Vaults that require different levels of Quorum. **Safes** `Priority: High` The standard way is for funds to be stored in the Baal contract, but theoretically everything can be stored and acted upon the Safe. The Baal contract just holds the logic. Priority for Minions is low, but priority for supporting Safes/Vaults (without the Minion functionality) is high. Users can create Safes & decide if they want to install a Minion. What happens if the DAO treasury receive funds, but DAO stores its funds in the Safe (or vice versa)? We should display the balances & enable the DAO to move funds from the DAO vault to the Safe (i.e. interacting with external contract). **RageQuit** `Priority: High` RageQuit is enabled only for the tokens in the Treasury, so Safe funds cannot be ragequittable. Based on the above, the default way to hold funds should still be via the DAO Treasury. During summoning, the summoner can provide an existing Safe or we help to deploy a Safe for the summoner **Shamans**`Priority: High` Shamans is a contract that the DAO can program to do programmatic updating/issuing/rebalancing/conversion of Shares & Loot. The current setup is mainly for onboarding. There are some risks of DAO takeovers, if Shamans issue Shares for yeeted funds. However, the DAO is able to vote & approve Shaman summonings and configurations. Once we introduce this concept, there's more space for innovation & education over Shaman interactions. Shamans are likely going to be bolt-ons, so we don't want to force any design / UI on it. Perhaps only the configurations & whitelisting portions should have a DAOhaus UI. - [ ] What is the safety valve feature on Shamans, if users don't agree with the Shaman logic? **Shares** `Priority: High` Both Shares & Loot are permissioned, so the DAO can control both the transferability of Shares & Loot. They are have ERC-20 functions but they are not ERC-20 tokens per se. If shares transferability has been turned on, Shares can be transfered on Metamask like an ERC-20 token. Loot cannot be transferrable from Metamask (using existing ERC-20 standards), but should be enabled via our DAOhaus UI. :::info This is dependent on the Mystics' last decision on shares vs loot transferability. ::: **Delegation** `Priority: ?` We need to show delegation of Shares & voting power in the UI. Any member can delegate to any address. No tokens are being transferred - the voting weight of the delegator gets assigned to the delegate. As a delegate, you cannot ragequit any of the shares delegated to you. On the member's page, we need to show actual balance and delegated balance. ## Summoning **Customising ERC-20 Parameters for Shares/Loot** `Priority: ?` Summoners can name a token for Shares only & assign images. Summoners provide Share array & Loot array for Members. Summoners do not need to enter the token supply, but it is under the control of the DAO. We are not trying to create a new economic / token model - we are just using the ERC-20 features to help introduce greater fractionalisation. **Whitelisting/RageQuit tokens** `Priority: High` Token whitelisting is not required - the new process is basically just indicating which tokens can be ragequitted. **Min/Max Voting Periods** `Priority: Low` Summoners can now set Min/Max voting period per proposal. To start, we have Max voting period to always equals to Min voting period, so users don't need to toggle & adjust another Voting period parameters. From a UI POV, this will start looking like the current one (i.e. 1 voting period), before giving users more granularity in controls. Since users can still interact directly with the contracts that are not taken care by the UI, we should show UI alerts on these situations. **Grace Periods** `Priority: ?` For grace period, there is no Min/Max. This can be adjusted in DAO Settings later on. On the contract level, when a change in grace period is executed, every proposal after will ahve the new grace period. > The contract is infinitely more complex & configurable for advanced users, but the UI has to simplify this for all users. In the future (aka `Priority: Low`), we can set * A YES/NO transferrability for Loot & Shares at summoning. * Bolt-on Shamans (Forged Shaman contracts) ## Proposals **Are proposals in a queue, or do you set proposal velocity?** Proposals still go in order, but if the processing fails (e.g. execution fails & reverts), the failed proposal get skipped to the next one. **Retry of failed proposals** `Priority: High` DAOhaus UI should flag failed transactions for users to retry the processing/execution of the failed proposal later. It's really easy for Proposals to fail, so we should pay more attention to helping users test & forecast these failures. **Proposal Expiry** `Priority: Low` Users can set a limit to not process proposals after certain time period has passed. This is set when every proposal is submitted. We can offer proposal expiry suggestions based on the DAO proposal configurations or different types of transactions (e.g. DeFi, etc.) **Sponsoring Proposals** `Priority: ?` Sponsoring used to start the voting on proposals, causing a gap between Sponsoring & Voting and drop-offs. Now, sponsoring does not require any deposits - basically a member signals that this proposal should go into voting. From a UI POV, sponsoring and submitting a proposal can be done in 1 step (e.g. via a Checkbox), signalling that the user is agreeing and sponsoring. Auto-voting is however not possible, so users will still need to do 2 steps: Submit+Sponsor, followed by Vote **Proposal Period** The new design now looks like there's no need to set any generic velocity (it's basically seconds). ::: info This Proposal Period section is dependent on whether the Mystics will add in a configurable time period (grace period) between voting and processing, so members have the time to RageQuit ::: ## Flashloans `Priority: Low` If the DAO had 100 ETH, someone can borrow the ETH and return it in 1 block, paying the DAO some interest. Is enabling flashloans a good thing? This gives the DAO more revenue with zero risk. RageQuit can happen as well as the transactions will be ordered in the block based on gas costs.