This guide is aimed at developers willing to build disputable apps. Here you will learn the things you should bear in mind while building a disputable app to make sure it is set up and integrated correctly.

<aside> 🚨 This document has been shared publicly with the community to gather feedback

</aside>

<aside> ⚠️ This guide is written based on the implementation provided here and here

</aside>

1. Architecture

The following diagram shows the architecture built to support disputable apps for Aragon organizations:

As you can see, the disputable apps are connected to an Agreement app installed in the organization. This is how apps become disputable. The disputable apps are not in charge of handling the disputes-related logic, this will be held in the Agreement app, but to interact with the Agreement app to handle the different possible scenarios a dispute can go through in the context of each disputable app.

Additionally, the Agreement will hold the integration with a shared Staking pool. Disputable apps can decide whether to use or not to collateralize the actions that could be disputed.

2. Terminology

To clarify some concepts and make sure you are on the same page, let's be clear about these different terms we will refer continuously along this guide:

• User: Member of an organization; someone that can interact with a disputable app.
• Action: The intent submitted by an user to a disputable app. For example, a vote in the case of a Voting app, a delayable in the case of the Delay app, an entry in the case of the Registry app.
• Action ID: The unique numeric identifier for an action submitted by a user in the context of the Agreement app.
• Disputable Action ID: The unique identifier for an action submitted by a user in the context of the disputable app. Note that each disputable app could have different types for the identifiers and/or these could be repeated among different disputable apps. However, each action will have a unique "action ID".