Requirements for Aragon Network / Court Launch


This post defines the high-level requirements associated with an initial launch of the Aragon Network DAO. An update to the Aragon Network whitepaper was also just merged which goes into more depth on how the Aragon Court and Proposal Agreements are being implemented, don’t hesitate to open issues in that repo if things are not clear.

The Aragon Network DAO will be governed by ANT holders and will rely on the Aragon Court and Proposal Agreements to define subjective criteria for what proposals are acceptable. It will allow treaasury governance without the involvement of the Aragon Association. The Aragon Network DAO will not replace the existing AGP process, instead a finance track proposal will be made to provide funding for organization, similar to how the AGP10 DAO is funded. If this initial deployment goes well, additional finance track proposals and/or meta track proposals can be made to transition more of the project governance over to the Aragon Network DAO.

Aragon Court MVP

The Aragon Court acts as a dispute resolution oracle, in the initial implementation we will focus strictly on resolving disputes involving proposal agreements. The court will take a dispute and its associated terms, collateral, fees, and claims as inputs and produce a ruling: either dismiss the dispute or cancel the pending vote and transfer collateral to the Challenger.


The Aragon Court dispute resolution process

  • Jurors must be able to stake and activate their tokens committing to arbitration responsibilities.
  • Jurors must be able to review disputes, and associated terms and claim data.
  • Jurors must be able to commit their vote.
  • Jurors must be able to reveal their vote.
  • Jurors must be able to view deadlines for pending disputes (commitment and reveal steps).
  • Jurors must be able to de-activate their tokens.

Proposal Agreements

Proposals agreements allow an organization to define human readable terms, a required collateral deposit, and an arbitration oracle. These terms can constrain the types of proposals and/or the off-chain processes associated with specific actions that require the same permission. For example granting the permission to upgrade a critical contract such as the ACL requires root-level authority, but a proposal to upgrade the ACL without an independent audit should never be allowed. Similarly, the capability to transfer funds or mint tokens is acceptable, but a proposal which bribes voters to transfer funds should never be allowed.


Proposal Agreements Process Diagram

  • Organizations must be able to create a proposal agreement by defining human readable terms, a required collateral deposit (token, amount), and specifying an arbiter. For V1, we do not need to expose the ability to change the arbitration oracle in the UI.
  • Organizations must be able to assign the CREATE_VOTES role of the voting app to the proposal agreement. Proposers should be prompted to agree and deposit collateral if they try and create a vote that is protected by a proposal agreement.
  • Challengers should be able to create a dispute from a pending vote detail page and be prompted to deposit collateral and provide evidence to support their claim that the proposal is invalid.
  • Proposers and Challengers must be able to view the status of agreements and disputes they are involved in, and withdraw collateral when an agreement is resolved.
  • Voting app must be updated to allow votes to be paused and canceled

ANT Staking Curve

In order to participate as a juror, an individual must acquire ANT and then deposit it into the court’s staking contract. Similar to a token bonding curve, the staking contract uses the current balance of deposited ANT to determine an exchange rate between ANT and stake in the court. Unlike a token bonding curve, we do not treat the resulting economic stake as a transferrable token. This curved staking approach encourages jurors to participate early and establish the credibility of a specific instance of the court, and enables the network to deploy multiple instances of the court protocol which compete with one another.

The staking and un-staking actions are governed by the following formulas:



Where s is the resulting stake in the court and d is the users deposit. When un-staking, c is the amount of ANT returned. The other variables represent state and parameters of the staking curve. r is the ratio of deposits to total stake, b is the balance of ANT in the staking contract, and t is the total amount of distributed stake.

Once a prospective juror has staked they are considered active and eligible to be drafted to review cases. A distinction is made between a juror being staked and active. An active juror can de-activate themselves at any time, but they will not be able to un-stake until any pending disputes they have been involved in have completed.

More resources on the court:
You can also find additional information about the court implementation in this forum post. Or checkout the WIP implementation on github. We are also actively working on more documentation and educational blog posts as we progress, so stay tuned!


Overall this looks awesome! Have a few questions though so created an Issue :slight_smile:

Edit: also the white paper on the GitHub is more reliable and up to date reference than this thread on the forum right? And thus it’s probably better to ignore the old threads on the forum?


So I’m doing research on various cryptoeconomic mechanisms that allow people to do useful things, and one thing that keeps coming up is how to resolve disputes on non deterministic data (aka things in the real world). Prediction markets offer one approach, but they are susceptible to 51% attacks or manipulation due to low engagement. Many alternative approaches involve some type of bond combined with an arbitration system. AFAIK the Aragon court is being presented as a solution to make decentralized governance more robust to real world scenarios, but has it also been explored as a method to provide oracle services to the Aragon ecosystem?

  • Example: a dApp needs a piece of data from the real world (did the rocket land successfully?). Anyone can provide data along with a stake on that data. Anyone can also challenge the data with a stake on the challenge. If there is a challenge the court resolves. The court gets it’s fee and the winner of the challenge gets the stake that’s left over. At any level of resolution a higher bond can be provide to escalate the case. This is pretty much how the court is setup today I think. This would allow a dApp (or DAO) to have reliable off-chain data, but at no cost to the dApp developer. It would also provide revenue for jurors and the Aragon Court.
  • note: this also assumes that the dApp in question has some kind of mechanism to reward people for producing data that is used in the dApp (inflation funding, fees, mandatory participation, whatever), but that’s not what we’re looking at here.
Revisiting Long-term funding models for Aragon