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.
Requirements
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.
Requirements
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_VOTESrole 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
pausedandcanceled
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:
Staking:
Unstaking:
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!
