Minion Design Space

# Minion Design Space Generally speaking, a minion assists a DAO with *tasks* that the DAO cannot execute on its own. More specifically, minions can take all kinds of forms and help their DAO with all kinds of different tasks in many kinds of ways. The minion design space has the following dimensions: 1. Task domain 2. Breadth of task scope 3. Control 4. Execution scope 5. Value storage 6. Level of user abstraction ### Task domain * **External to the DAO**: A minion can connect its DAO to the outside world, allowing it to interact with smart contracts, protocols, and apps outside of the DAO itself. * Make DeFi trades and actions * Manage ENS names for the DAO * InterDAO actions * Claim airdropped tokens * Mint/Buy/Sell digital collectibles * * **Internal to the DAO**: A minion can also augment a DAO's internal operations, helping to manage internal DAO affairs that the core DAO itself cannot explicitly handle. * Manage DAO roles by minting/transferring NFTs * Setting the DAO's custom DAOhaus theme * Setting the DAO's social links on DAOhaus * Manage the DAO's custom content on DAOhaus * ### Breadth of task scope * **Generic (any task)**: The original minion. A vessel through which a DAO can execute any arbitrary transaction * **Single category of tasks**: Multiple built-in functions (often wrappers around other smart contract interfaces) all relating to the same objective for the DAO. * e.g. a collection of DeFi interfaces, DAOhaus settings, a set of DAO to DAO interaction functions, etc. * **Single task (specialized)**: Built-in function(s) geared towards a single task * e.g. ENS management, NFT bank, etc. ### Control * **DAO control**: the typical minion will be controlled by the full DAO, i.e. have their actions triggered by via the standard DAO proposal flow * **Delegated control**: other minions can be configured to have actions triggered by other means, such as: * a single DAO member * a multisig of DAO members * even another minion! * **Joint DAO control**: two DAOs could control the same minion, much like a multisig * The advantage over using a Gnosis Safe owned by both DAOs would be the ability to auto-create a proposal in both DAOs to trigger a joint task * For example, this could be used for alliances between two DAOs ### Execution scope * **Full transaction execution**: Standard minion * **Voting transactions only**: This option offloads execution of the desired transaction(s) to another contract such as a Gnosis Safe. The minion itself acts solely as a connection point between the DAO and the Gnosis Safe, signing within the Safe on behalf of the DAO. * *Benefits*: * The DAO gets access to all the Gnosis Safe Apps * The ability to use WalletConnect to interact with the long tail of dapps * *Drawbacks*: * Only owners of a Safe can create transactions, so the DAO would need to delegate that role to an individual member (compared to a standard minion which can be configured to allowe anybody to create transactions) * Only that delegate would be able execute transactions (compared to a standard minion which can be configured to allow anybody to execute) * Managing that delegation (e.g. appointing a new delegate as a signer in the Safe) would require the DAO to use a second minion. ### Value storage * **Can store value**: most minions will be able to store, receive, and send value (i.e. tokens) * **Don't store value**: some specialized minions may be designed solely to execute transactions on external smart contracts without transferring value. These will be rare, but may be desireable * for example, a minion that is purpose-built to withdraw tokens from a protocol that allows withdrawn tokens to be relayed to another address (i.e. the minion's DAO) ### Level of user abstraction * Raw bytecode * ABI transaction builder * WalletConnect * Forged (specialized UI) * Pre-baked (one-click action) # Minion Components #### Contract(s) A minion contract can take the following forms: * An empty vessel that can execute arbitrary transactions (i.e., bytecode) when approved by a DAO proposal * Built-in functions that execute logic within an established scope. These functions can be simple wrappers around other smart contract interfaces or custom logic. #### User interface A minion UI influences it's level of user abstraction. * The simplest UI is a form into which a user can enter an address and transaction bytecode for the minion to execute. * The next simplest UI is an ABI transaction builder * Minions can also have specialized UIs that feel more like a fully fledged application (Forged Minion) * Or even pre-baked transactions that can be initiated with just a single click. # Minion Primer ## What is a Minion? Moloch DAOs are designed to slay Moloch, [the god of coordination failure](https://slatestarcodex.com/2014/07/30/meditations-on-moloch/). To do this well, Moloch DAOs have intentionally minimal capabilities: they can accept members, store shared funds, and process votes on which new members to accept and how to spend those funds; and that's about it. A Minion is an assistant. It helps the DAO do things it otherwise can't. For example, a Minion can interact with other smart contracts on behalf of its DAO and hold assets that the DAO can't hold (like NFTs). In fact, the possibilities are virtually endless. You can think of a Minion as an extension of a DAO that can be configured to do almost anything. Here's a basic overview of how a Minion works: 1. A DAO member creates a transaction that they want the minion execute. 2. They submit that transaction to the Minion, which stores the transaction info and then initiates a Yes/No proposal in the DAO. 3. The DAO votes on the proposal. 4. Anybody can attempt to execute the transaction from the minion; if the proposal passed, the minion will execute the transaction ## For DAO members If you're a member of a moloch DAO, a minion gives you and your DAO access to the full richness of the Ethereum ecosystem. With a minion, your DAO will be able to interact with any Ethereum smart contract, which means your DAO can use any DeFi protocol, mint tokens, hold NFTs, interact with other DAOs, and a whole lot more! Let's take a look at a couple examples of what a Minion can bring to a DAO: #### NFTs Because Moloch DAO shares grant members proportional ownership over the assets in the DAO bank, only fungible tokens can be held in that bank. With the rise in popularity of non-fungible tokens (NFTs) to represent digital things -- like art, metaverse real estate, domain names, etc. -- a lot of DAOs are thinking about how they might own and manage NFTs. Enter Minion, which can hold NFTs on behalf of it's DAO. Let's say a DAO wanted to purchase a parcel of real estate on Cryptovoxels (like Raid Guild did to build [its castle](https://www.cryptovoxels.com/parcels/2575)). To do that, a member of the DAO would create a new minion proposal to make the purchase. The DAO would vote, and if the proposal were to pass, the minion would execute the purchase and then own the new parcel! From there, the DAO could, via its minion, make access control and other adjustments to its property. Eventually, the DAO could even have the minion sell the parcel, with any proceeds from the sale going into the main DAO bank! #### DAOs as members of other DAOs Imagine a DAO that maintains and governs a web3 product that is built on top of another protocol. To protect itself against platform risk and to advocate for new protocol features, the product DAO would want to participate in governance over the protocol. In other words, if that protocol were governed by a DAO, then the product DAO would need to become a member of the protocol DAO and vote on proposals. A minion makes that possible. The minion itself would be the member and execute votes based on the product DAO's decisions. Because a minion can be configured to do pretty much anything, the DAO could even decide to assign a delegate to make decisions in the protocol DOA without requiring a full vote in the product DAO. Here at DAOhaus, we're using some of these ideas to allow DAOs to govern the DAOhaus platform directly. #### Separation of concerns Use multiple minions to handle different types of tasks or manage different buckets of funds. ## For devs If you're a developer, Minions open up a large space for you to build cool new stuff for DAOs. Here's are a few dimensions of the design space: 1. Task domain 2. Breadth of task scope 3. Control 4. Execution scope 5. Level of user abstraction ### Task domain * **External to the DAO**: A minion can connect its DAO to the outside world, allowing it to interact with smart contracts, protocols, and apps outside of the DAO itself. * Make DeFi trades and actions * Manage ENS names for the DAO * InterDAO actions * Claim airdropped tokens * Mint/Buy/Sell digital collectibles * * **Internal to the DAO**: A minion can also augment a DAO's internal operations, helping to manage internal DAO affairs that the core DAO itself cannot explicitly handle. * Manage DAO roles by minting/transferring NFTs * Setting the DAO's custom DAOhaus theme * Setting the DAO's social links on DAOhaus * Manage the DAO's custom content on DAOhaus * ### Breadth of task scope * **Generic (any task)**: The original minion. A vessel through which a DAO can execute any arbitrary transaction * **Single category of tasks**: Multiple built-in functions (often wrappers around other smart contract interfaces) all relating to the same objective for the DAO. * e.g. a collection of DeFi interfaces, DAOhaus settings, a set of DAO to DAO interaction functions, etc. * **Single task (specialized)**: Built-in function(s) geared towards a single task * e.g. ENS management, NFT bank, etc. ### Control * **DAO control**: the typical minion will be controlled by the full DAO, i.e. have their actions triggered by via the standard DAO proposal flow * **Delegated control**: other minions can be configured to have actions triggered by other means, such as: * a single DAO member * a multisig of DAO members * even another minion! * **Joint DAO control**: two DAOs could control the same minion, much like a multisig * The advantage over using a Gnosis Safe owned by both DAOs would be the ability to auto-create a proposal in both DAOs to trigger a joint task * For example, this could be used for alliances between two DAOs ### Execution scope * **Full transaction execution**: Standard minion * **Voting transactions only**: This option offloads execution of the desired transaction(s) to another contract such as a Gnosis Safe. The minion itself acts solely as a connection point between the DAO and the Gnosis Safe, signing within the Safe on behalf of the DAO. * *Benefits*: * The DAO gets access to all the Gnosis Safe Apps * The ability to use WalletConnect to interact with the long tail of dapps * *Drawbacks*: * Only owners of a Safe can create transactions, so the DAO would need to delegate that role to an individual member (compared to a standard minion which can be configured to allowe anybody to create transactions) * Only that delegate would be able execute transactions (compared to a standard minion which can be configured to allow anybody to execute) * Managing that delegation (e.g. appointing a new delegate as a signer in the Safe) would require the DAO to use a second minion. ### Level of user abstraction * Raw bytecode * ABI transaction builder * WalletConnect * Forged (specialized UI) * Pre-baked (one-click action)