⚖ Disputable Minions 😈

:balance_scale: Disputable Minions :smiling_imp:

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?

Proposal Information

Proposal Rationale

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.

  1. Coordinate capital via Moloch.
  2. Invest a significant portion of the Moloch assets into a DeFi project using a Minion.
  3. 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).
  4. Submit Minion proposal to transfer all assets held to the attacker contract.
  5. Those 51% of attackers vote to approve that proposal.
  6. 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.

Proposal description

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 openDispute() method.

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 isDisputed to 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! :tada: 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 0x4751dc98622f77BEf152Dd94f1bB12B37512c858


I actually had this on my wishlist for proposals I’d love to see in the pilot.

Just supported it, can’t wait to see it built!

1 Like

Disputable Minions Update!

Disputable Minions work like normal minions, but there’s a grace period before Minion proposals can be executed. During the grace period a Moloch Member can create a dispute (and pay the fees to do so). The Moloch members can then submit evidence to the alternative dispute resolution provider. From there if the dispute is overruled the action be executed, but if not then the proposal is invalidated.

You can learn more and check it out here: https://github.com/tkernell/disputable-minion

But wait… there’s more!

We created a DisputableMinion and submitted a dispute to the Aragon Court (on Ropsten):

We’re now adding more nuanced features for dispute fees so that Minion proposal creators have skin in the game when submitting proposals. Then we’ll be ready to move into stage 2 of the raid. This is where we’ll create an interface for the Disputable Minions. Users will then be able to access all the new Disputable Minion features along with the classic Minion functions we all know and love. Because voting takes time, we’re submitting the proposal for stage 2 of the Disputable Minion proposal now. That way we’ll be ready to roll as soon as we finish the contract upgrades!

Please reach out if have any questions and please vote to support the creation of Disputable Minions that can be arbitrated by the Aragon Court!



I noticed that the Court Dashboard wasn’t displaying the dispute information very well.

This is something we can work on in the next phase with the interface, but we have a bunch of tooling set up to support disputables in terms of pinning IPFS CIDs submitted on-chain, as well as defined schemas we currently use to help render information. We don’t have them well documented at the moment, but it shouldn’t be too hard to integrate the services into a frontend and make sure we’re publishing the disputes with the correct metadata formats!

1 Like