[quest] Develop new Quest document type v8

[sceenius]

1 Purpose Quests are single- or multi-worker future engagements with one or more milestones, a "bounty" being a specialized quest with a single-worker and single-milestone. For more background information and the discussion around this issue, please visit the Discord quest design channel

Nomenclature

Type	Description
Quest	The main document, contains key information about the quest (note: we aim to share this document with other dApps)
Quest-assignment	The assignment document, similar to role- or badge-assignment
Quest-milestone	The milestone document, releasing funds after successfully passing a vote on a milestone
Quest-roster	Quest-member x quest-milestone grid showing member-contributions
Quest-sponsor (or treasurer )	Person holding the funds in escrow with the power to release or block funds, (e.g. investor).
Quest-creator (or owner)	Person running the quest with authority to edit/withdraw it.
Quest-member	An active participant of the quest, receiving payout for successful completion of milestone

Entity Relationship

Graph Relationship

Milestone Status Diagram

2 Authorization

Document	Function	Quest-creator	Quest-sponsor	Quest-member	Hypha-member
Quest	Create	✅	✅	✅	✅
Quest	Propose	✅	✅	✅	✅
Quest	Suspend	✅	✅	✅	✅
Quest	Withdraw	✅	✅	⛔	⛔
Quest	Edit	✅	✅	⛔	⛔
Quest	Save Draft	✅	✅	⛔	⛔
Quest-milestone	Create	✅	✅	⛔	⛔
Quest-milestone	Delete	✅	✅	⛔	⛔
Quest-milestone	Edit	✅	✅	⛔	⛔
Quest-milestone	Save	✅	✅	⛔	⛔
Quest-milestone	Release	⛔	✅	⛔	⛔
Quest-roster	Add (V2)	✅	✅	✅	⛔
Quest-roster	Edit (V2)	✅	✅	✅	⛔
Quest-roster	Add member	✅	✅	⛔	⛔
Quest-roster	Remove member	✅	✅	⛔	⛔

3 Business Logic

3.1 Quest 3.1.1 Quest begins when the Quest document has been voted in (quest defined and funds staked, no start date needed) 3.1.2 Quest ends when all milestones have been completed (all voted in) OR if a milestone keeps failing (not passing) 3.1.3 Quest has an owner (sponsor) to control most changes (e.g. new participants added, contribution levels adjusted) 3,1,4 Quest funds go into escrow and cannot be changed throughout the quest (to avoid fraudulent behavior) 3.1.5 Quest funds are multi-token and can be customized (use same feature and is contributions) 3.1.6 Quests can be terminated by anyone in the organization through a suspension vote (to avoid fraudulent behavior) 3.1.7 Quests have a single source of funding that is bound to an accounting ID (list pending) [V2] Quest funds can be amended during the quest and must be voted in by the organization (the payouts will accumulate all amendments similar to badge stacking) [V2] Quests are bound to a circle ID as defined in Nestr

3.2 Milestones 3.2.1 Milestones are executed and completed in sequential order (e.g. not skipping low payouts) 3.2.2 Milestones can be added at any time by owner (sponsor) or removed IF they have not started yet (no vote necessary) 3.2.3 Milestones have individual weights that must add up to 100% [V2] Milestone addition/removal triggers a recalculation of milestone% and contribution% in equal amounts (prompted for and adjustable by quest owner) [V2] Voting is accelerated by 80/20/1T1V/0WK (passed as soon as quorum and unity reached)

3.3 Payouts & Participants 3.3.1 Participants can join or leave the quest at any time (payouts are computed at every milestone completion event, incl pro-rated) 3.3.2 Only the quest-sponsor can change participation levels (incr/decr %contribution) BUT jointly with members 3.3.3 Participant contribution levels must add up to 100% for each milestone 3.3.4 Badge multipliers are applied to payouts (using separate accounting bucket) 3.3.5 Payouts are released from Escrow once (1) the vote has passed and (2) the quest-sponsor has released the milestone [V2] Member addition/removal triggers a recalculation of contribution% in equal amounts (prompted for and adjustable by quest owner) [V2] Multi-roster input by any team member, with averages and variations taken across all submissions and the ability to correct percentages [V2] Additional [expense] account types are added to cover external agency work of additional bonus payouts or expenses [V2] Quest-participant must reduce the income from a role-assignment prior to joining the quest

4 Calculations [V2]

Milestone and member additions and removals can be calculated automatically by adding or removing equal amounts to the remaining objects. This action must be confirmed before it is executed since the quest owner might want to keep the percentages as is and adjust them manually. It is a big time-saver if used cautiously and with the right facilitation & protocol (e.g. a rage-quit or new member equal-addition).

4.1 Milestone removal: %payouts are added in equal parts to the remaining milestones, e.g 5 20% becomes 4 25%

• simple calc to divide the leaving %payouts by the number of remaining payouts and add to each

4.2 Milestone addition: %payouts are removed in equal parts from the remaining milestones, e.g. 4 25% becomes 5 20%

• simple calc to update the new %payouts = old %payout - 100/N(N+1) and 100/N+1 for the new milestone

4.3 Member removal: FOR EACH MILESTONE %contributions are added in equal parts to the remaining members, e.g. e.g 5 20% becomes 4 25%

4.4 Member addition: FOR EACH MILESTONE %contributions are removed in equal parts from the remaining members, e.g. 4 25% becomes 5 20%

• simple calc to update the new %contribution = old %contribution - 100/N(N+1) and 100/N+1 for the new member

5 Governance

