Daohaus
Daohaus can add Moloch v3 governance to an existing Safe
Daohaus can connect Moloch v3 governance to an existing Safe while keeping assets at the same treasury address. The Safe must authorize the governance contract as a module, and the deployment must reference that Safe. Members then use shares, the DAO's voting tokens, to decide treasury actions. Factory compatibility and remaining owner permissions determine how this arrangement operates. Designating the retained Safe as the main treasury also brings its eligible assets within the DAO's ragequit mechanism.
Last updated ·
Key takeaway: An enabled governance module adds a transaction path alongside the Safe's existing owner permissions.
The existing Safe keeps custody of the assets
Attaching governance changes which contract can authorize transactions against the Safe. It does not require sending the existing treasury balance to Baal, the Moloch v3 governance contract. The Safe remains the asset-holding account, while Baal applies the DAO's governance rules. A treasury payment draws on assets held by the selected Safe and sends them to the recipient specified in the approved action. Membership shares record governance and financial weight; they are not the payment asset. The retained Safe can hold native coins, ERC-20 tokens, and NFTs. Each proposed action must address the relevant asset type.
The summoner connects deployment with the Admin App
The deployment route determines whether the Admin App can recognize the new organization. Its subgraphs index the base summoner factory, which connects deployed contracts with application records. Subgraphs supply structured records for DAOs, proposals, votes, and members.
The indexed base factory
A compatible deployment uses that base factory directly or a Higher Order Summoner that calls it. Custom configurations can retain app indexing without requiring the standard setup form to expose every option. Supplying an existing Safe is a supported factory capability. That fact does not establish that every summoning interface supports the same configuration.
Network and contract addresses
The Safe and chosen summoner must operate on the same blockchain. Bringing a Safe reuses an account on that chain; it does not bridge its assets. Factories and templates have network-specific deployment addresses. The setup must identify those contracts for the chain where the treasury already holds funds.
Who can authorize transactions after governance is added?
Baal authorizes actions through the DAO's rules, while the retained Safe may still have owner and module permissions outside that voting process. The actual authority depends on those configured permissions, not simply on the DAO appearing in an app.
Safe owners and enabled modules
Enabling a governance module does not automatically remove the Safe's existing owners. Modules operate alongside the owner-signature mechanism. The existing owner threshold therefore remains relevant unless an authorized configuration change alters it. Other enabled modules also need consideration because their permissions may provide additional ways to execute Safe transactions.
Shaman permissions
Shamans are external contracts that receive specific DAO permissions. An admin Shaman can change membership-token transferability, while a manager Shaman can mint or burn shares and loot. A governor Shaman can change governance settings and cancel proposals during voting. These powers operate outside ordinary proposal approvals. Granting them can affect who holds financial rights over the existing treasury, even when its Safe address stays unchanged.
Shares and loot allocate claims on the retained treasury
The initial membership allocation determines how members divide rights over the treasury that already exists. Shares combine voting power with financial rights, while loot carries financial rights without voting power. Both are ERC-20 membership tokens in Moloch v3. Their balances have a different purpose from the native coins or other tokens held inside the Safe. Allocating membership units changes the distribution of treasury claims; it does not require distributing the treasury's assets immediately.
Issuing additional shares or loot changes the combined supply that supports proportional claims. A manager Shaman's minting authority therefore has financial consequences for existing members.
Resolve a missing module permission before another setup attempt
An existing-Safe setup that lacks the intended Baal module's authorization cannot establish the planned governance connection. Repeating the same attempt leaves that permission gap unchanged.
- Both the selected factory and the retained Safe operate on the same network.
- The treasury parameter identifies the Safe whose assets must stay in place.
- Admin App integration uses the indexed base factory, including compatible Higher Order Summoners.
- Owner approvals satisfy the Safe's threshold for enabling the exact intended Baal module.
- The enabled-module record matches the governance contract selected for that Safe.
Safe owners can correct missing module authorization through the Safe's approval mechanism. Retry the setup only after the authorization and treasury address agree with the intended configuration. A confirmed module entry establishes permission; matching treasury balances alone do not establish it.
Can a passing vote move the retained Safe's funds immediately?
A passing vote still needs the configured voting and grace periods to end before proposal processing can execute its actions. Quorum does not shorten those periods. The proposal also remains subject to its expiration, the applicable quorum and retention requirements, and the preceding proposal's state. Those settings govern the authorization path; the Safe supplies the assets for the approved action.
The Admin App distinguishes Ready to Execute from Action Failed. A recorded approval or processing transaction alone does not establish that the recipient received the asset.
Treasury designation determines the member's exit rights
The retained Safe's designation decides whether its assets belong to the main treasury or a sidecar. A v3 DAO has one main treasury and can attach additional sidecar Safes. Sidecar Safes do not give members ragequit rights over their assets. The main treasury supports proportional token withdrawals when members burn shares or loot. The Safe can also hold NFTs, which standard ragequit cannot redeem proportionally. This choice determines whether members have exit rights over funds already held at that address.
Things people ask
Do existing Safe signers automatically receive voting power in the new DAO?
A Safe signer does not gain DAO voting power solely from signing authority. The DAO's share allocation and delegation determine voting power. Starting members receive the share amounts specified during setup; later proposals can allocate additional tokens. A Safe's owner list therefore does not establish its DAO electorate.
Which networks have deployment records for the governance and treasury components?
Moloch v3 templates, summoners, and Safe templates list deployments on Ethereum mainnet, Gnosis Chain, Polygon, Optimism, Arbitrum, Base, and Sepolia. Interface support for a particular existing-Safe configuration is a separate requirement. Sepolia is a test network, and contract addresses must match the chosen network.
Will bringing a v2 DAO's Safe also copy its membership balances?
Reusing a Safe does not itself reproduce a v2 DAO's membership allocation. To preserve existing membership, the new v3 organization needs explicit allocations that reproduce the intended shares and loot. Summoning or a later proposal can supply those allocations.
Does retaining the Safe eliminate deployment and proposal costs?
Retaining the Safe avoids relocating its assets, while deployment and on-chain governance operations still require network gas. The configured proposal offering is separate from gas. Baal requires that exact native-token amount when the submitter's voting power falls below the sponsor threshold. A submitter who meets the threshold can self-sponsor without a required offering.
Are Shaman contracts compulsory for an existing-Safe DAO?
Shaman contracts are optional when an existing-Safe DAO uses ordinary proposal governance. The DAO can appoint them during setup or later through governance if the relevant roles remain unlocked. These administrative powers are separate from Baal's permission to execute approved actions through the Safe.
Where does the Admin App show the retained treasury address?
The Settings view lists the treasury's Safe contract beside the Moloch v3 contract and membership-token contracts. The Safes view also displays the main treasury address and the addresses of additional Safes. Those separate entries help distinguish the retained treasury from a governance contract or a sidecar.
Can members request the Safe's native coin through an ERC-20 transfer proposal?
The proposal menu separates Network Token Transfer from ERC-20 Token Transfer because they target different asset types. A request for the network's native coin belongs to the native-token proposal type. An ERC-20 request identifies a token contract, even when both assets appear in the same retained treasury.
Can an ERC-20 already in the Safe become the DAO's voting token?
The existing-token deployment path requires Baal-compatible shares and loot contracts, with ownership assigned to the new DAO. An arbitrary ERC-20 balance in the Safe does not establish that compatibility. Treasury holdings and the contracts that implement voting or loot are separate configuration choices.