Requirements

Contracts

• Agreement
  • A single Agreement MUST allow multiple Disputable apps to be linked
  • Collateral requirements MUST be configurable (and updatable) per Disputable app
  • The agreement content MUST be signed before a user is allowed to submit actions
  • The agreement settings (content, title, arbitrator, and staking factory) MUST be updatable
    • Updates to an Agreement's setting MUST cause a user to re-sign before they're allowed to submit actions again
  • Actions MUST continue using the content, arbitrator, and collateral requirements active at the time the action was submitted, even if new changes were activated
  • Actions MUST support multiple challenges (*if the Disputable app allows for it)
    • Once challenged, actions MUST not allow more challenges until a dispute has been finished ("one challenge at a time")
  • Challenged actions MUST pass a settlement period before a dispute can be raised
  • Arbitrator dispute fees MUST be paid half and half between the parties involved (*see exception below in assumptions if the arbitrator's fee structure changes)
  • Actions MUST be "closable": in this state, the Agreement MUST allow a submitter / challenger to claim staked tokens and MUST NOT allow any more challenges
• Disputable apps
  • The Disputable app MUST be notified on every Agreement state change to an action (*)
    • The Disputable app SHOULD update its own internal state when actions are challenged
    • (*) Except for the closed action state, ideally this should be originated from the disputable app itself
  • The Disputable app MUST decide how many times an action can be challenged
  • The Disputable app MUST decide what a dispute ruling means for an action
  • The Disputable app MUST decide when an action can be "closed"
• Disputable Voting app
  • The Disputable Voting app MUST allow one challenge per vote, even if it gets solved in favor of the submitter
• Disputable Delay app
  • The Disputable Delay app MUST allow one challenge per delayable, even if it gets solved in favor of the submitter
• Disputable Registry app
  • The Disputable Registry app MUST allow multiple challenges, even if it gets solved in favor of the submitter, entries can be challenged again

Frontend

• The Client MUST implement Agreements as a "native app"
  • Only the first installed Agreement instance will be shown
• A staking UI MUST be available in the client
• The agreement content MUST be markdown or pdf
• The signing process ("intents" or "transaction paths") MUST take into account the existence of an Agreement and any disputable apps, verifying additional conditions (see Section 4.3)

Assumptions

Contracts

• Agreement
  • The Agreement WILL rely on a staking pool shared among all Aragon DAOs
  • Organizations MUST use ACLv2 in order to use the Agreement as an ACLOracle
  • Submitted actions MUST only have one ongoing challenge at a time, and can only be settled once
  • Challenged actions WILL expire into the suggested settlement (by the challenger) if the action submitter is unresponsive
  • Settled actions SHALL NOT be challenged again—they MUST be considered "closed"
  • If the arbitrator's fee changes (either fee amount or fee token), the action submitter MUST contribute the difference rather than match the challenger
• Disputable apps
  • Submission and challenge permissions WILL be controllable per Disputable app using permissions and ACL oracles
  • Collateral requirements WILL be defined per-app, not per action
    • If users would like to define per-action collateral requirements, they will need to install multiple instances of an app
  • Disputable apps MUST be the first app in a multi-step transaction path
  • A challenged action SHOULD be considered "paused" for the duration of the challengeDuration
• Security modelling
  • The Agreement WILL hold user funds and WILL be in control of externally placed funds (staking lock manager)
  • The Agreement lives as an "extension" of the Court and its stateful properties: any entity can create a dispute on the Court, and the same can be said for contracts connected to an Agreement
    • The Court may introduce a whitelist of allowed contract types (via EXTCODEHASH)
  • Users SHOULD trust the Agreement<>Court link
  • Users SHALL NOT trust the Agreement<>DisputableApp link, and must vet Disputable apps accordingly
  • In case an arbitrator rules a dispute with an unknown result, the Agreement app WILL communicate the unknown ruling as action voided to the Disputable app
  • In case a challenged action is settled, the Agreement WILL communicate action rejected to the Disputable app
  • If a Disputable app fails to allow an action from being "closed" ("deadlock"), the organization SHOULD upgrade the app to allow submitter / challenger to claim staked tokens