As a set of smart contracts deployed to a blockchain, Aragon organizations are able to operate securely, transparently, and reliably. They can define permissions, manage funds, and require stakeholders to vote on actions. An organization can even perform arbitrary transactions and be used as a collectively-managed, permissioned Web3 wallet.
This functionality is incredibly powerful but practically quite limited without the ability to impose subjective constraints. Participation in organizations requires trust, so in order to make Aragon organizations more useful, we need to implement mechanisms that minimize the amount of trust required. Proposal Agreements do that by allowing organizations to define expectations for users who submit proposals, and the Aragon Court provides a process for resolving disputes when participants disagree on whether a specific proposal meets those expectations.
This post discusses how an organization will be able to create a Proposal Agreement, what common use cases proposal agreements enable, and what dependencies on the court need to be considered when an organization chooses to use a proposal agreement.
Creating a Proposal Agreement
A Proposal Agreement is a human-readable document stored on IPFS and an associated Aragon forwarder that is used to interact with an Aragon Voting app. When the court is released, an organization will be able to use the App Center to install and configure a proposal agreement.
During this process, the following parameters must be defined:
- Agreement Text: An IPFS-hosted text document describing the agreement terms
- Deposit Collateral Requirement: An amount of tokens that must be deposited as collateral to use the forwarder
The agreement text is what defines the requirements for valid proposal submission. For example, an organization may want to require that all proposals have a link to a Github issue or forum post so that the proposal has a clear space for discussion. It may require that specific information be included in the post like the justification for the proposal. It may have requirements about the nature of the proposal itself, like whether the proposal represents a conflict of interest for the proposer or whether it attempts to bribe or manipulate the organization’s stakeholders.
The deposit collateral requirement defines an amount of ERC20 tokens such as ANT, DAI, or even the organization’s native token which must be deposited as collateral when submitting a proposal. If the proposal is disputed, the proposer’s deposit will be at risk. Having a large deposit requirement will ensure that proposals are carefully considered and may result in fewer proposal submissions.
The address of the proposal agreement forwarder needs to be granted permissions in the organization so that it can Create, Pause, and Cancel votes in one or more of the organization’s Voting apps. More details on how proposal agreements fit into Aragon’s permission architecture can be found in the whitepaper.
Utility of proposal agreements
The introduction of proposal agreements and the Aragon Court adds a lot of flexibility and power to Aragon organizations. Being able to specify subjective constraints in human-readable text allows for complex governance processes to be quickly adopted and enforced. It also enables organizations to better protect the rights of passive and minority participants, by requiring only a single active participant to create a dispute.
The following are examples of how proposal agreements could be used
- Encoding responsibilities to stakeholders: Organizations that pool resources and direct them toward some common goal can encode the expectation that the resources will be used to further the common goal within the proposal agreement terms. If a proposal is made to use the resources for some other purpose, a dispute can be created.
- Defining procedural requirements: The process for creating and presenting a proposal can be defined in the proposal agreement terms. An organization may require a proposal to link to a specific location for discussion, define how users should be notified prior to a proposal being voted on, or require that proposals related to code upgrades point to the results of a professional audit before being considered.
- Bounty and Milestone Payments: Organizations may want to release funding based on bounty completion or milestone completion, for example, when using Autark’s Projects app. The organization can have recipients submit proposals through a proposal agreement to request the payout, and then someone can dispute the payment if they feel the task or milestone wasn't completed correctly.
- Curated Lists: the curation criteria can be defined in the proposal agreement terms and the action to add an entry can be disputed.
Organization dependency on the Aragon Court
Each Aragon organization is a completely self-contained set of smart contracts and operates as a sovereign entity. Even though Aragon maintains the underlying smart contract repositories, an organization must confirm each smart contract upgrade and can choose not to upgrade if they want. They can even choose to fork the repository and migrate to contracts maintained by a different provider.
This means that Aragon and Aragon Network Token holders have no control over the operation of any Aragon organization. This is a purposeful design goal of Aragon’s architecture as the ability for organizations to maintain complete sovereignty is an important differentiator between an Aragon organization and a traditional legal entity.
However, when using proposal agreements organizations must opt-in to a dispute resolution service provided by the Aragon Court, and in order for disputes to be resolved the court must be granted some limited authority over the organization’s operation.
Specifically, once a dispute has been created, the outcome of the dispute can cancel an active vote. The court can never take actions within the organization, but it can prevent actions from being performed. If someone is able to create disputes and manipulate the outcome of disputes, then it would be possible for them to effectively freeze the organization.
This may seem problematic, why should an organization put so much trust in the Aragon Court? In practice, the amount of authority that is ceded to the court is entirely dependent on how the organization is configured. This allows the organization the ability to make decisions about how much and where trust is placed between themselves, other participants in their organization, and the court.
- An organization can restrict dispute creation to only members of the organization (e.g. token holders). For organizations that don’t have transferable tokens, this would mean that even if the court was malicious, if there is consensus among the organization members, then votes could be passed without a dispute being created and without giving the court the opportunity to cancel the vote.
- An organization could be configured such that there are two voting apps, one with a high approval quorum and one with no quorum requirement, and only require proposal agreements for the voting app that doesn't have a quorum requirement. In this case, even if the court is malicious, so long as there is enough support within the organization, it can overcome a malicious court.
- An organization may choose to grant its members the right to unilaterally exit with a proportional share of the organization’s assets. By granting exit rights to individuals, even if the organization is otherwise unusable, members of the organization can overcome a malicious court simply by abandoning the organization and starting a new one.
- An organization may use a futarchy decision market to remove or replace the proposal agreement and place a check on the decisive power of the court within their own organization.
These options enable organizations to take advantage of the court’s dispute resolution service while minimizing the risk that a vulnerability in the court will adversely impact the organization.