Quests swarm funding proposal

Quests swarm funding proposal

Proposal Information

Proposal description:

This proposal is to fund the Quests Swarm DAO: The 5 members of the DAO managing funds are all the members working on Quests. For the moment, they will be the only one managing the funds for the MVP. Once the MVP is released, other members that would like to join the DAO will be able to.

Proposal Rationale

Honey quests will be a way to create tasks, fund them with honey from the DAO, and allow one or more people to complete them. This will offer many advantages such as:

  • Providing an opportunity for developers to get in touch with IT promoters.
  • Help promote blockchain technology and cryptocurrency all around the IT community.
  • Create a link between promoters (Creators) and developers (Players)
  • Providing an easier way to get in contact with experts specialized in advanced IT fields.
  • Easy and user-friendly rewarding system based on honey from the DAO.

The documentation for honey quests is still in progress, you can follow all our advancements and new features on:

What are the key features that will be integrated into the MVP?

Quests are a way to engage and organize community efforts to accomplish shared goals. Quests involve 3 participant roles.

  • Creators - Create and campaign for quest funding
  • Players - Complete quests
  • Patrons - Fund quests

Creators define a task that can be publicly verified as completed and define some parameters:

  • An expiration date
  • A funding token (eg $hny)
  • A patron address
  • Collateral amount (%)

The quest description can be used by the creator to define requirements, milestones, and other details. This is open-ended and quite flexible, upon completion users would specify the reward amount, which may be the full amount held by the quest or a portion, depending on how the quest has been defined.

A one-off quest intended to be completed only once would allocate all of its funds to the first completion. However, a quest intended to be completed multiple times in different ways, for example, “writing a blog post explaining your vision for 1hive over the course of 2021” could say that the first completion receives 10% of the funding, and each subsequent completion receives 10% creating a decaying reward until the quest expires.

Each time a quest is completed, a portion of the funds released are given to the creator. Once a quest has expired any remaining funding is returned to the Patron.

Expected duration or delivery date (if applicable):

2-3 months

Team Information

Swarm DAO members with equal weight in control of funds:

@felix @gossman123 @XEAxMaste @zbeubzbeub @fred

Skills and previous experience in related or similar work:

Many new group members are involved, some of whom have already explained their skill in the introduce yourself thread. Overview of skills: web-dev, algo-trading, just back-end technologies, reverse engineering, mobile apps , full-stack and DevOps.

Mentors that will help throughout the project:

@willjgriff @lkngtn

Funding Information

Amount of HNY requested:

HNY Requested 60 ~ $18k at the current price of $310/HNY.

Ethereum address where funds shall be transferred:

Quests Swarm DAO Agent:


A more detailed description of how funds will be handled and used:

Rates for contributors will be $30/hour. The above HNY should see us through to the MVP. Any funds remaining at this time will be used for future development. Payments will be made in HNY at the $ value at the time of the hours completed, once every 2 weeks. If the HNY price depreciates significantly or development takes longer than anticipated more funds may be requested. The above estimate has taken into account the main contributors individual estimates for completion of their part of the work plus some extra for unknowns.

Information breakdown:
The hours work on the project will be visible here : Quests hours
Kanban board : Kanban
GitHub code: (this will be fork into 1Hive repo when the MVP is done)

Vote on proposal :


Love it. good luck guys. (❁´◡❁)(❁´◡❁)


Really excited to see this happen!


I like the quests idea , wishing you guys success in making this project work .

1 Like

Great initiative. I’ve added my support. Best of luck! :honeybee:

1 Like

I’m curious about your relationship to the others involved, I can’t recall having seen any of those usernames around besides yours. Can you tell us more? Maybe link to the intro posts for each?

It would also be useful if you wrote a detailed technical specification of the functionality involved, including how it will use the Aragon Govern contracts to delay rewarding players, once they have finished the work, giving others time to verify and challenge the work they have done. You will need to understand the Aragon Govern contracts to some extent to enable the UI/web app to submit reward requests through it.

I’m also curious if any more discussion has been had about whether players should claim a quest before starting it or if it will just be the first to claim the reward that wins? For an MVP I would suggest it being the first to claim that wins as it will be less complex.

With regards to the params creators specify in order to create a quest. Specifying the patronAddress implies only one address can fund each quest, I think that’s reasonable for an MVP but it would be nice if multiple addresses could fund a quest in future. Also the collateralAmount (%). collateralAmount in this context implies the amount the player would risk when making a request for a reward, is that what this is for? And can you explain what the % sign refers to? Alternatively perhaps this is actually the reward percent paid for each successful reward request? Curious for some clarification.

Looks good though, I’m in favour.


