RPIP-39: Bounty Incentives (forum vote live)

[LongForWisdom]

Forum vote can be found here.

---

Hey folks. This is intended to be the discussion thread for RPIP-39. The RPIP in question can be found in the usual place:

RPIP-39: Bounty Incentives

---

Summary

Essentially, this RPIP aims to empower the GMC to provide incentive rewards if they choose to do so for three activities within the bounty process. These activities are:

• Proposing a Bounty - Providing the initial idea and convincing the GMC that it is worth pursuing. (paid when the proposal is adopted by the GMC)
• Defining a Bounty - Providing a clear and actionable set of milestones, deliverables and key information that can be used by a bounty hunter to complete the bounty. (paid when the definition is adopted by the GMC)
• Supporting a Bounty Hunter - Ie, providing feedback, direction and assistance navigating Rocket Pool’s processes and structures that a bounty hunter external to rocket pool may find challenging. (paid when a bounty is completed)

This proposal does not set hard numbers on these incentives, leaving those in the hands of the GMC. GMC decisions related to these incentives may be challenged using the existing GMC decision challenge process.

A set of recommendations are included that describe some of the authors thoughts related to lever setting. These are non-binding on the GMC, and are mainly just meant as a starting point for discussion.

@Valdorff (as RPIP editor) recommended that the @GMC propose some initial values prior to voting taking place. I don’t think that’s strictly necessary due to the challenge process, but I don’t object either.

I’ll follow up in a few days with a poll once there’s been some opportunity to discuss.

---

---

Initial Lever Recommendations

(section since removed from RPIP, included here so can be a part of the discussion)

These are non-binding recommendations to the GMC for initial incentive lever settings. They are included as a starting point for discussions and are not intended to limit GMC decision-making.

• For the first few months, levers SHOULD be set to higher levels, to reach a meaningful number of open bounties quickly.
• Lever A and B SHOULD NOT be zero unless unallocated GMC funds are low.
• Lever B SHOULD be higher than Lever A to incentivize the directly-actionable definitions over the not-directly-actionable proposals.
• Lever B SHOULD have a relative component, as higher-value bounties should be expected to have more detailed, more strict, and less ambiguous definitions.
• Lever C SHOULD be a focus for experimentation. It is difficult to know how useful or effective it will be without empirical testing.
• The sum of lever incentives SHOULD be less than 10% of the total bounty value under normal circumstances.

[ShfRyn]

I don’t feel strongly about any of the numbers I’ve posted below. I did throw several structural ideas into the mix to hopefully create a more optimal process.

–

First I think it’s important to categorize bounties by their amounts. A $50,000 bounty provides far greater impact to the protocol than a $1,000 bounty.

Bounties can be categorized into the following:

Regular Bounty:
Bounty Value <= $2,000

Premium Bounty:
Bounty Value > $2,000

–

Proposing A Bounty

• Regular Bounty - $50
• Premium Bounty - ROUND(ROUND(bountyValue / 100, 0) / 100, 0) * 100
  • I propose dividing the dollar amount of the bounty by 100 and rounding the result to the nearest $100
  • For example, a bounty worth $50,000 would award $500 to the bounty submitter, and a bounty worth $23,200 would award $200 to the bounty submitter.

Defining A Bounty

Defining the bounty is crucial and entails significant administrative effort if not done from the original applicant. It involves verifying intentions with multiple parties and it can be quite difficult ensuring it is error-free. I would like to see this incentive boosted as much as possible.

• Regular Bounty - $25 (maybe only claimable by the applicant? That way were not incurring too many small $ transfers, and unnecessary administrative overhead)
• Premium Bounty - ROUND(ROUND(bountyValue / 100, 0) / 100, 0) * 125
  • I propose dividing the dollar amount of the bounty by 100 and rounding the result to the nearest $125
  • For example, a bounty worth $50,000 would award $625 to the bounty definition writer, and a bounty worth $23,200 would award $250 to the bounty definition writer.

Supporting A Bounty Hunter

It looks like Patches is already a prime example of this, providing exceptional guidance to a bounty hunter for the Smartnode Notification Functionality bounty. I don’t think it is wise to attach a flat number to this. I foresee bounty facilitators spending anywhere from 10 minutes to several hours when managing a bounty.