5.1 Quests are organizational assets that are voted in by all members (80/20/1T1V/1WK) 5.2 Quest-assignments are approved and edited by the quest-owner 5.3 All other decision-making is internal to the team and not stored on-chain [V2] Quest-milestones are voted in by the organization at the completion of the milestone (80/20/1T1V/0WK) [V2] Voting power is determined by the accounting ID (assignment-based) or circle ID (member-based) [V2] Quests can be created outside of the Hypha DHO and then used inside Hypha to continue the quest

6 UI/UX

We aim to simplify the UI for quests as much as possible and introduce a new full-screen form to create and edit quests. The difference to current objects (e.g. role, role-assignment) is that all related forms are combined into a single form to edit. For quests, this would combine the quest definition, the quest-milestones and the quest-assignments into a single (tabbed) form.

[sceenius]

Question: are the new T-bonds from Telos playing a role for us in quests? Answer: no.

Figure 1. By delaying the sale of tokens until after the key milestone is achieved, the token price may avoid sell-offs and appreciate more from reaching adoption, marketing or development milestones funded by the sales.

https://medium.com/@goodblock_info/launching-t-bonds-on-telos-dd2c7f363ae9

[sceenius]

Collecting ideas for a single quest screen - note "jobs" = Role-assignments, and "challenges" could be permanent single-player single-task (introductory) quests

https://www.reddit.com/r/DestinyTheGame/comments/8io868/bungie_could_we_see_the_return_of_the_original/

[sceenius]

@gregory-latinier I am thinking to use a table-based layout for the Milestones and Members forms (I tried a tree-view but it is hard to edit that). Do you think the following is possible? Click on "Edit" and switch to the table edit form and "Save" to go back.

[n13]

@sceenius can we remove commitment %?

A quest is a defined outcome - how much commitment someone is using to reach this outcome should be irrelevant.

I would also really prefer to leave the divying up of the loot to the quest members, and not define it here?

Although the question would then be, how to pay out.... hmmm...

Or maybe this - the quest can be undertaken by either a team, or an individual. A team could be an organization in Seeds terms. The quest itself doesn't care - the quest only cares about milestones, achieved results, and is a contract to release payouts based on these.

The entire mess of group management can then be done by the team - a team could have its own contract - again we could spruce up the org contract a litltle to distribute incoming funds to members of the team. Team can then manage itself

Quest can then simply not deal with team management. Separation of concerns.

What do you think?

[n13]

Two main things I would like to change here:

Separation of concerns, removing team management

We can provide a separate contract or use the org.seeds contract for teams - then teams can sign up same as individuals.

Quest domain:

• Quest lifecycle create/assign/verify/complete
• Milestone management
• Payout based on completed milestones
• Deal with fail cases / no show / not completed / retracted / cancelled

Team management - can be done in any way. None, org contract, some other clan contract that distributes funds, etc.

Privately funded quests

Private sponsor can fund quests, DAO has nothing to do with it. Can assign verifiers or remain the only verifier (voter on milestones).

[sceenius]

@n13 I will remove the %commitment, you are right, this is not relevant.

On the team management, there are 2 sides to it:

1 deciding who gets to participate and at what level of contribution 2 the actual names and contribution levels (for payouts)

1 is where we defer all decisions (and how they arrived at it) to the team, the org is really only concerned with the outcome. #2 is needed for the payouts.

Privately funded quests can be done via the Accounting ID (an account that is tied to any accounting source, internal or external). However, the context is still the DHO, in our case the Hypha DHO, later the DHO.

[sceenius]

@dappdever Could you add a graph diagram for the quest? I've linked your other diagram above (reference link), so you can just add it to that Google doc.

[julioholon]

That's what I got from the specs so far, please see if it makes sense?

Quests

1. Any member can create a Quest and vote on it via the DHO, with the following info:

• Title
• Description (including OKRs)
• Link
• Circle (optional)
• Token budget

2. Once approved Quest can be voted for assignment (defining Quest Owner)
3. Quest owner can then create Milestones (no voting needed), each Milestone has this info:

• Title
• Description
• Token payout %
• Status (Not Started, Active, Paused, Aborted, Completed, Finished)

4. Quest owner can also assign Members for each Milestone, making them Active
5. Quest owner can unassign Members for an Active Milestone, if no one remains it becomes Paused (a Member can also unassign himself)
6. Members assigned to a Milestone can change the status back and forth from Active -> Completed
7. Completed Milestones can be voted by the DHO (or Circle) to become Finished, releasing the payment from escrow. If voting fails it goes back to Active.
8. All status changes performed without voting should support adding a text Note explaining the reason for the change
9. Once Payment is released, each Member assigned to the Finished Milestone receives equal percent of the tokens (i.e. 2 Members will earn 50% each) (TBD -- the Member setting it to Complete can specify different percentages for the completing Members)
10. The Quest owner can move a Milestone to Aborted anytime before it's Completed or Finished, returning the Milestone tokens to the Quest pool
11. Once all Quest tokens are distributed, all remaining not Finished Milestones become Aborted and the Quest itself is considered Finished.

[sceenius]

@juliolrmonteiro Yes, that's pretty much it. Some comments:

6 Would be an agreement with all team members that the milestone is completed and ready for a vote, the quest owner would make that change

8 The only critical decision is a "downvote" and I think we can do the same as we do with roles and role-assignments (share your reason, but not required)

9 Different percentages are a must have since people will work with diff capabilities and capacities on the quest

10 Is more about quest dynamics, milestones can be added or removed at any time, given that they have not passed

11 The roster should avoid this scenario and would typically pay out more towards the end of the quest; if no funds are left, you could set the payouts to zero

[sebastianmontero]

@dappdever here is a first stab at the document diagram, what do yo think?

[leonieherma1]

Also see https://github.com/hypha-dao/dao-contracts/issues/54