Coordinape
This document outlines a couple of the potential options for an integration between the bankless bounty board and coordinape.
Working Document with the Apes
Workflows
Bankless Technical Spitball
Bounty Circles
What is it?
What Problem Would it Solve?
Technical Implementation Ideas
Considerations
Dynamic Bounties
What is it?
What Problem Does it Solve?
Technical Implementation Ideas
Considerations
Working Document with the Apes
Workflows
Bankless Technical Spitball
Reach out to jordaniza#9868 with any questions on this section
A couple of ideas for integrations below:
Bounty Circles
What is it?
- Allow bounties to be claimed by multiple users, where the claimants manage the distribution of the bounty using the Coordinape circles mechanic.
What Problem Would it Solve?
- When multiple claimants want to work on a bounty, there's the problem of how to divide up the rewards. This is especially true for larger, more complex bounties that may involve several stages of work, where naturally there will be some folks who contribute more.
- This would allow the creation of larger, less well-defined bounties, as the team working on it can independently allocate rewards amongst themselves, and the bounty creator can just say "yep, this is done, distribute the funds as you see fit"
Technical Implementation Ideas
Workflow (click to open)
- User creates a bounty with a
multiClaimantoption andmanage this bounty as a Coordinape Circle?flag enabled.
- If so, bountyboard proxies part of the POST
/bountiesrequest to the Coordinape API: - POST
/circlesto create a new circle (under the current DAO as a protcol) - Callback POST to
${circleId}/admin/v2/epoches - A new circle is created, with one user (the creator), and one epoch
- Claimants can ask to be added to the circle, at the discretion of the creator
- Claimant asks to claim - this sends a pending request to join circle to the circle admin
- When added, they sign up for coordinape using the app if needed, then get added
- GIVE and GET are handled in the normal way
- At the end of the epoch, the creator can release part or all of the bounty to the claimants, and roll the bounty over with remaining funds
- Here we could set up an integration between Coordinape and Bountyboard, where bountyboard:
- Get the
pending-token-giftsfor the circle - Bountyboard could have the option to release funds, in the API
- How do we connect the bounty as a treasury?
Considerations
Bountyboard
- Bountyboard will need to adapt the data model to allow for multiple claimants
- If Coordinape needs to be enabled in the DAO, Bountyboard will need a
coordinapeEnabledflag
- Bountyboard will need to add an approval workflow to allow someone to request entry to bounty circle (email or discord?) - does coordinape have this?
- Will need a mechanism to connect bounties to and from GIVE:
- Ideally, we need to allow a part release of funds (or we MVP with a single Epoch and all-or-nothing)
- How do we connect the bounty as a treasury? Would be a big discussion point.
Coordinape
- Circles are linked to protocols:
- Does the DAO need to be a Coordinape customer to enable this feature or could we setup a circle in isolation?
- Does the user need to be setup in Coordinape for this to work?
- In bankless, coordinape is an L2 perk, will we relax this for bounties?
- Are we calling the react API or the PHP API? The react API seems to be defined in the
APIService, which contains really useful logic to also get the Web3 signatures, but I'm not 100% clear how an outside application would call it, might just be missing something.
- Are the circles going to be permissionless (gas fees?)
- Are epochs tied to the DAO or can each circle run independent epochs?
- How are GET tokens integrated with the treasury, I can see that there is a vault integration layer in the smart contracts but I'm a little unclear how it all works under the hood.
Dynamic Bounties
What is it?
- Allow Coordinapes to allocate GIVE to a bounty, increasing the value of the bounty until it is claimed.
What Problem Does it Solve?
- Creating bounties at a fixed point in time, with a fixed reward, assumes that we get it right first time in terms of compensation.
- If there is work that needs doing, but that is not being done, adjusting compensation up could be one solution.
- By allowing Coordinape to allocate to projects or bounties, we can give insiders more ability to fund work they believe needs doing.
Technical Implementation Ideas
Workflow, click to open
- When creating bounties, Bountyboard should pass a
enable dynamic rewards on this bounty?flag, to allow it to appear in coordinape circles. - Bountyboard can expose a list of dynamic bounties, maybe just by modifiying the GET
/bounties?customer=bankless&dynamic=true
- During each epoch, circles can opt to allocate GIVE tokens to bounties vs. users
- Bountyboard will call Coordinape API to get
pending-token-gifts, and display the current bounty + pending rewards
- Once GIVE converts to GET, bountyboard will need to pull in the funds to an escrow contract or webservice.
- When the bounty is claimed, the escrow service is emptied.
Considerations
- How will DAO members feel about this? It's essentially a haircut from salaries, as Coordinape circles are Zero Sum.
Bountyboard
- We will need to add a
reward.pendingobject, to reflect the fact that GIVE has not yet been converted to GET
- How will the total be calculated, if we have multiple currencies (what if the treasury pays in USDC but the bounty was originally denominated in BANK?
- We will potentially need an escrow service to hold pending funds, so they can be claimed or released back to the treasury.
Coordinape
- Bounties-as-users appears to break the existing data model in a number of ways:
- They don't have eth addresses
- They don't send GIVE, they only receive
- They don't belong to a circle in the traditional sense
- Would therefore require some more detailed input on the coordinape side of how to treat a non-user within their application.