Minion V2 improvements

[dekanbro]

---

name: DHIP Request about: Create a DAOhaus Improvement Proposal title: 'Minion V2 improvements' labels: DHIP assignees: '@dekanbro'

Proposal Idea: Minion V2 improvements

Proposal Submitted By

Dekanbro

Summary

The current Minion has some limitation. Through user feedback and battle testing we have found the places where the minion works well and other places where it could use a few updates.

Why should we do this?

Current minion is limited to single calls, and does not have much flexibility around execution conditions. Because of this we end up making a lot 1 off minions for many different use cases. These one offs are hard to track and hard to maintain.

We will be better off if we can make a set off contracts that are flexible to meet 90% of cases.

List of things that minion v2 could have and become much more flexible.

Proposal Minion

• Multi-call support: If we can chain multiple calls together in a single proposal we can do many more complex operations. Currently with single call if some as simple as needing an approval requires 2 proposals.
• Early execution: When summoning a new minion a minimum quorum can be set which allows a minion action to be executed immediately after quorum is met, before voting ans grace period has been completed
• Conditional execution: Execution can be limited to some requirement that is meet by an external contract first. This could be a price oracle, voting oracle, an another proposal from a different dao, number of shares a member has (or does not have). Really anything that could be worked into an arbitrary contract could be a condition.
• Treasury deposits: a minion can request funds from the main treasury in the same proposal that it does arbitrary contract calls.
• Change ownership: ownership of a minion can be changed from one dao to another to help with dao upgrades, mergers and acquisitions.
• Gas optimizations: we can save alot of gas by saving less in contract storage and hashing operation for execution.

Escrow Minion

• new member proposals with multi escrow tribute where you can tribute multiple nfts, or erc20s, or a mix of the 2 in exchange for shares, loot, or funding.

Anything else you'd like to add?

current working repo https://github.com/HausDAO/MinionSummonerV2

Skills Needed

• Solidity Development
• Front end Development

[spengrah]

Security concern

If a DAO member can permissionlessly deploy a new minion with an early execution quorum of their choice, and then submit a proposal for that minion with treasury deposits, then they can effectively steal funds from the DAO at will.

Example

I have 5% of the shares in a DAO with $100k in its bank. In just 4 transactions I can steal all the DAO's funds. All of this can be done without approval from the DAO, so I can do this nearly instantaneously. A more sophisticated attacker could even create a new contract that bundles these transactions into one.

1. I deploy a new minion with a <= 5% early execution
2. I submit a new proposal to that minion that uses the treasury deposits feature such that the proposal action would both move funds from the DAO to the minion and then send those funds to myself
3. I immediately vote Yes with my 5% of shares, triggering the early execution condition
4. I Immediately execute the action, which sends the $100k to myself

Potential Mitigations

• require a DAO proposal to deploy a new early execution minion (allowing the DAO to ensure that minions with dangerously low early execution quorums don't get deployed)
• prevent early execution minions from using the treasury deposits feature (forcing a DAO proposal to send funds into the minion)

[dekanbro]

@slgraham this is a valid comment. The early execution and treasury deposit features do not work together. The treasury deposits always have to wait the full voting period and grace before funds are transferred to the minion.

So if a proposal is made that needs funds those funds must have already been deposited into the minion from a previous proposal or from a direct deposit from another source outside the DAO treasury.

A few other safe gaurds: only a member can make a proposal and early execution only works with no NO votes.

One thing that could happen, and potential DOS attack

• a proposal is made to do a treasury transfer and execution requires those transferred funds, the proposal is contentious passing by a small margin.
• the no voters create a new proposal to spend those funds on something else, even though a minority in the DAO they can get quorum for early execution.
• once the initial treasury proposal is initiated the NO voters execute their transaction first before the original proposal has a chance to execute.

This is mitigated by early execution needing unanimous yes votes, but still could be a risk with very low quorum and a highly coordinated attack.

[spengrah]

@dekanbro this is great! I like the unanimous YES requirement a lot.

To further protect against the potential attack you identified, it might be worth requiring that minions with an early execution threshold below 50% be deployed via a DAO proposal. That way the DAO as a whole decides whether to accept the risk, and its not possible for an individual member to deploy a small-quorum minion.