• $50/hr for bounty support
• Maximum of 1 hour for regular bounties
• Maximum of 5 hours for premium bounties. (Anything supporters spending over 5 hours are welcome to submit a retrospective application)
• Create a process for ‘Approved Bounty Supporters’ where a list of several vetted individuals can be selected.

[LongForWisdom]

Thanks for starting the conversation on this ShfRyn.

Currently the RPIP is written assuming the formula for bounty calculation aren’t going to be this complex. I’m happy to update it if you want to go with this, but I’d give the following points for consideration.

@ShfRyn

First I think it’s important to categorize bounties by their amounts. A $50,000 bounty provides far greater impact to the protocol than a $1,000 bounty.

I would recommend not having discrete tiers here. I suggested absolute + relative amount in the RPIP. Given your numbers here, I would suggest:

Absolute reward: $50
Relative reward: 1% of the bounty value.

Below $2000, this is close enough to $50 to not be a meaningful difference. In what you currently propose, a premium bounty at $2001 is going to pay only $20, while a regular one would be $50.

Alternatively, you can set the incentive at 1%, and a minimum of $50 per proposal. Relative with Minimum might be a clearer way to express these than absolute + relative, to be honest.

@ShfRyn

I propose dividing the dollar amount of the bounty by 100 and rounding the result to the nearest $100

I really don’t think there is a need to round to the nearest $100. You gain very little from doing this, and the system becomes more complex, with weird incentives around bounty headline amounts due to the rounding borders. Just round to the nearest whole number internally to avoid fractional values and don’t mention this as part of the formula.

@ShfRyn

Regular Bounty - $25 (maybe only claimable by the applicant? That way were not incurring too many small $ transfers, and unnecessary administrative overhead)

I’d suggest you avoid small transfers by keeping an internal account, and only paying out to an individual address once their account exceeds your minimum amount. Perhaps $100, especially if gas prices start spiking more highly again. The GMC needs to keep an account of where money is committed anyway (due to committing to bounty payouts at the point a bounty is accepted rather than when it’s completed), so it shouldn’t be too much of a stretch to do this on top.

@ShfRyn

Supporting A Bounty Hunter

To be clear, as currently written, actual support work is not a requirement of the support contact being paid. This is intentional, as I think the goal is to have individuals standing by to provide support when asked rather than having the support contacts hassling bounty hunters absent their request (which you incentivize by requiring it.)

Given this is the case, I would start this off at a lower level to the other levers, and only increase it if there is a lack of individuals willing to sign up for this role.

I would not recommend creating a process to vet supporters at this stage, it runs the risk of creating process and administrative work that we don’t know if there is a need for. Give it a small relative and absolute reward, then see what the outcome is on newer bounties. Things to watch are maybe:

• Is the author always putting themself as the support contact?
• Are definitions being blocked because authors cannot find willing support contacts?
• Do the first few bounty hunters actually working on newer bounties speak positively about support contacts on average?
• Are any of the support contacts trying to abuse the incentive?

I’ll also note that the RPIP gives the GMC the power to refuse to pay out the support incentive for any reason, so there is a safety valve there against abuse.

[Valdorff]

@LongForWisdom

I would recommend not having discrete tiers here. I suggested absolute + relative amount in the bounty.

@LongForWisdom

Alternatively, you can set the incentive at 1%, and a minimum of $50 per proposal.

I like either of these much better than a hard cutoff.

@ShfRyn

I don’t think it is wise to attach a flat number to this. I foresee bounty facilitators spending anywhere from 10 minutes to several hours when managing a bounty.

Agreed. This can probably be handled similarly to the above - a maximum percentage payout.

@LongForWisdom

I would not recommend creating a process to vet supporters at this stage

Strong agree. I’m a huge fan of trusting first and adding overhead only as needed. We have some relevant safety valves.

[epineph]

So I really love the idea, and I think aiming to award community members who are selflessly contributing to others’ work is admirable and possibly critical to getting things done.

My critiques:
I think that the RPIP itself is too complex. Since the pDAO (composed of members with a variety of language abilities and time commitment) is the voting, I would try to pare down the RPIP to be more digestible. Since there is so much optionality and flexibility built into this, I do wonder whether a “this is what the pDAO mandates/allows” vs “this is left to the discretion of the GMC and the author is suggesting” format would make more sense; even linking to the latter as it is non-binding.

