Fiduciary Agreements and Minority/Passive Stakeholder Protections for DAOs



One of the benefits of a traditional legal structure is the established body of law and regulations that define fiduciary duty and protect the interests of minority and/or passive stakeholders in a shared enterprise. DAOs on the other hand, must explicitly define all the rules and protections within their internal governance process.

The following situation is a good illustration of the problem with collectively managing funds using a DAO that we would like to solve:

A simple DAO is deployed with a vault that holds the organizations collective funds, in order to move an arbitrary amount of funds from the vault for an arbitrary purpose a vote is required with a simple majority to pass.


There are two fundamental issues with this approach, (1) it assumes that all stakeholders will pay attention and vote so that true majority can be reached to approve of proposals, and (2) there are no protections for minority or passive stakeholder interests. If a bad proposal is presented a relative majority of stakeholders is required to act in order to prevent it from passing.

These challenges become particularly problematic when you consider certain types of “malicious proposals” which are designed to incentivize people to vote to approve even if they would normally disagree with the proposal. The most straightforward example of this is a proposal which moves all funds into a contract which then releases funds to all stakeholders who voted to approve the transfer.


In a traditional organization there are legal provisions that provide recourse for stakeholders in such situations, but in the case of a DAO where the stakeholders and proposers may not be legal entities (they may be pseudonymous or even other DAOs), such retro-active protections would not be particularly effective deterrents.

One potential way to solve this problem would be to use a subjective oracle mechanism like the propose Aragon Court to enable a single individual to raise a dispute and prevent a proposal from being executed. This could be accomplished by requiring proposers to agree to a “fiduciary agreement” in order to submit a proposal. The agreement would have them put up a deposit which could be retrieved after the vote is completed. If anyone feels the proposal does not meet the standards set in the fiduciary agreements they can raise a dispute by putting up an equal deposit. The proposal could be immediately canceled, and the dispute could be settled. If they win they take their counterparties deposit as profit.

Such a mechanism would allow an organization to enforce some standards on the types of proposals that can be made, preventing obvious malicious proposals, but could also be used to set a subjective standard for the purpose of the funds–much like a traditional organization would have bylaws. This would set clear expectations and provide protection for minority and passive interests because it would only take a single honest actor to prevent at bad proposal rather than a relative majority of stakeholders.

Uncomfortable Thoughts On Decentralization

Great post! Using the Aragon Court to protect against 51% attacks in DAOs is one of the most important use cases for it.

In my opinion, rather than cancelling/delaying open votes, I would add an initial stage to proposals when they can be flagged for review by the Aragon Court. This could be a separate app, so the Voting app doesn’t need to know anything about the fact that the Aragon Court may have been involved.

This also gives a clear timeline for proposal execution once a proposal is finally created in the Voting app, which we wouldn’t have in case an open vote can be delayed at any point. This separation also allows to easily transition from another proposal vetting mechanism (e.g. a council curating proposals) to the one proposed here.


I think the initial stage for reviews makes sense, but do think that there is value in allowing for a process to cancel/delay active votes. Specifically there may be instances where a vote begins but new information is discovered such as a contract vulnerability that would warrant delaying or cancelling the execution of a proposal. However, such a process introduces concerns that an attacker may be able to disrupt the smooth operation of a DAO by using disputes as a way to delay arbitrary proposals indefinitely.

With that in mind (per our one on one discussion) the following modification to this proposal might work best:

There is a proposal review period where a dispute can be raised by putting down a deposit equal to that of the proposer. If there are no disputes within this period, the proposal would proceed to a vote. A dispute can still be raised while the vote is active, and such a dispute would “pause” the vote until the dispute is resolved. If the dispute is not dismissed, then the vote is cancelled. If it is dismissed then the vote would resume. For each dispute the required deposit for initiating the dispute would double, ensuring that repeated disputes become progressively more expensive.


I agree that being able to pause the proposal even when it is already being voted on could be beneficial for the cases you mention.

From our conversation, we talked about increasing the size of the deposit once the review period is over by a factor of 5-10x. Because of this significantly higher deposit requirement after the review period has ended, we can expect that after people have taken the time to vote, only major issues or new information being discovered will cause disputes during voting time. It can also be expected that whoever creates the dispute is certain enough that it won’t be dismissed and they will recover their deposit.

So the cost for disputes would be:

During review period: deposit(d) = 2 ^ d * PROPOSAL_DEPOSIT
During voting period: deposit(d) = 2 ^ d * VOTING_PERIOD_FACTOR * PROPOSAL_DEPOSIT

  • d is the number of disputes that have already been dismissed for the proposal, for the first one it is 0. Disputes created during the review period should carry to the voting period.
  • VOTING_PERIOD_FACTOR determines how much more expensive is to pause a proposal and create a dispute during the voting period.