1. Introduction
Aragon Court currently uses a “flat” recurring subscription fee per organization, along with dispute and appeals fees which are paid on a per-dispute basis. The intention of the current subscription fee model is to address the issue that the value provided by Aragon Court is realized for organizations on an ongoing basis but the need to actually escalate disputes to the court should be relatively rare. Similar to insurance, paying for coverage on an ongoing basis helps to create more stable costs for users, and more predictable revenue for service providers. However, the flat subscription model doesn’t scale based on usage, risk, or value provided. The result is that it is difficult to appropriately price a flat subscription fee, as it may be almost negligible for a large organization like the Aragon Network, but if it is set higher than it will price out a much longer tail of organizations. Additionally, the flat subscription model assumed that organization would budget and pay for subscriptions as a collective, but this assumption makes integration with decentralized applications and protocols more difficult, as they may not even have a traditional financial decision making process and instead have users pay or be rewarded through more automated interaction patterns.
2. Proposal
That said, bearing in mind the ongoing development of Agreements as the nexus between Aragon organizations and Aragon Court, we propose a new mechanism based on transaction fees. The Agreement app is a particular app that serves as a bridge with Aragon Court, that users can opt-in to install in their organizations and provides a framework for other Aragon apps to become disputable. This means it enables apps to have their on-going actions easily integrated with Aragon Court in case they want to dispute them. For example, a Voting app can be integrated with the Agreement app so its votes can be challenged in court. Thus, the idea of transaction fees is to have each of these actions paying in advance a proportional fee to Aragon Court in case these get disputed, similar to an insurance mechanism.
This serves three purposes:
- It is variable based on the usage of the Agreement forwarder, the more an organization’s members use Agreements the more they pay to Aragon Court, even if they don’t have a large volume of disputes.
- It abstracts the need to worry about fees from the organization perspective, users will pay for the fees as they interact with the organization. This is really important for organizations that may be intended to serve a single purpose (e.g. curate a registry, or allocate funds using conviction voting) as creating a recurring expense (even a small one) requires some sort of way to define a budget consistently.
- It enables the organization to fund itself based on people interacting with it. For example, a curated registry may have a set of members who are promoting and maintaining the registry, when someone submits an entry they pay into the DAOs, and this provides a business model for the promoters and maintainers of the registry.
3. Technical details
A simple solution would be to define a number of fees based on the disputable app being used. We can easily implement something like an oracle for Aragon App fees that basically tells a fee amount for the type of disputable app being used. For example Voting (1 DAI), Delay (1 DAI), etc. This oracle would be managed by the Aragon Court’s governor.
contract AragonAppFeesOracle {
function setFee(bytes32 appId, ERC20 token, uint256 amount) external onlyGovernor;
function getFee(bytes32 appId) external returns (ERC20, uint256);
}
This oracle should be implemented by the Aragon Court’s subscription fee module, an ongoing implementation can be seen here.
Based on the feedback we have gotten during the development process I expect this to be a relatively uncontroversial change, but it seems worth discussing here as there may be thoughts and feedback on the current or proposed fee mechanism that may emerge.