I am concerned that each bounty now could have up to 3 (or more, if multiple claimants) addition payments based off of it. This will definitely increase the work overhead of the GMC, and in actuality, a large chunk of this work would likely fall upon the administrator; in neither case do we have much extra bandwidth as we are already struggling to validate completed bounties and grants. Obviously these are mostly suggestions, but if the pDAO passes this there are 30+ extra rules laid out in the RPIP that we will be responsible for adhering to.
I think that there may be a point in running a trial of this (eg, a grant for 3 months or even a retroactive grant to see how the numbers would work and if they would be motivating). Specifically, if this system doesn’t work we have a dangling RPIP.

There’s nothing that prevents someone from listing a friend or someone who had little to do with the project; rooting out those individuals may be challenging.

In terms of lever values- totally based on my own feels
lever A: This should be a fixed value, not a percentage of the value to prevent overvaluing projects. I would set 100 USD.
Lever B: 3%, minimum 50$
Lever C: 5%, minimum 50$

[LongForWisdom]

I really appreciate the feedback and am happy to chat further about it whenever.

@epineph

I think that the RPIP itself is too complex…

If others agree, I can remove the initial recommendations to shorten it, and the corresponding part of the rationale section. I would be less comfortable removing more than that though. The benefit of leaving these decisions to the GMC is that it ultimately saves the pDAO more time and effort. Inevitably, at some point the GMC will want to change the settings to better meet some goal. It is better that the happy path doesn’t require the pDAO to vote again.

All that said, I value brevity as much as anyone. If you have any more targeted ideas or suggestions about how to cut complexity or length without serious impact to meaning, I’m happy to consider them.

@epineph

I am concerned that each bounty now could have up to 3 (or more, if multiple claimants) addition payments based off of it.

This is also under the GMC’s control. You can state that you will only accept bounties with one support contact. Or only accept bounties in which the proposer / definer /contact are the same person, etc. If the GMC is in a position where the upkeep of these rules is untenable, they can set the levers to zero and not worry about it.

@epineph

I think that there may be a point in running a trial of this (eg, a grant for 3 months or even a retroactive grant to see how the numbers would work and if they would be motivating).

A limited trial could have some benefit, and this is actively possible at the discretion of the GMC under the current wording. I’m unsure a retro would provide much incentive. I can throw together a spreadsheet to show what the GMC would have paid out for past bounties at various lever settings if you feel that useful, but I’m unsure how predictive it would be on future bounty submissions.

@epineph

Specifically, if this system doesn’t work we have a dangling RPIP.

We have a few of these. I don’t love them, but I don’t think they do any real harm. If we want to mitigate that issue on a wider basis, I’d suggest the RPIP editors apply tags to the RPIPs, so these can be more easily filtered out of the common view unless explicitly looked for.

@epineph

lever A: This should be a fixed value, not a percentage of the value to prevent overvaluing projects.

This is something the GMC should watch for, but I’m not sure it requires that the lever have a fixed value. Ultimately these incentives are only paid out if the GMC accepts a proposal. If you think a bounty is overvalued, you should modify it, or not accept it. If you do this consistently, there is no incentive for proposers to pad values.

[epineph]

I’ll preface by saying many or possibly most of my comments fall in the ‘unpopular opinion’ category.

point 1:
So I think the actual thing that the pDAO is voting on is something like “allow the GMC to offer up to an additional 10% of an approved bounty to incentivize proposing bounties, defining the completion and evaluation of bounties, and supporting completion of bounties.”

Everything else seems like it is optionality at the discretion of the GMC, and rather than empowering the pDAO by offering a lot of context, I think the complexity of the text may actual confuse the meaning of the vote for many, which effectively has the opposite effect of forcing interpretation through trusted community members (influencers).

Point 2: This is a good point.

point 3: I agree with you, I think doing a trial may not be the best use of administrative resource.

point 4: Fair point

point 5: The GMC has almost no functional ability to price things within an order of magnitude, and we trust the proposer (usually someone who has thought much more about the subject matter) to tell us what they think are reasonable prices because bounties are generally not claimed by the proposer; most awards are at 100% or declined. I think it’s better to not have any incentive for proposers to increase numbers. But I can see it your way as well.

Not trying to derail the thread but adding more context here

understandability

