# EQTY Aragon Apps

This document outlines specs for custom Aragon apps to be built by EQTY Labs in support of various DAO integrations.

Aragon is a Solidity based dApp/DAO framework with a user/role/permissions system that its “apps” run atop. An Aragon based dApp/DAO is a deployment consisting of a collection of Aragon Apps that support both standalone and interoperable functionality. For instance the “Finance” app can be deployed by itself to allow permissioned users to manage a treasury, but it can also be deployed in conjunction with the “Voting” app, to allow members to vote on treasury management.

Note: `Roles` in this document correspond to the `Actions` column on the Aragon permissions dashboard. An `Action` there is what you would normally call a `Role` and it can have multiple contract functions associated with it.

The function prototypes documented here are meant as minimal documentation of planned architecture; many implied initialization functions and read-only functions (getters, filtered getters, etc) are omitted. However, all functions that affect state should be documented here and have their associated roles indicated.

It's likely many function prototypes will change during development, especially related to the interface between apps and any proxy functions supporting that.

# Working Groups App

## Overview

Allows users to create, remove, and manage working groups for the DAO. A Working Group is technically a sub-DAO of the primary DAO with a combination of self permissions and permissions controlled by the primary DAO. WG membership is managed by a Tokens App deployment in the WG’s sub-DAO.

The agent contract for the Working Group's sub-DAO can be given permissions in the main DAO to allow the sub-DAO to perform actions in the main DAO.

## Roles

- Create Working Group
- Remove Working Group

## Functions

### Create Working Group

function newWorkingGroup(
    string workingGroupName,
    string workingGroupMetadata,
    address initialMember
)
    external
    auth(CREATE_WORKING_GROUP_ROLE)
    returns (uint256 workingGroupId)

### Remove Working Group

function removeWorkingGroup(
    uint256 workingGroupId
)
    external
    auth(REMOVE_WORKING_GROUP_ROLE)

# Documents App

## Overview

Allows users to manage a document store for the DAO. A document can consist of content stored on-chain or content stored on IPFS. Documents and directories stored off-chain are referenced on-chain by their CID.

In leau of a full blown permissions based filesystem, documents are split into two categories (core documents and regular documents), with separate role permissioned to create/edit/delete each. This allows the contract implementation to remain simple, but still allows for delineation between more important documents (like a constitution) and less important documents (like a list of memes).

## Roles

- Edit Core Documents
- Edit Regular Documents

## Functions

### Create Document

function newDocument(
    string name,
    DocumentType documentType,
    string content,
    bool isCoreDocument
) {
    // Checks role permissions based on `isCoreDocument`
}

### Edit Document

function editDocument(
    string name,
    DocumentType documentType,
    string newContent,
) {
    // Checks role permissions based on if document to edit is `Core` or `Regular`
}

### Remove Document

function removeDocument(
    string name
) {
    // Checks role permissions based on if document to remove is `Core` or `Regular`
}

### Types

enum DocumentType {
    OnChainFile,
    IpfsFile,
    IpfsDirectory,
    FilecoinFile,
    FilecoinDirectory,
}

struct Document {
    string name,
    DocumentType documentType,
    string content,
    bool isCoreDocument
}

# Filecoin Storage App

## Overview

Allows users to submit and pay for storage deals on the Filecoin network. Additionally this app acts as an interface for tracking stats and health of existing storage deals submitted through this app.

In order for this app to pay for deals, it must first be funded with FIL. This can be done by users directly sending FIL to this app, or through treasury transfers from the Finance App.

## Roles

- Submit Storage Deal

## Functions

### Submit Storage Deal

function submitStorageDeal(
    bytes pieceCid;
    uint64 pieceSize;
    bool verifiedDeal;
    bytes client;
    bytes provider;
    string label;
    int64 startEpoch;
    int64 endEpoch;
    int storagePricePerEpoch;
    int providerCollateral;
    int clientCollateral;
)
    external
    auth(SUBMIT_STORAGE_DEAL_ROLE)
    returns (uint256 storageDealId)

# Multi-Choice Voting App

## Overview

Allows users to submit and vote on proposals with multiple selectable options (as opposed to yes/no like the Voting App).

The first version of this will support either Ranked Choice Voting, Quadratic Voting, or both (TBD).

