Minions are vulnerable to 51% attacks, but it doesn’t have to be that way!
Does a Minion introduce perverse incentives to the moloch dao structure? If you use a minion to invest some DAO assets in an external project, those assets are no longer available to members who choose to RageQuit. This breaks the cryptoeconomic alignment that makes Moloch magical. Can we maintain alignment, voice, and exit rights for while also using Moloch extensions like Minion?
Moloch Minion is a Moloch contract extension that can receive tokens, send tokens, and call external contracts. It has it’s own GuildBank and it’s own proposal process, however, for Minion proposals to pass they need to be approved by their parent Moloch. Think of Minion as a sidecar to Moloch that allows it to do more things in the wild world of Ethereum.
Moloch uses RageQuit to align incentives among members. This mechanism has been battle tested and works well. Moloch extensions such as Minion, however, do not have a RageQuit mechanism built in. They’re more of an external account that can interact with external contracts according to the will of Moloch.
In short, tokens in Minion do not have the same security guarantees or benefits of Moloch. If Moloch puts funds into the Minion, then a DAO member disapproves of a Minion proposal, when that member RageQuits they’d only get their proportional share of the Moloch GuildBank - not the funds in the Minion. This makes Minions susceptible to 51% attacks.
- Coordinate capital via Moloch.
- Invest a significant portion of the Moloch assets into a DeFi project using a Minion.
- Create attacker contract ‘owned’ by 51% or more of the Moloch’s members (could just be a new Moloch that the attackers are all members of).
- Submit Minion proposal to transfer all assets held to the attacker contract.
- Those 51% of attackers vote to approve that proposal.
- Other 49% of share members face choice between:
A) Ragequit to take their share of existing Guildbank tokens while abandoning any minion-controlled assets, or
B) Stay, allowing the proposal to take the Minion’s tokens, but keeping the option to reclaim their proportional share of assets in the Moloch GuildBank.
This attack allows 51% of ownership to steal up to 50% of everyone else’s assets.
If Minions were disputable the the voice of minority Moloch Shareholders could be protected. This might look like a disputable Minion and a DAO operating agreement. Then if a Minion vote passes a vote that Shareholders disagree with they could raise a dispute to have it reviewed by an alternative dispute resolution service within the context of a DAO operating agreement, investment mandate, etc…
Creating “disputable Minions” would create a delay window after Minion proposals execute where an alternative dispute resolution process could be used to block proposals that don’t conform to the DAO’s operating agreement and/or investment mandate.
There will be a delay window after every
executeAction() method is called, and during that delay anyone can raise a dispute by calling the
The struct for each Minion proposal shall have a param to determine the alternative dispute resolution (ADR) provider for that proposal. The only way to set this parameter on the Minion proposal struct is to pay the
openDispute() method specifying the ADR provider (from a hard coded list) and paying the ADR provider’s fee to the method.
To open a dispute anyone can call the payable
openDispute() method. This takes in a proposal ID, the dispute resolution provider (a hard coded list of providers and their addresses), and an amount of payment. It then checks that the proposal exists and that the correct amount was paid for the proposal provider selected. It then sets the Minion proposal
true and the
ADRprovider to the ADR provider specified.
To resolve a dispute the ADR provider calls
resolveDispute() and specifies the Minion proposalID. The
resolveDispute() method then checks that the proposal is under dispute and that the ADR provider matches
msg.sender. The ADR provider only needs to call this if the dispute was deemed invalid. If the proposal was deemed valid, however, then the ADR provide leaves the
isDiputed flag to true.
We add a check ot the Minion’s
executeAction() method so that it checks if a proposal is under dispute or not. Only non-disputed proposals may be executed.
Note: escalation is not built into the Disputable Minion. If an ADR provider with escalation is chosen they can escalate the dispute internally, but for the purposes of the Minion when it’s resolved it’s resolved and that’s it.
Team Information (For Funding Proposals)
- burrrata: I like DAOs, and as such participate in, design, and deploy a lot of DAOs and DAO related things.
- HeavyChain: Winner of multiple DAO Hack Month bounties for Minion extensions!
- RaidGuild: We might also bring in some RaidGuild designers and developers.
Funding Information (For Funding Proposals)
We’ve been exploring disputable Minions for a while and it’s time to take this project to the next level. This looks like:
- (500 ANT and 2-3 weeks) Fork the Minion contract to add dispute resolution.
- (500 ANT and 2-3 weeks) Fork the Minion interface to add dispute resolution.
This proposal is for 500 ANT to start work on the Minion contracts to integrate dispute resolution with the option to use the Aragon Court! Once the contracts are updated, we will then request another 500 ANT to create an interface for the disputable minions.
Funds can be transferred to