A linguistically complex discussion has a place in the forum, where many of us are here daily or weekly keeping up, fluent english, etc. Once you move to the full pDAO, we don’t know where people stand. The average reading literacy for Americans is ~8th grade level, and at least the going by recommendations in the medical field the sweet spot for communication is at a 4th-6th grade level. Apparently, this is even true when communicating to people with post-graduate education- they retain more new information when it is presented at a 6th grade level than at their stated educational level. I think simplifying the language will make it more likely the pDAO will participate and the vote will reflect their actual preferences

interpretability

The second point is more on aimed at the decentralization and interpretation standpoint. This RPIP has 30 rules that are not closely interrelated. If it passes (let’s say 80% to 20%), this doesn’t mean 80% of NOs think every rule is correct; rather that 80% think the sum of rules is better than no rules. In some circumstances, a majority could disagree with a majority of the rules and the RPIP could still pass; but for this thought experiment I’ll assume each rule gets about as much support as the entire proposal- 80%. So the chance of a given voter liking all 30 rules is 0.8^30 = 0.0012, close to 1/1000. So based on random chance, we are looking at 1/1000 NOs, or 3, agreeing with all rules- the author being one.

The other option is having a relatively small set of rules- lets say 5. Under the same assumptions, about 1/3 of node operators would agree with all 5 if the voting went 80/20. But then we get the the crux: if we use fewer rules, then more rules will be decided unilaterally by (in this case) the GMC. This SEEMS fundamentally centralizing.

Yet, from my standpoint, in effect the difference is a majority of the GMC (5 people) reach agreement on all rules, as opposed to 3 people in the pDAO. They are essentially equally centralized, but the complex pDAO vote is more pernicious because it gives the appearance of decentralization.

So if this RPIP gets voted in, who can say that the majority of pDAO agrees that “Lever B SHOULD be higher than Lever A to incentivize the directly-actionable definitions over the not-directly-actionable proposals?” It’s probably a little over 50/50, but not much.

[LongForWisdom]

Thanks Epi, comments were useful.

I’ll spend some time thinking on point 1. I don’t think I agree with your characterization but this isn’t really an angle I’d considered. I see most of the content as a framework that the GMC can use to actually do incentives. While there is optionality and complexity, surely this is preferable to just saying: ''GMC can spend up to 10% on incentives." and making no effort to impose any limitations or lay out any structure to this at all.

For point 5, I feel like you’re selling yourself short. Sure, no one expects the GMC to be experts at pricing, but in most cases we’re not talking about anything wildly far from ‘write, develop, organize or market something’ which feel like they’re common enough tasks that pricing is not arduous. For almost all bounties, you could likely get a solid number by asking each member to spend 5 minutes by the clock on an estimate, and then taking the median response.

I’ve never noticed an accepted grant or retro where the pricing is an order of magnitude from where my gut tells me it should be, at least once we’re up past $1000.

A better alternative may be that you pay-for-time for lever A and B, as ShfRyn suggested for C. The GMC then needs to price and evaluate the number of hours proposers and definers have spent on the proposal or definition in addition to evaluating the content. However, at least in this scenario the work being priced is always the same: Writing the bounty.

[LongForWisdom]

I’ve made some updates to reduce length and hopefully improve accessibility here: https://github.com/rocket-pool/RPIPs/pull/152/files. This includes removing the initial lever suggestions, which I will add to the initial post so they are still available for discussion.

I’ve not made any logic or structural changes so far.

[LongForWisdom]

I’ve made some further updates. Again, no major changes, but just taking into account some feedback from various people. Namely:

• Made it slightly more clear what the ‘lever’ terminology means.
• Ability to have minimum and maximum payout values for the levers.
• Slightly more clear on what happens when lever values are changed by the GMC.
• Added a section to the rationale to communicate my position on @epineph’s feedback.

Sentiment poll here:

RPIP-39: Bounty Incentives

• Support moving to vote; this is great
• Support moving to vote; this is good enough
• Oppose moving to vote
• Abstain

Please feel free to comment, especially if there are improvements you’d like to see in this proposal.

[dmccartney]

I think this is much more complex than necessary.
We should simply authorize the GMC to spend up to 10% on incentives and let them get creative.
I don’t see the upside in codifying to this level of detail in the RPIP.
If the authority doesn’t work or there are issues we can always adjust the authority later.

[CharlesIV]

Hello!

From an operational perspective, I feel that being less specific in the RPIP and leaving the GMC to use discretion when determining specifics seems to produce less friction.

