# Quests Contract/Functionality Spec

## Creating a Quest

Quests are funded tasks that can be completed by anyone, on chain they will be defined with:

- An IPFS Hash of the text details about the quest.
- A token used for payment.
- An unused funds address.
- Time to expiry, past which the funds can be returned to the unused funds address (this could be hardcoded or specified by the factory).
- The Aragon Govern address used for verification when executing a claim (this will be stored and specified by the factory).

The text details about the quest, uploaded to IPFS, should include:
- Details about what the quest entails.
- What evidence must be submitted by users claiming a reward for completing the quest.
- The payout amount. This could be a constant amount for quests that payout multiple times, a range with reference to what determines what amount, the contracts balance at time of claim. This shouldn't be a percentage of the contracts balance though as claims are not guaranteed to happen in order as they can be cancelled, messing up the valid claim amounts.
- Optionally a whitelist of addresses or set of addresses that can receive rewards for this quest.

There will be a factory contract which creates new Quests using the arguments above. The creation function could also accept and transfer an initial deposit from the sender to the Quest contract. The factory could retain references to the quest contracts or it could just emit them in events.

Each Quest will be a new contract so that fund contributors can send funds directly to the quests address rather than calling a function on the contract (this is currently necessary to allow Conviction Voting to fund Quests without an intermediate contract).

## Claiming from a Quest

To make a claim a user must submit a function call, which will call the Quest contract, along with a deposit, to the Aragon Govern Queue. The Queue delays the call for a period of time, maybe 7 days. Within the delay others can also deposit some amount and challenge their claim which raises it to Celeste to decide whether the claim should be allowed or cancelled.

Calls to the Quest contract to claim from it, called after passing the delay in the Aragon Govern contract, will include:
- An IPFS hash of the evidence for having completed the quest.
- The amount of tokens being claimed (if 0, could claim the entire quests balance).
- Address to receive the claim amount.

The text evidence, uploaded to IPFS and submitted, should adhere to the evidence requirements specified in the original quest details. Otherwise it is likely it can be challenged and cancelled via Celeste.

## Web App

Since we are significantly limiting checks made on chain and allowing them to be specified in a plain text document, for example allowing the user to specify the claim amount, the UI must clearly display all the information necessary to easily determine whether a claimer is acting honestly.

The main screen could be a list of all quests which can be clicked to open a detail view. To create a quest there can be a create quest button that opens a modal or side bar like on 1hive.org when creating a proposal.

The detail view of each quest should allow users to claim from the quest. As specified in the Claiming section, creating a claim requires submitting a data structure to the Aragon Govern Queue that includes the Quests `claim()` contract call and an approval to allow the Govern Contracts to take a deposit from the user. They must then wait 7 days after which `execute()` can be called (via the UI) on the Govern Contracts, returning the deposit to the user and executing `claim()`. If disputed, once the dispute is over the user must call `resolve()` (via the UI) on the Govern Contracts instead of `execute()` which will call `claim()` if necessary and return the deposits to the winning user (claimer or challenger).

The detail view must display the quests original description (fetched from IPFS), as specified when creating the request, and a list of all claims made. Including the claims evidence content (fetched from IPFS) and the amount they are claiming and what address it is being sent too. This should include a button to dispute the quest if their evidence is not considered in line with the quests original description. The deposit required to create the dispute should also be shown.

The UI will require a subgraph to fetch the data from the Quests contract and the Govern contracts (there is already a Govern Subgraph so hopefully you can use that).