Options for proposals in this app will not directly have EVM scripts associated with them like Voting App proposals do. Any automated actions associated with multi-choice proposals should be handled by an app that deploys a multi-choice proposal and then interprets the results itself and spawns any resulting actions.

## Roles

- Create Multi-Choice Vote
- Modify Multi-Choice Support
- Modify Multi-Choice Quorum

## Functions

### Create Multi-Choice Vote

function newMultiChoiceVote(
    VoteType voteType,
    string metadata,
    string[] choices,
)
    external
    auth(CREATE_MULTICHOICE_VOTE_ROLE)
    returns (uint256 voteId)

### Vote (on a Ranked Choice multi-choice vote)

function voteRankedChoice(
    uint256 voteId,
    uint256[] choiceRanks,
)
    external
    auth(CREATE_MULTICHOICE_VOTE_ROLE)
    returns (uint256 voteId) {
    // First checks that target vote has type: Ranked Choice
}

### Vote (on a Quadratic multi-choice vote)

function voteQuadratic(
    uint256 voteId,
    uint256[] choiceWeights,
)
    external
    auth(CREATE_MULTICHOICE_VOTE_ROLE)
returns (uint256 voteId) {
    // First checks that target vote has type: Quadratic
}

### Change Support Required Percentage

function changeSupportRequiredPct(
    uint64 supportRequiredPct
)
    external
    auth(MODIFY_MULTICHOICE_SUPPORT_ROLE)

### Change Minimum Quorum Required Percentage

function changeMinAcceptQuorumPct(
    uint64 minAcceptQuorumPct
)
    external
    auth(MODIFY_MULTICHOICE_QUORUM_ROLE)

# Curation App

## Overview

Allows users to curate and rank items in collections.

Life cycle of a curation collection:
1. **Inclusion Phase:** Users propose items to include in collection and each is accepted or denied.
2. **Ranking Phase:** Items in collection are ranked (if collection is a ranked collection).
3. **Locked:** Collection state is locked.

TODO: Maybe make collection items ERC721 to provide easier interrop with other apps (for instance if something wants to source these lists for functionality in another app like data authentication)
## Roles

- Manage Collection Lifecycle
- Propose Item Inclusion
- Judge Item Inclusion
- Rank Items

## Functions

### Create New Curation Collection

function newCollection(
    string name,
    string metadata,
    CollectionType collectionType
)
    external
    auth(MANAGE_COLLECTION_LIFECYCLE_ROLE)
    returns (uint256 collectionId)

### End Inclusion Phase for a Collection
This advances the collection to the Ranking Phase if it's a ranked collection, or to Locked if it's a Normal Collection.

function endInclusionPhase(
    uint256 collectionId
)
    external
    auth(MANAGE_COLLECTION_LIFECYCLE_ROLE)

### Propose Item Inclusion

function proposeItemInclusion(
    uint256 collectionId,
    string itemJson
)
    external
    auth(PROPOSE_ITEM_INCLUSION_ROLE)
    returns (uint256 itemId)

### Accept/Deny Item Inclusion

function judgeItemInclusion(
    uint256 collectionId,
    uint256 itemId,
    bool accept
)
    external
    auth(JUDGE_ITEM_INCLUSION_ROLE)

### Rank Items

function rankCollectionItems(
    uint256 collectionId,
    uint256[] rankedItemIds
)

### Types

enum CollectionType {
    NormalCollection,
    RankedCollection
}

# Filecoin Data Validation App

## Overview

Allows users to submit proposal for data prepared for Filecoin storage.

Life cycle of a data proposal:
1. Data preparer proposes lists of root CIDs for storage deals.
2. Proposal is accepted or denied based on off-chain authenticity auditing of prepared data.

An off-chain oracle can pick up root CIDs for creating storage deals for passed proposals or this could later be integrated with an on-chain storage app to automate storage for authenticated data.

## Roles

- Propose Data
- Authenticate Data

## Functions

### Propose Data

function proposeData(
    string metadata,
    string[] rootCIDs
)
    external
    auth(PROPOSE_DATA_ROLE)
    returns (uint256 proposalId)

### Accept/Deny Data

function authenticateDataProposal(
    string proposalId,
    bool accept
)
    external
    auth(AUTHENTICATE_DATA_ROLE)