---
# System prepended metadata

title: v3 Vaults
tags: [v3]

---

---
tags: v3
---

# v3 Vaults


**Goal**

Enable v3 DAOs to add extra gnosis safe vaults.

- Add baal as a module to a gnosis safe 
    - existing safes and/or deploy a new safe
    - seems the DAOs main treasury safe would be the module on extra vaults
- Track the connection in the subgraph
- Enable removing the DAO as module
- Allow naming and hiding


**w/out minion (shim contract) - IDEAL SOLUTION**
- no new contracts/factories needed
- use the gnosis UI to add the module
- ideally need a method to tie the safes to the baals in our subgraph
    - if the module addition event is on the individual safe contract it would require indexing all safe contracts - NOT GOOD
    - alternatively, if we find another way (api/subgraph) to detect a baal is a module on a safe we can prompt the user to 'name' the safe, make a tx to a metadata solution like the poster contract and integrate with that
    - poster will allow renaming/hiding through our subgraph

**TO DO for this flow:**
- Identify a way to query gnosis api/subgraphs for safes by module address
    - kinda like the the '/owners/{address}/safes/' endpoint but '/modules/{address}/safes/'
- Define the user flow to add/remove
    - might be initiated in the DH UI, but most of it happens in the safe UI
    - could potentially be done through the zodiac module in the safe app
    - prompt to remove/replace signers on existing safes?
- Can we also support launching a new safe with just the baal as a module
    - in the DH UI


## w/ minion
- would be able to add some extra functionality in the shim
- enables cross withdraw from v2 w/out proposal
    - might help upgrade paths
- enables early execution
- this requires code updates to current minion
    - some internal logic from moloch to baal
    - member checks
    - quorum checks
    - submitProposal
- need a factory on each network
- UI deployment would be similar
    - 2 modes to launch a safe and to bring your own