Additionally, GMC members are elected presumably because we trust their judgement. Not requiring a vote to change all of the functions of this RPIP would make sense if we trust those members. So for these reasons I see where Epineph is coming from when they suggest a “this is left to the discretion of the GMC and the author is suggesting” approach to writing the RPIP.

When reading LFWs response, I began to wonder if the optionality or modularity of these systems can be expressed so that things look as lightweight as they would function in practice.

You could show the three scenarios you’re trying to allow the GMC to incentivize, the systems you suggest to keep that on rails, and what autonomy the GMC is left with. It could help guide how the GMC would view various requests with different requirements, without tying their hands if they shift things on the fly.

This might help address edge cases and structure payouts while also moving somewhat in the direction DMCcartney is suggesting.

Is it possible to “split the difference” by offering the GMC some tools to respond to grant requests without tying their hands or being overly complex?

Finally, I read your comments on centralization Epineph, and I’m not sure how to respond. If the pdao is giving an appearance of decentralization but perhaps does not offer a “true” check on a vote vs the GMC, I still believe we should approach that issue on its own.

Trusting the GMC w more autonomy regarding how they implement further incentives to propose, define, or support a bounty still seems the most efficient way to proceed.

[LongForWisdom]

Appreciate the comments @dmccartney and @CharlesIV, especially given the much more lively tokenomics discussions.

Given that you both agree in part with @epineph, I’m going to draft a more minimalist version of the RPIP, unless there’s a obvious negative response, I expect I’ll finalize the minimalist version. I’ll post it in the thread here for feedback shortly.

@CharlesIV

You could show the three scenarios you’re trying to allow the GMC to incentivize, the systems you suggest to keep that on rails, and what autonomy the GMC is left with. It could help guide how the GMC would view various requests with different requirements, without tying their hands if they shift things on the fly.

I’m having trouble translating this into actual text on the page. Could you give me an example of what you mean? I think that the included text does this indirectly, and that there’s not much a hypothetical narrative contributes to the RPIP post-ratification?

@CharlesIV

Is it possible to “split the difference” by offering the GMC some tools to respond to grant requests without tying their hands or being overly complex?

I’m not sure. From my perspective, the levers are those tools, and already fulfil the criteria of not being overly complex, and not overly tying hands. Beyond a carte blanche: ‘The GMC may spend their budget to incentivize engagement with the bounty system’ Any other statement ties their hands to some degree.

I’ll work on a minimalist draft today.

EDIT: Minimalist, low definition version - RPIPs/RPIPs/RPIP-39.md at 0067787e1f3c39f6dfe82edc0f0b8e6f1e454c66 · rocket-pool/RPIPs · GitHub

[CharlesIV]

I’ve reviewed the RPIP, and I think it balances things nicely. Using the section you’ve added towards the end labeled “Current and Historic Methods” to detail the framework for incentives is what I meant by “split the difference”.

In my mind, issuing guidance as to what path the GMC would consider in most scenarios while leaving them to negotiate details or switch up for edge cases will offer some insight to their calculus without imposing future votes to change details. That’s the happy medium.

If I’m missing a dynamic here and we need to be more specific in the RPIP, I’m open to using the initial RPIP. Unless it exposes us to some type of risk or potential issues, I prefer this approach from an operational perspective.

Thanks for your hard work LFW.

[LongForWisdom]

Aight. Response from everyone I’ve spoken to has been positive. So we’ll go with the more minimal version. I’ve requested the RPIP editors merge the changes and finalize the RPIP.

To summarize, major changes are:

• Removal of the definitions and incentive levers and associated text in other sections, and freedom is given to the GMC to determine methods.
• 10% limit to incentives is a hard rule (it was only a recommendation previously.)
• GMC Administrator is responsible for updating the current and previous incentive allocation methods section, and the table was removed, as it assumed adoption of the levers.

Assuming I get the okay from the editors, I’ll start writing up vote text shortly.

Thanks to all for the votes and feedback.

[LongForWisdom]

Vote text is now up for feedback here:

• GitHub PR (for line comments)
• Discord Thread (for discussion or comments)

[Patches]

I’m voting in favor, which should be unsurprising.

Writing a bounty and hiding in a cave until someone claims to have completed it isn’t a good UX for bounty hunters. We need people who are willing to provide them with guidance. Those people should be compensated for their time.