Glossary

Entity is used as a way to refer to a blockchain address. This could be a single person or a group (utilizing a multisig or DAO).

Task A single item on OpenR&D that includes a budget and description. It can have multiple (accepted) applicants, but only 1 executor. It can have multiple submissions, but only 1 accepted submission. This could be a longer-term job listing or a one-time job. It could be anything, from software development to feeding your neighbour's cat.

Task funder The entity that has funded the initial budget of the task. This is usually also the creator of the task.

Task manager The entity that will perform the management operations. Every task has a single task manager. Usually, this is the funder of the task, but in special cases, it makes sense to give this power to someone else.

Task state A task can be either Open, Ongoing, or Closed. An Open task does not have an executor yet and allows new applications. A taken task does have an executor, will not allow application, but will allow submissions. A closed task does not allow any interactions, as it has finished.

Applicant An entity that is willing to perform a task for a certain reward. They apply and specify the desired reward on a per-task basis. The asked reward can be higher than the task budget and can include payouts to several different entities, although usually it will be only to the applicant. Their application can be accepted by the task manager, but if their asked reward exceeds the budget, the manager will need to increase the budget to be equal or greater first. Any accepted applicant can take the task to become the executor, this action is irreversible and on a first come first serve basis.

Executor An entity that is chosen to perform the task. They are the only entity that can create submissions.

Submission A declaration from the executor that they believe the task has been completed. Alternatively, you could view this as a request for the reward to be released and the task to be closed. A submission includes an explanation on why they think the task has been completed, which usually includes where to find the deliverables (if any). The task manager will review this submission and either accept or reject it. Acceptance will close the task and release the reward, where any leftover budget will be sent back to the task funder's wallet. In case of rejection, no action will be performed. When reviewing the task manager is required to provide an explanation on why this decision has been made.

Dispute manager The entity that will handle any disputes related to the task. This dispute manager is chosen by the task creator. In case the executor and task manager cannot reach an agreement on whether the task has been completed, the executor is able to create a request to the dispute manager to look into the case and provide their judgment. This request does cost a fee, which is set by the dispute manager, to compensate them for their resources spend on reviewing the case. The executor can also specify how much of the reward they think they should receive (in case they agree they did not complete the task completely, but do think they should receive more than the task manager is offering them). If the dispute manager decides in favor of the executor, the (partial) reward will be paid out and the task will be closed. Any leftover budget will be refunded to the task funder, similar to completing the task normally. The dispute manager protects against malicious or unfair task managers. Every dispute manager can choose their way of deciding on disputes, although we would recommend using a decentralized process. Openmesh provides a dispute manager, but task creators are free to pick any other one they prefer. Similarly, anyone is free to start their own dispute management service.