Bounty Proposal: Surrender Funds

[0x4007]

Describe the background or context

• Penalty for reopened issues #439
• I think it would be a very interesting future if projects pay the debt of the bounty hunter (to the future project it shouldn't make any economic difference.)
• This will make claw-backs seamless for projects that received bogus work.
• This proposal will allow the claw-backs to be global (instead of limiting on the repository level!)

Describe the solution

If there is a disagreement between the bounty hunter and the project review board related to the delivery of the work, we should allow for the bounty hunter to "surrender" the bounty they earned. This way, they can get off the hook and start on their next bounty with no debt.

I think that getting to this situation in the first place is somewhat exceptional (poor QA is the responsibility of the partners after all) and the bounty hunter already did real work leading up to that point. So perhaps the surrender rate can be the entire bounty BUT exclude comment incentives (not sure if we should use that repository's configured rates or if we should have a standard global rate to calculate this, in case a partner has comment incentives disabled for some reason.)

Normally bounty hunters are not eligible for comment incentives, but this could provide a reward for extra effort (e.g. ideas, research) being put in to the bounty only for when there was a disagreement.

Examples

"Good" Bounty Hunter

• The disputed bounty was for 500 USD.
• The bounty hunter contributed plenty of research/ideas/conversation in the thread (comment incentives earned of 100 USD)
• Project and bounty hunter disagree about the quality of the deliverable and bounty hunter refuses to continue working with Project.
• Bounty hunter uses /surrender command to send back ( 500 USD - 100 USD = 400 USD )
• In this scenario, the bounty hunter still made it out with 100 USD and returned 400 USD

"Bad" Bounty Hunter

• The disputed bounty was for 500 USD.
• Minimal comment incentives (e.g. 5 USD)
• Disagreement
• Bounty hunter surrenders 500 USD - 5 USD = 495 USD

---

We might need to think of a way to proactively protect Partners if they spot a bad bounty hunter early on leaving a lot of bogus comments and working on bogus work. Maybe the partner can delete or mark as spam the bogus comments, invalidating those as countable. I think there is a feature to ban a contributor from a repository and automatically delete their comments as well which should solve for this exploit vector.

[0x4007]

@rndquu @Draeieg @sergfeldman rfc

[rndquu]

Bounty hunter uses /surrender command to send back ( 500 USD - 100 USD = 400 USD )

By "send back" you mean penalty applied on the next generated permit? How exactly a bounty hunter should send back the reward?

[0x4007]

Minutes from research call

• enable opt-out for clawbacks on repo level
• partner reputation system
  • a hunter surrender will severely dock the reputation of a partner project
  • when bounty hunters continue to work on bounties of a partner project, boost the partner reputation (they are probably good to work with.)

[0x4007]

By "send back" you mean penalty applied on the next generated permit? How exactly a bounty hunter should send back the reward?

I think this is a rough proposal that can benefit from refinement:

We can parse an onchain transaction e.g.

/surrender 0x6cea3b8812043a38418cd75e8411de0cf8401ba2c575e44e5f34dfd9947bb1cd

Where the argument is a transfer from the hunter's registered wallet back to the permit wallet.

• We need to ensure that we save-and-check the surrendered transaction hash so that it isn't double surrendered.
• We need to verify it is from the registered wallet of the bounty hunter.
• We also need to verify the amount is equal to the bounty, minus the comment incentives.
• finally need to verify the destination wallet address is the partner permit wallet

---

We ideally should handle this inside of a dApp where it automatically calculates the comment incentives that they can keep etc. and the bounty hunter just needs to press one button to finish the surrender operation. But that flow isn't too clear to me at the moment.

[sergfeldman]

@rndquu @Draeieg @sergfeldman rfc

@pavlovcik

I thought thoroughly about this idea and for now I suggest

• Focus all interactions with bounty hunters more on positive incentives than punishments.

• Clearer define incentive types and decide whether a bounty hunter will have separate "balances" or single "balance" for incentives.
  For example, we have bounties that are incentives for completing tasks, and incentive for comments that is a different incentive type.
  Some time ago, we gave a bug bounty and potentially can give incentives for helping with new tasks description, which can be a third incentive type.

For the future I propose

• If the negative case with bounty reopening will be repeated often, then consider a compensation mechanism with the insurance logic.
  The insurance logic: the less productive experience a bounty hunter has, the higher his deductions to the insurance fund should be. For bounty hunters with a long productive experience, the insurance system will make additional incentives instead of deductions.

The same or similar mechanism can be used for the reputation system.

[0x4007]

Focus all interactions with bounty hunters more on positive incentives than punishments.

On paper I can get behind this. We just have to think through all of our incentive mechanisms in practice and verify that we can substitute every incentive using "positive leverage" vs "negative leverage".

Clearer define incentive types
for helping with new tasks description, which can be a third incentive type.

This is all simplified and calculated as "comment incentives" which is applicable for 1. filing a new issue and writing its description 2. contributing comments to the issue conversation 3. pull request reviewers leaving comments.

However I imagine that they might be calculated at different rates. For example, the original comment used to open an issue will receive more credit per word when compared to other commenters in the issue conversation.

This is a purely quantitative calculation on value provided. In the future, we can leverage ChatGPT to parse the meaning behind each comment in order to measure the contributions from a qualitative perspective.

insurance fund

I'm unsure if I fully understand your idea. Who's funding this?

• If it is us, then this doesn't solve the problem because we're spending money on non-performance.
• If its the bounty hunters, then this is the same as my proposal with extra steps.

[sergfeldman]

Who's funding this?
If it is us, then this doesn't solve the problem because we're spending money on non-performance.
If its the bounty hunters, then this is the same as my proposal with extra steps.

I meant bounty hunters are funding the insurance deductions.

A general approach can be like for social insurance
https://www.investopedia.com/social-insurance-definition-5214692

The specific logic with criteria and calculations can be developed if the problem with surrenders will happen often.

[0x4007]

I meant bounty hunters are funding the insurance deductions.

• If its the bounty hunters, then this is the same as my proposal with extra steps.

[Draeieg]

Who's funding this?
If it is us, then this doesn't solve the problem because we're spending money on non-performance.
If its the bounty hunters, then this is the same as my proposal with extra steps.

I meant bounty hunters are funding the insurance deductions.

A general approach can be like for social insurance https://www.investopedia.com/social-insurance-definition-5214692

The specific logic with criteria and calculations can be developed if the problem with surrenders will happen often.

the overall idea for insurance has been talked already as tricky and more expensive, we should stick to solutions that are simpler/capital efficient

if anything we can do that social insurance thing as an opt in, but id wager most people in crypto would percieve anything taxlike as a scam

Since this scenario would happen if a partner does bad QA or is acting in bad faith and changes the specs we can brand /surrender a "protection against bad clients" and incentivize QA best practices (maybe make QA incentives?)

other options are

• gating /surrender behind levels and reputation (like we talked about gating comment incentives
  this will prevent bad hunters from accessing the features to begin with, and incentivize new hunters to level up and pick reputable partners instead of the typical freelance dilemma where a new freelancer with 0 reputation in the platform has to pick other 0 reputation clients making their first experiences bad
• doing the communist debt system where they have a negative balance effectively and some other project "pays" the missing funds

[0x4007]

Since this scenario would happen if a partner does bad QA or is acting in bad faith and changes the specs we can brand /surrender a "protection against bad clients" and incentivize QA best practices (maybe make QA incentives?)

/eject lol

QA incentives

Only if its somebody else's money, like Optimism OP tokens etc.

• gating /surrender behind levels and reputation (like we talked about gating comment incentives
  this will prevent bad hunters from accessing the features to begin with

Imagine leveling up your player stats to buy perks at the UbiquiStore. I don't think this is a viable proposal but an interesting thought:

• "You want the comment-incentives perk? 1000 UBQ"
• "You want the eject perk? 500 UBQ"

etc

• doing the communist debt system where they have a negative balance effectively and some other project "pays" the missing funds

I think its just the framing of this mechanism.

"communist" ☭: A future project pays a previous project's debt when the bounty hunter is collecting payment.
"automated" 🤖: A bounty hunter's debt is automatically deducted and refunded to the previous partner during their payout from a new partner.

[0x4007]

@rndquu perhaps we can complete the technical spec to turn this into a bounty? #441 (comment)

[rndquu]

@rndquu perhaps we can complete the technical spec to turn this into a bounty? #441 (comment)

Let's wait for #439