Hey there, yes of course!
We’re all people going to the same software engineering school, in April we’re all going to be new grads. I think we know each other for more than 4 years now. I’ve introduced them to the 1hive community by doing a pitch about Honey Quests, they we’re all really interested in the idea and learning about blockchain technologies even tho they have limited knowledge on the subject


Yes, I agree, this is still something we have to take the time to understand to make sure we’re using the correct flow. Will make an update about the subject later on.

Yes, this is something we’ve talked about. This will depend on the quests, some quests would able to be done by multiple people at the same time and all be rewarded correctly. We don’t want the people to just rush the quest to be the first to claim the reward, but maybe it’s something that we’ll only implement after the MVP. Still trying to get a good scope on the feature we will release with the MVP.

Yes, this is also something we’ve talked about. I think we’re going to start only having 1 patron address at first, but the goal is to be able to have multiple patrons for each quest.

The collateral amounts are something that can be added or not with the quest itself. The idea was that if a quest is only doable by one people at each time (e.i. a quest about making the mobile view of a project prettier) the player will have to add collateral to make sure that they’ll be working on this quest and they intend on doing it. The (%) amount will be depending on the reward of the quest (e.i. 10% of the reward will need to be added as collateral to make sure that you’ll be working on this quest).

Think of it as proof that you’ll do quests

Glad to hear :smile: :honeybee:


If that’s the case, presumably they would only get their deposit back once successfully claiming the reward for completing the quest? Would putting up this deposit block others from attempting the quest? Ideally it wouldn’t, in which case I see 2 options:

  1. Once the quest is complete everyone who claimed they would complete the quest would get their deposit back. This means if you claim you will complete it but don’t, you will only get your deposit back if someone else completes it.
  2. Alternatively you could say once the deposit is put up, you won’t get it back unless you complete the quest yourself. So if multiple people make a deposit to attempt the quest, only the completer gets their deposit back which would create more competition to complete the quest quicker.

In either case, you also need to think about if the deposit needs to have been put up sometime in advance of requesting the reward. Otherwise they could just put up the deposit immediately before requesting the reward. Alternatively if only one person could put up the deposit per quest, you need to specify a time limit before someone else can attempt that quest. And in both cases decide whether these time frames are specified by the quest creator or globally.

Personally I wouldn’t bother with figuring that out and just do whoever submits the reward request first but I’m interested to hear what you think and if you have a solution.

Also you will still need to add a parameter specifying what percent of the reward is paid out per reward claim to handle quests that can be completed multiple times.

1 Like

Sounds great, am i correct in my understanding that “quests” are bounties ?

1 Like

Yup, exactly! I think they should also be usable as a basic Escrow. So an individual should be able to request funds from the 1Hive common pool to a quest they created, that will only pay out to them or return the funds to the sender after an expiry, then if they do the work they get the funds. In future it could integrate milestones to make periodic payouts for a single quest.

1 Like

I think we can support milestones simply by allowing people to complete quests multiple times so long as there is still funding the quest hasn’t expired. The quest would define the milestones, and then when the completer requests funds, if they request more than what corresponds to the amount they would be challenged.

There’s a discussion to be had about how payments are made with multiple payout quests then. It was suggested that multiple payout quests would payout a percent of the balance, but ideally both options would be encoded and possible.

Alternatively, as I think you’re suggesting (@Felix this is why a technical document would be useful) users could straight up specify the amount they’re requesting and it must be in line with the proposal description. If it isn’t it will get challenged and likely cancelled. The issue with this and using a percentage of balance, is due to the delay, if a request ahead of yours gets cancelled after you’ve created yours, the amount you put in would be incorrect, so this calculation should ideally be done on chain. Unless you don’t do this and just use the same amount for each reward.

What’s the latest on this? I was actually thinking of building a similar MVP app. Where can I get the latest update @Felix ?

1 Like

Hey there! You can see the update here : GitHub - 1Hive/quests and the WIP UI atm here : The team is currently working on the subgraph , if you want to contribute and help us let me know! We still have a lot of fund :slight_smile:


This is epic! Super excited to see this come to life.

Maybe I haven’t digged deep enough but I can’t seem to find the full documentation of the project (scope, features, implementation, …) Could you redirect me? Otherwise I will struggle to get up to speed :stuck_out_tongue:

@Felix I also reached out to you on Discord :slight_smile:

Hey guys, the #:star2:quests team is currently looking for more developer, If you’re a frontend dev and you would like to join the team, send me DM on discord. We’re also looking for people to help with the integration of the subgraph!

(All the compensation will be in HNY) :bee:

Hey everyone, just want to give an update on the recruiting of new Developers. We’re happy to announce that we have a new member joining the quest team! Welcome to @sundeep_charan, he’s a Software Engineer based out of React/Node/TypeScript/GraphQL. He’s currently working on a project with Raid guild, but for the rest of his time, he’ll work on this project with us!